I have pushed the Autofac branch. On Sat, Apr 16, 2011 at 11:52 AM, Corey Kaylor <co...@kaylors.net> wrote:
> The biggest change is configuration. It has its own traditional > configuration section now. Anyone using a load balancer would need to point > to the container specific LoadBalancerBootStrapper. If wiring things up > yourself, there is a *slight* change from using a facility, but very > minimal. It took me all of 30 seconds to update our projects with the > changes, granted I am more familiar with them. > > I'll post a separate thread as requested detailing the changes required to > update. > > > > On Sat, Apr 16, 2011 at 11:43 AM, Mike Nichols > <nichols.mik...@gmail.com>wrote: > >> What braking changes are there? If it just means another assembly and >> behavior is the same I say go for it. The castle dep has been a numbs one >> obstacle to this projects adoption. There is one thing I may have a problem >> with but will check that branch when I get home. >> On Apr 15, 2011 3:24 AM, "Steve Wagner" <li...@lanwin.de> wrote: >> > Ok that is much better. I fallen about that branch right after ive send >> > the message. >> > >> > What you can do is simply. Make an announcement about the change and >> > what breaking changes are there. Then give the people an ultimatum to >> > answer (in example 7 days) and if no one have a reason against it, do >> > the merge. >> > >> > Since i mainly interested in using ESB with Autofac, where can i help >> > you with the Autofac parts? >> > >> > -Steve >> > >> > On 14.04.2011 23:50, Corey Kaylor wrote: >> >> Sounds very similar to the work I did as well, including configuration >> >> changes, etc. Did you by chance look at the branch I have on github? My >> only >> >> reservation to merging into master is that certain people who don't >> seem to >> >> have an opinion will likely have one after the fact and I don't really >> have >> >> a lot of free time on my hands at the moment. I would love to close >> this out >> >> though, we've been using StructureMap with RSB for some time now and >> it's >> >> working out well. I also have a 80% implemented Autofac container as >> well. >> >> >> >> https://github.com/hibernating-rhinos/rhino-esb/tree/servicelocator >> >> >> >> Thoughts? >> >> >> >> On Thu, Apr 14, 2011 at 1:03 PM, Steve Wagner<li...@lanwin.de> wrote: >> >> >> >>> Ok lets bring this a bit forward! >> >>> >> >>> https://github.com/lanwin/rhino-esb >> >>> >> >>> Ive created a fork and extracted all Windsor specific stuff to an >> >>> Rhino.ServiceBus.Windsor assembly. Then I've replaced all usages of >> the >> >>> Kernel in the core parts with an IContainerAdapter interface and added >> an >> >>> impl of it to the Rhino.ServiceBus.Windsor. This assembly contains >> mostly >> >>> configuration,facilities and hosts. >> >>> >> >>> It works, all tests pass and the Starbucks example runs. The only >> problem >> >>> is that the Starbucks.Tests dont run because it dose not Shadowcopy >> both >> >>> assemblies. Maybe someone else has an idea why?!? >> >>> >> >>> If we now move the common functionality of the >> configuration,facilities and >> >>> hosts to more abstract base classes, we have a pretty good extension >> point >> >>> for using another container. Also Windsor could stay the main >> container of >> >>> RSB. >> >>> >> >>> For existing users there is nearly no migration overhead. They only >> need to >> >>> add the new assembly and they are done, no breaking changes. >> >>> >> >>> If the second assembly is really a problem, we could provide an second >> >>> ilmerged distribution package. >> >>> >> >>> Thoughts? >> >>> >> >>> -Steve >> >>> >> >>> >> >>> On 01.02.2011 23:02, Corey Kaylor wrote: >> >>> >> >>>> It is both 3.5 and 4.0 currently, 4.0 is built from the powershell >> script. >> >>>> Although all that is negotiable depending on the route chosen. >> >>>> >> >>>> >> >>> -- >> >>> You received this message because you are subscribed to the Google >> Groups >> >>> "Rhino Tools Dev" group. >> >>> To post to this group, send email to rhino-tools-dev@googlegroups.com >> . >> >>> To unsubscribe from this group, send email to >> >>> rhino-tools-dev+unsubscr...@googlegroups.com. >> >>> For more options, visit this group at >> >>> http://groups.google.com/group/rhino-tools-dev?hl=en. >> >>> >> >>> >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "Rhino Tools Dev" group. >> > To post to this group, send email to rhino-tools-dev@googlegroups.com. >> > To unsubscribe from this group, send email to >> rhino-tools-dev+unsubscr...@googlegroups.com. >> > For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Rhino Tools Dev" group. >> To post to this group, send email to rhino-tools-dev@googlegroups.com. >> To unsubscribe from this group, send email to >> rhino-tools-dev+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to rhino-tools-dev@googlegroups.com. To unsubscribe from this group, send email to rhino-tools-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
