Problem with Windsor null reference exception

[Henrik]

I was wondering if I could get some help debugging this exception?

TearDown : System.NullReferenceException : Object reference not set to
an instance of an object.
at System.Collections.ObjectModel.Collection`1.Add(T item)

at
Castle.Facilities.AutoTx.TxComponentInspector.AddInterceptor(ComponentModel
model)
at
Castle.Facilities.AutoTx.TxComponentInspector.ProcessModel(IKernel
kernel, ComponentModel model)

at
Castle.MicroKernel.ModelBuilder.DefaultComponentModelBuilder.BuildModel(String
key, Type service, Type classType, IDictionary extendedProperties)
at
Castle.MicroKernel.Registration.ComponentRegistration`1.Castle.MicroKernel.Registration.IRegistration.Register(IKernel
kernel)

at Castle.MicroKernel.DefaultKernel.Register(IRegistration[]
registrations)
at Castle.Windsor.WindsorContainer.Register(IRegistration[]
registrations)
NHibernateFacility_ValidationError_OnSave.cs(75,0): at
Castle.Facilities.NHibernate.Tests.Container..ctor()
NHibernateFacility_ValidationError_OnSave.cs(48,0): at
Castle.Facilities.NHibernate.Tests.NHibernateFacility_ValidationError_OnSave.SetUp()
--TearDown
NHibernateFacility_ValidationError_OnSave.cs(54,0): at
Castle.Facilities.NHibernate.Tests.NHibernateFacility_ValidationError_OnSave.TearDown()

A repro is here:
https://github.com/haf/Castle.Facilities.NHibernate/commit/bc2257cd4e0992f1d2bde70de14da383910927b9

Windsor 2.5.2, 2.5.3 are affected. Not 2.5.1.xxxx

[Berke Sokhan]

Any news on this one? I am getting it too.

Without a resolution to this, whole new Castle.Facilities.AutoTx / Castle.Services.Transactions / Castle.Facilities.NHibernate trilogy become useless :(

2011/5/6 Henrik <hen...@haf.se>

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

--
Berke SOKHAN.

http://twitter.com/berkesokhan
http://blog.berkesokhan.com
http://www.birliktegelistir.com/editors.aspx

[Krzysztof Koźmic]

If you can reproduce it in a way that points to some reasonable bug in Windsor or elsewhere...

I looked at it when Henrik originally reported it but other than "that's bizarre it can't be happening" I didn't find any good explanation for that.

Krzysztof

[Berke Sokhan]

My stack looks same with Henrik:

   at System.Collections.ObjectModel.Collection`1.Add(T item)
   at Castle.Facilities.AutoTx.TransactionalComponentInspector.AddInterceptor(ComponentModel model) in d:\Builds\Castle.Transactions-beta\src\Castle.Facilities.AutoTx\TransactionalComponentInspector.cs:line 78
   at Castle.Facilities.AutoTx.TransactionalComponentInspector.ProcessModel(IKernel kernel, ComponentModel model) in d:\Builds\Castle.Transactions-beta\src\Castle.Facilities.AutoTx\TransactionalComponentInspector.cs:line 46
   at Castle.MicroKernel.ModelBuilder.DefaultComponentModelBuilder.BuildModel(String key, Type service, Type classType, IDictionary extendedProperties) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\ModelBuilder\DefaultComponentModelBuilder.cs:line 67
   at Castle.MicroKernel.Registration.ComponentRegistration`1.Castle.MicroKernel.Registration.IRegistration.Register(IKernel kernel) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registration\ComponentRegistration.cs:line 904
   at Castle.MicroKernel.DefaultKernel.Register(IRegistration[] registrations) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\DefaultKernel.cs:line 595
   at Castle.MicroKernel.Registration.BasedOnDescriptor.TryRegister(Type type, IKernel kernel) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registration\BasedOnDescriptor.cs:line 208
   at Castle.MicroKernel.Registration.FromDescriptor.Castle.MicroKernel.Registration.IRegistration.Register(IKernel kernel) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registration\FromDescriptor.cs:line 96
   at Castle.MicroKernel.Registration.BasedOnDescriptor.Castle.MicroKernel.Registration.IRegistration.Register(IKernel kernel) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registration\BasedOnDescriptor.cs:line 325
   at Castle.MicroKernel.DefaultKernel.Register(IRegistration[] registrations) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\DefaultKernel.cs:line 595
   at Castle.Windsor.WindsorContainer.Register(IRegistration[] registrations) in e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\Windsor\WindsorContainer.cs:line 689
   at PayFlex.Vpos.Server.Container.Bootstrapper.Initialize() in D:\SVN Repositories\iPayVPOS\trunk\PayFlex.Vpos\PayFlex.Vpos.Server.Container\Bootstrapper.cs:line 32
   at PayFlex.Vpos.Server.Application.Program.Main() in D:\SVN Repositories\iPayVPOS\trunk\PayFlex.Vpos\PayFlex.Vpos.Server.Application\Program.cs:line 19
   at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
   at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
   at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

I am using Henrik's version of Transactions/AutoTx lib coming with new NH Facility.

And I get this exception when registering some POCO service class which have "Transactional" attribute on it (removing attr. prevents exception, but nh facility need it to open injected session).

My early impression was AutoTx has some bug in inspecting attributes, maybe a null check before adding to interceptors collection obviously ...

Will look at source and try to point exact location.

2011/6/16 Krzysztof Koźmic <krzyszto...@gmail.com>

[Henrik Feldt]

Hmm, I don’t know how to fix this properly...

 

The only work-around so far for me is to downgrade Windsor to 2.5.1. That works. I suggested that some of the improvements from v3 might be back-ported to change some of the bits in Windsor and make it go away.

 

Henrik

[Berke Sokhan]

I also tried to gather all Castle projects to one solution to see what is failing but w/o success.

Got all sources from git/castleproject source and  git/haf/castle.facilities.nhibernate built them. But NH facility uses Windsor 2.5.1, and I dont want to downgrade to it. I already spent too much time try to integrate the new nh facility. I also noticed old NHIntegration facility uses an old version of Castle.

So may I ask you guys, to achive session-per-call/tx-per-call nhibernate WCF application server (that is not using IIS or httpbinding), excluding nhfacilities and including wcf facility...

Can you guide me to a best practice?



2011/6/18 Henrik Feldt <hen...@haf.se>

[hammett]

I guess this testifies that the separation of codebases brought up
some pain for users. I'd say that we need to bring them back
together..

--
Cheers,
hammett
http://hammett.castleproject.org/

[Berke Sokhan]

+1 if I may.

2011/6/20 hammett <ham...@gmail.com>

[hammett]

I'll take the burden to combine the repositories soon. And integrate
the build system. Unless someone is really against it..

It's the cycle of life: change, gain insight, change again.

On Mon, Jun 20, 2011 at 9:17 AM, Berke Sokhan <berke...@gmail.com> wrote:
> +1 if I may.
>
> 2011/6/20 hammett <ham...@gmail.com>
>>
>> I guess this testifies that the separation of codebases brought up
>> some pain for users. I'd say that we need to bring them back
>> together..

--
Cheers,
hammett
http://hammett.castleproject.org/

[hammett]

Or shall we use git's submodule?

[Sebastien Lambla]

I'd say that one of the issues here is breaking changes being introduced across versions. Even if you reintegrated those components, things would still break for users in the same unexpected way.

Isn't it an integration testing automation problem rather than a code split one?

>> el(String key, Type service, Type classType, IDictionary

>> n\FromDescriptor.cs:line
>> 96
>>    at
>> Castle.MicroKernel.Registration.BasedOnDescriptor.Castle.MicroKernel.
>> Registration.IRegistration.Register(IKernel

>> kernel) in
>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registratio

>> el(String key, Type service, Type classType, IDictionary

[Mauricio Scheffer]

+1 to this. I wouldn't put the code back together in a single repository. Instead, try creating a super-project / super-repository explicitly for integration purposes, with git submodules (or subtree merging http://progit.org/book/ch6-7.html ) pointing to the individual project repositories.

--

Mauricio

[John Simons]

I'm also against the merging of the repositories in a single one.

I think the current solution provides the best outcome for individual committers and patchers.

As Seb points out, the current problem is the lack of release process and automation.

I've mentioned before that maybe we need some kind of build manager/release manager that releases/builds Castle as a whole, from the individual repositories.

-1 for using submodules and/or subtree.

Instead we should have a go at automating as much as possible and try OW to deal with inter-dependencies.

Cheers

John

---

From: Mauricio Scheffer <mauricio...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Tuesday, 21 June 2011 6:46 AM

[hammett]

The issue reported by the user (getting all pieces to compile) doesnt
seem to have anything to do with release process/automation. Since I
had the same issue, and ended up giving up (which speaks volumes),
this is an issue that urges a solution.

On Mon, Jun 20, 2011 at 2:37 PM, John Simons <johnsi...@yahoo.com.au> wrote:
> I'm also against the merging of the repositories in a single one.
> I think the current solution provides the best outcome for individual
> committers and patchers.
> As Seb points out, the current problem is the lack of release process and
> automation.

[Henrik Feldt]

I agree with John. The problem is not having them separate, but the lack of integration testing.

 

I think a good package manager and more integration testing is the answer.

[hammett]

Well, it's not a source or binary compatibility issue. Seems more like
a bug related to order of calls. I dont know Krzysztof's release
process, but he may caught this earlier if he run the facility test
cases. The problem is that this is damn difficult to do now, since all
projects are their own island.

[hammett]

This seems like the easiest way to solve it.

[Henrik Feldt]

It does take a LOT of time initially. The histories are big. I tried.

Perhaps another angle could be team city's 'build dependency' concept?

>> >> Mod el(String key, Type service, Type classType, IDictionary

>> >> extendedProperties) in
>> >> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\ModelBui

>> >> lde r\DefaultComponentModelBuilder.cs:line
>> >> 67
>> >> at
>> >> Castle.MicroKernel.Registration.ComponentRegistration`1.Castle.Mic
>> >> roK ernel.Registration.IRegistration.Register(IKernel

>> >> kernel) in
>> >> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registra
>> >> tio
>> >> n\ComponentRegistration.cs:line
>> >> 904
>> >> at Castle.MicroKernel.DefaultKernel.Register(IRegistration[]
>> >> registrations) in
>> >> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\DefaultK
>> >> ern
>> >> el.cs:line
>> >> 595
>> >> at
>> >> Castle.MicroKernel.Registration.BasedOnDescriptor.TryRegister(Type
>> >> type, IKernel kernel) in
>> >> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registra
>> >> tio
>> >> n\BasedOnDescriptor.cs:line
>> >> 208
>> >> at
>> >> Castle.MicroKernel.Registration.FromDescriptor.Castle.MicroKernel.

>> >> Reg istration.IRegistration.Register(IKernel

>> >> Mod el(String key, Type service, Type classType, IDictionary
>> >> extendedProperties)
>> >> at
>> >>
>> >> Castle.MicroKernel.Registration.ComponentRegistration`1.Castle.Mic
>> >> roK ernel.Registration.IRegistration.Register(IKernel

[Krzysztof Koźmic]

+1 for merging repositories, at least to a degree.
We've already did that with Windsor and some facilities and Castle.Core and things like logging services or DictionaryAdapter which got pulled into Castle.Core.dll altogether.

To pain better picture here are the repositories we currently have for CastleProject at github (I removed repositories that are marked as readonly):

Castle.MonoRail3
Castleproject.org-Site
Castle.Core
Castle.Windsor
NVelocity
Castle.Facilities.Wcf
Castle.Transactions
Castle.Components.Binder
Castle.ActiveRecord
Castle.MonoRail
Castle.Facilities.ActiveRecordIntegration
Castle.Facilities.NHibernateIntegration
Castle.Components.Validator
Castle.Components.Scheduler
Castle.Components.TemplateEngine
Castle.Components.Pagination

16 repositories altogether.
Out of those I think we should do some merges as follows:

1. Castle.MonoRail3, Castle.MonoRail, NVelocity
2. Castle.Windsor, Castle.Facilities.Wcf, Castle.Facilities.NHibernateIntegration
3. Castle.Core, Castle.Components.Validator, Castle.Components.Scheduler, Castle.Components.TemplateEngine, Castle.Components.Pagination
4. Castle.ActiveRecord, Castle.Facilities.ActiveRecordIntegration
5. Castle.Transactions (unless Henrik wants it to go with Windsor)
6. Castleproject.org-Site <-- that I would be happiest to move away from current model and have a simple CMS, current model for updating the site is PITA but I digress

You may notice Castle.Components.Binder is not on the list. IIRC John had a look into this and suggested it could be pulled into Monorail altogether.


With the sourcecode-level merges we could still maintain independent release schedule by working off of release branches but in reality I'd be most happy for projects that live together to be released together. This is going to get a bit more complicated for Core releases as all top level projects (AR, MR and Windsor) will be driving changes in Core so we'll need to pay some attention to that.

As for common testing I'm all for it although not sure how we'll deal with breaking changes...
Krzysztof

[hammett]

Great suggestion!

2011/6/21 Krzysztof Koźmic <krzyszto...@gmail.com>:

[John Simons]

I'm +1 for Krzysztof suggestion but there are a few projects that I'm not too sure if are worth keeping.

I suggest we decommission: Castle.Components.Scheduler and Castle.Components.TemplateEngine.

Castle.Components.Scheduler, Mauricio has done an integration between Quartz + Windsor

Castle.Components.TemplateEngine, this is just 1 interface!

I think Castle.Components.Pagination could be absorbed by MR too.

And I'm not too sure what to do with Validation, my first though is decommission it, thoughts?

NVelocity, unfortunately there is no point of also keeping this one, I mean we should keep it until MR+++ is released and after that, get rid of it, thoughts?

---

From: hammett <ham...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Tuesday, 21 June 2011 8:37 PM

>>> castle-project-devel+unsub...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/castle-project-devel?hl=en.
>>>
>>>
>>> --
>>> Berke SOKHAN.
>>>
>>> http://twitter.com/berkesokhan
>>> http://blog.berkesokhan.com
>>> http://www.birliktegelistir.com/editors.aspx
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google
>>> Groups "Castle Project Development List" group.
>>> To post to this group, send email to
>>> castle-pro...@googlegroups.com.
>>> To unsubscribe from this group, send email to

>>> castle-project-devel+unsub...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/castle-project-devel?hl=en.
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Castle Project Development List" group.
>>> To post to this group, send email to
>>> castle-pro...@googlegroups.com.
>>> To unsubscribe from this group, send email to

>>> castle-project-devel+unsub...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/castle-project-devel?hl=en.
>>>
>>>
>>> --
>>> Berke SOKHAN.
>>>
>>> http://twitter.com/berkesokhan
>>> http://blog.berkesokhan.com
>>> http://www.birliktegelistir.com/editors.aspx
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Castle Project Development List" group.
>>> To post to this group, send email to
>>> castle-pro...@googlegroups.com.
>>> To unsubscribe from this group, send email to

>>> castle-project-devel+unsub...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/castle-project-devel?hl=en.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Castle Project Development List" group.
>>> To post to this group, send email to
>>> castle-pro...@googlegroups.com.
>>> To unsubscribe from this group, send email to

>>> castle-project-devel+unsub...@googlegroups.com.

>>> For more options, visit this group at
>>> http://groups.google.com/group/castle-project-devel?hl=en.
>>
>>
>>
>> --
>> Berke SOKHAN.
>>
>> http://twitter.com/berkesokhan
>> http://blog.berkesokhan.com
>> http://www.birliktegelistir.com/editors.aspx
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Castle Project Development List" group.
>> To post to this group, send email to
>> castle-pro...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> castle-project-devel+unsub...@googlegroups.com.

>> For more options, visit this group at
>> http://groups.google.com/group/castle-project-devel?hl=en.
>>
>
>
>
> --
> Cheers,
> hammett
> http://hammett.castleproject.org/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to

> castle-project-devel+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>



--
Cheers,
hammett
http://hammett.castleproject.org/

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.

To unsubscribe from this group, send email to castle-project-devel+unsub...@googlegroups.com.

[Henrik]

I was objecting to the merging of Castle Transactions with AutoTx and
potentially with NHibernate Facility and Windsor... Which this thread
was about initially - if other projects are to be merged, then can a
new thread be started please?

With regards to the core problem of this thread - Windsor messing up
interceptors in version 2.5.2 and 2.5.3 I think it would be good if
Krzysztof could look at doing a "git bisect" in the source of Windsor
between 2.5.2 and 2.5.1 to see what introduced the problem and then
release a 2.5.4. Alternatively Berkan could do the same. I don't have
the time at the moment to learn and look into Windsor's code.

This would solve the thread's original problem. A process for
integration testing changes that affect downstream packages could then
be introduced on the CI server.

On Jun 21, 11:47 pm, John Simons <johnsimons...@yahoo.com.au> wrote:
> I'm +1 for Krzysztof suggestion but there are a few projects that I'm not too sure if are worth keeping.
> I suggest we decommission: Castle.Components.Scheduler and Castle.Components.TemplateEngine.
> Castle.Components.Scheduler, Mauricio has done an integration between Quartz + Windsor
> Castle.Components.TemplateEngine, this is just 1 interface!
>
> I think Castle.Components.Pagination could be absorbed by MR too.
> And I'm not too sure what to do with Validation, my first though is decommission it, thoughts?
>
> NVelocity, unfortunately there is no point of also keeping this one, I mean we should keep it until MR+++ is released and after that, get rid of it, thoughts?
>
> ________________________________

> From: hammett <hamm...@gmail.com>

> To: castle-pro...@googlegroups.com
> Sent: Tuesday, 21 June 2011 8:37 PM
> Subject: Re: Problem with Windsor null reference exception
>
> Great suggestion!
>

> 2011/6/21 Krzysztof Koźmic <krzysztof.koz...@gmail.com>:

> ...
>
> read more »

[Henrik]

You will have to downgrade it till we have solved this problem, or you
will have to solve it yourself. We accept pull requests.

On top of things, the NHibernate Facility that you are using is in
beta at the moment, but has no known bugs. I am working as much as I
can with respect to other committments, to make both Tx, AutoTx and
NHFac GA-releases.

Cheers,
Henrik

On Jun 20, 10:45 am, Berke Sokhan <berkesok...@gmail.com> wrote:
> I also tried to gather all Castle projects to one solution to see what is
> failing but w/o success.
>
> Got all sources from git/castleproject source and
> git/haf/castle.facilities.nhibernate built them. But NH facility uses
> Windsor 2.5.1, and I dont want to downgrade to it. I already spent too much
> time try to integrate the new nh facility. I also noticed old NHIntegration
> facility uses an old version of Castle.
>

> So may I ask you guys, to achive* session-per-call/tx-per-call nhibernate

> WCF application server (that is not using IIS or httpbinding), excluding

> nhfacilities and including wcf facility*...

>
> Can you guide me to a best practice?
>
> 2011/6/18 Henrik Feldt <hen...@haf.se>
>
>
>
>
>
>
>
>
>

> > Hmm, I don’t know how to fix this properly... ****
>
> > ** **

>
> > The only work-around so far for me is to downgrade Windsor to 2.5.1. That
> > works. I suggested that some of the improvements from v3 might be

> > back-ported to change some of the bits in Windsor and make it go away.****
>
> > ** **
>
> > Henrik****
>
> > ** **
>
> > *From:* castle-pro...@googlegroups.com [mailto:
> > castle-pro...@googlegroups.com] *On Behalf Of *Berke Sokhan
> > *Sent:* den 16 juni 2011 14:11
> > *To:* castle-pro...@googlegroups.com
>
> > *Subject:* Re: Problem with Windsor null reference exception****
>
> > ** **

> > ****
>
> > 2011/6/16 Krzysztof Koźmic <krzysztof.koz...@gmail.com>****

>
> > If you can reproduce it in a way that points to some reasonable bug in
> > Windsor or elsewhere...
>
> > I looked at it when Henrik originally reported it but other than "that's
> > bizarre it can't be happening" I didn't find any good explanation for that.
>

> > Krzysztof****
>
> > On 16/06/2011 8:47 AM, Berke Sokhan wrote: ****

>
> > Any news on this one? I am getting it too.
>
> > Without a resolution to this, whole new Castle.Facilities.AutoTx /
> > Castle.Services.Transactions / Castle.Facilities.NHibernate trilogy become

> > useless :(****
>
> > 2011/5/6 Henrik <hen...@haf.se>****

> >https://github.com/haf/Castle.Facilities.NHibernate/commit/bc2257cd4e...

>
> > Windsor 2.5.2, 2.5.3 are affected. Not 2.5.1.xxxx
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to
> > castle-project-d...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/castle-project-devel?hl=en.****

>
> > --
> > Berke SOKHAN.
>
> >http://twitter.com/berkesokhan
> >http://blog.berkesokhan.com

> >http://www.birliktegelistir.com/editors.aspx****
>
> > -- ****

>
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to
> > castle-project-d...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/castle-project-devel?hl=en.****
>
> > ** **

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to
> > castle-project-d...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/castle-project-devel?hl=en.****

>
> > --
> > Berke SOKHAN.
>
> >http://twitter.com/berkesokhan
> >http://blog.berkesokhan.com

> >http://www.birliktegelistir.com/editors.aspx****

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to
> > castle-project-d...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/castle-project-devel?hl=en.****

[Mauricio Scheffer]

I'll post here to keep the voting thread clean:

Shallow clones mitigate somewhat the initial clone time. Shallow
clones can be used with submodules ( http://stackoverflow.com/questions/2144406/git-shallow-submodules
), not sure they can be used with subtrees.

About using TeamCity, how would it work when you want to write some
integration tests involving two projects?

About merging repositories: with DVCS it's generally recommended to
keep one repository per project (see
http://stackoverflow.com/questions/2732020/git-repository-layout-for-server-with-multiple-projects/2732038#2732038
, http://kiln.stackexchange.com/questions/500/should-i-use-more-than-one-repository
). Linus recommended the KDE team to split their repository into one
repo per project and integrating using submodules, when they were
migrating from SVN to git: http://lwn.net/Articles/246381/
If each project is in its own repository, it's easy to create as many
integration repositories as we need, while at the same time keeping
each project independent.

I agree about merging some projects though, e.g. Pagination into Core.

--
Mauricio

On Jun 21, 2:05 am, "Henrik Feldt" <hen...@haf.se> wrote:
> It does take a LOT of time initially. The histories are big. I tried.
>
> Perhaps another angle could be team city's 'build dependency' concept?
>
>
>
>
>
>
>
> -----Original Message-----
> From: castle-pro...@googlegroups.com [mailto:castle-pro...@googlegroups.com] On Behalf Of hammett
> Sent: den 21 juni 2011 00:20
> To: castle-pro...@googlegroups.com
> Subject: Re: Problem with Windsor null reference exception
>
> This seems like the easiest way to solve it.
>

> On Mon, Jun 20, 2011 at 1:46 PM, Mauricio Scheffer <mauricioschef...@gmail.com> wrote:
> > +1 to this. I wouldn't put the code back together in a single repository.
> > Instead, try creating a super-project / super-repository explicitly
> > for integration purposes, with git submodules (or subtree merging

> >http://progit.org/book/ch6-7.html) pointing to the individual project

> > repositories.
> > --
> > Mauricio
>
> > On Mon, Jun 20, 2011 at 5:02 PM, Sebastien Lambla <s...@serialseb.com> wrote:
>
> >> I'd say that one of the issues here is breaking changes being
> >> introduced across versions. Even if you reintegrated those
> >> components, things would still break for users in the same unexpected way.
>
> >> Isn't it an integration testing automation problem rather than a code
> >> split one?
>
> >> -----Original Message-----
> >> From: castle-pro...@googlegroups.com
> >> [mailto:castle-pro...@googlegroups.com] On Behalf Of hammett
> >> Sent: 20 June 2011 17:03
> >> To: castle-pro...@googlegroups.com
> >> Subject: Re: Problem with Windsor null reference exception
>
> >> I guess this testifies that the separation of codebases brought up
> >> some pain for users. I'd say that we need to bring them back together..
>

> >> On Mon, Jun 20, 2011 at 1:45 AM, Berke Sokhan <berkesok...@gmail.com>

> >> >> 2011/6/16 Krzysztof Koźmic <krzysztof.koz...@gmail.com>

> >> >> 0992f1d2bde70de14da383910927b9...
>
> read more »

[Henrik]

I have started the debugging ritual...

I can state that commit
31be4bb4305dd54813f7
contains the problem.

Moving on...

> > > "Castle Project Development...
>
> read more »

[Henrik]

...besides that, the tag 2.5.1 doesn't contain the namespace:
Castle.Facilities.TypedFactory

so I couldn't just checkout the correct tag, but have to manually test
my way forward...

We should set up a proper tagging system, imo, so that source can be
correlated with packages.

> > > > To post to this group, send...
>
> read more »

[Henrik]

This is the commit that broke interceptors:

https://github.com/castleproject/Castle.Windsor/commit/c2d7115109021

[Henrik]

In fact, it's the above commit (c2d7115109021) and the changes made to
this file:

src/Castle.Windsor/Core/DependencyModelCollection.cs

> > > > > > You received this message because you are subscribed to the Google Groups...
>
> read more »

[Henrik]

Here is a merged branch for which tests pass for me, both Windsor and
NHibernateFacility.

https://github.com/haf/Castle.Windsor/tree/2.5.4

Please release it, asap! ;) Or tell me if there are newly introduced
problems in it.

> > > > > > >    NHibernateFacility_ValidationError_OnSave.cs(48,0): at...
>
> read more »

[Henrik]

Nuget now has versions unaffected by this problem.

Issue closed. ^^ Yey.

> > > > > > > >    at...
>
> read more »