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 <[email protected]> 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 <[email protected]> > To: [email protected] > Sent: Tuesday, 21 June 2011 8:37 PM > Subject: Re: Problem with Windsor null reference exception > > Great suggestion! > > 2011/6/21 Krzysztof Koźmic <[email protected]>: > > > > > > > > > +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 > > > On 21/06/2011 8:16 AM, Henrik Feldt wrote: > > > 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. > > > From: [email protected] > > [mailto:[email protected]] On Behalf Of John Simons > > Sent: den 20 juni 2011 23:37 > > To: [email protected] > > Subject: Re: Problem with Windsor null reference exception > > > 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 <[email protected]> > > To: [email protected] > > Sent: Tuesday, 21 June 2011 6:46 AM > > Subject: Re: Problem with Windsor null reference exception > > > +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 <[email protected]> > > 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: [email protected] > > [mailto:[email protected]] On Behalf Of hammett > > Sent: 20 June 2011 17:03 > > To: [email protected] > > 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 <[email protected]> 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 <[email protected]> > > >>> 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: [email protected] > >>> [mailto:[email protected]] On Behalf Of Berke > >>> Sokhan > >>> Sent: den 16 juni 2011 14:11 > >>> To: [email protected] > > >>> Subject: Re: Problem with Windsor null reference exception > > >>> My stack looks same with Henrik: > > >>> at System.Collections.ObjectModel.Collection`1.Add(T item) > >>> at > >>> Castle.Facilities.AutoTx.TransactionalComponentInspector.AddIntercept > >>> or(ComponentModel > >>> model) in > >>> d:\Builds\Castle.Transactions-beta\src\Castle.Facilities.AutoTx\Trans > >>> actionalComponentInspector.cs:line > >>> 78 > >>> at > >>> Castle.Facilities.AutoTx.TransactionalComponentInspector.ProcessModel > >>> (IKernel > >>> kernel, ComponentModel model) in > >>> d:\Builds\Castle.Transactions-beta\src\Castle.Facilities.AutoTx\Trans > >>> actionalComponentInspector.cs:line > >>> 46 > >>> at > >>> Castle.MicroKernel.ModelBuilder.DefaultComponentModelBuilder.BuildMod > >>> el(String key, Type service, Type classType, IDictionary > >>> extendedProperties) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\ModelBuilde > >>> r\DefaultComponentModelBuilder.cs:line > >>> 67 > >>> at > >>> Castle.MicroKernel.Registration.ComponentRegistration`1.Castle.MicroK > >>> ernel.Registration.IRegistration.Register(IKernel > >>> kernel) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registratio > >>> n\ComponentRegistration.cs:line > >>> 904 > >>> at Castle.MicroKernel.DefaultKernel.Register(IRegistration[] > >>> registrations) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\DefaultKern > >>> el.cs:line > >>> 595 > >>> at > >>> Castle.MicroKernel.Registration.BasedOnDescriptor.TryRegister(Type > >>> type, IKernel kernel) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registratio > >>> n\BasedOnDescriptor.cs:line > >>> 208 > >>> at > >>> Castle.MicroKernel.Registration.FromDescriptor.Castle.MicroKernel.Reg > >>> istration.IRegistration.Register(IKernel > >>> kernel) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\Registratio > > >>> 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 > >>> n\BasedOnDescriptor.cs:line > >>> 325 > >>> at Castle.MicroKernel.DefaultKernel.Register(IRegistration[] > >>> registrations) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\MicroKernel\DefaultKern > >>> el.cs:line > >>> 595 > >>> at Castle.Windsor.WindsorContainer.Register(IRegistration[] > >>> registrations) in > >>> e:\OSS.Code\Castle.Windsor\src\Castle.Windsor\Windsor\WindsorContaine > >>> r.cs:line > >>> 689 > >>> at PayFlex.Vpos.Server.Container.Bootstrapper.Initialize() in > >>> D:\SVN > >>> Repositories\iPayVPOS\trunk\PayFlex.Vpos\PayFlex.Vpos.Server.Containe > >>> r\Bootstrapper.cs:line > >>> 32 > >>> at PayFlex.Vpos.Server.Application.Program.Main() in D:\SVN > >>> Repositories\iPayVPOS\trunk\PayFlex.Vpos\PayFlex.Vpos.Server.Applicat > >>> ion\Program.cs:line > >>> 19 > >>> at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, > >>> String[] args) > >>> > > ... > > read more » -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
