That's what I was considering for the implementation of this - unfortunately it only provides a collection of methods to retrieve component instances from the container, as it is a service locator. There would have to be something else that wires up all the correct components to use in RSB which would be unique per supported container (Windsor, Autofac, etc...) and to me that seems like an awful lot of duplication. Per my last email we'd probably be better off looking at creating an abstraction perhaps over CommonServiceLocator that allowed for component registration as well. This would be easy to do for the simple use case of "register this concrete class for this interface" but when you start dealing with the edge cases, like dealing with dependencies for the component registrations, it starts getting messy. NSB has an abstraction like this and I wrestled for quite a bit trying to implement an Autofac adapter for it. I'll think about it some more...could be doable, but in the end I don't know how much value it could really provide.
On Sat, Apr 4, 2009 at 1:40 AM, Simone Busoli <[email protected]> wrote: > > Have you seen CommonServiceLocator? Would it fit? > > 2009/4/4, Matt Burton <[email protected]>: >> >> Excellent - great stuff - congrats >> >> On Thu, Apr 2, 2009 at 2:46 PM, Ayende Rahien <[email protected]> wrote: >>> Work is now committed on the trunk. >>> Fully integrated with RSB now. >>> Need to do build scripts next. >>> >>> On Thu, Apr 2, 2009 at 3:23 PM, Matt Burton <[email protected]> wrote: >>>> >>>> > doesn't really work, think long running apps :-) >>>> > we have to have this run periodically. >>>> >>>> True, some sort of scavenging process. Hmm...well, if the goal is to >>>> keep it in proc you're pretty much stuck with a thread on a timer, no? >>>> You could write an external process to manage it but then you've >>>> introduced another moving part :( >>>> >>>> > In all honestly, I am not sure how feasible this is. I don't mind that, >>>> > as >>>> > long as someone else does it :) >>>> > It is just that I am afraid about the amount of work that is involved. >>>> > If you will look at RSB now it is just a set of small components that >>>> > are >>>> > being brought together by the facilities that bind them. >>>> >>>> Right - that's what I figured - basically what we'd be looking at is >>>> writing a custom configuration section that's independent of >>>> facilities in Castle. I understand that this flies in the face of the >>>> benefits of facilities, but it'll be required in this case. Not that >>>> hard to write, either...just a pain in the butt compared to creating a >>>> facility. But do it once and done. Then introduce the ServiceLocator >>>> to do DI. I did notice a number of places in the codebase where >>>> Windsor / Microkernel is being accessed pretty deep in the bowels, but >>>> hopefully those can be worked around. I can take a look at it further >>>> this weekend to see how feasible all this really is. >>>> >>>> On Thu, Apr 2, 2009 at 11:47 AM, Ayende Rahien <[email protected]> wrote: >>>> > inline >>>> > >>>> > On Thu, Apr 2, 2009 at 2:25 PM, Matt Burton <[email protected]> >>>> > wrote: >>>> >> >>>> >> LOL - kind of glossed over that part, didn't I? >>>> >> >>>> >> Take 2: what jumps out at me first is based on config, a method that >>>> >> gets called during dispose and recovery. >>>> > >>>> > doesn't really work, think long running apps :-) >>>> > we have to have this run periodically. >>>> > >>>> >> >>>> >> > Yes, a lot of the complexity goes away completely. It is not _just_ >>>> >> > ITransport, we also need to implement ISubscriptionStorage, this is >>>> >> > what >>>> >> > I >>>> >> > am doing now. >>>> >> >>>> >> Right. And then there's the whole ServiceLocator refactoring too, >>>> >> right? Yeah, I know the drill - send you a patch... :) In all >>>> >> seriousness, would you consider a transition like that? Or at least >>>> >> some other abstraction that would allow folks to plug in other IoC >>>> >> containers? >>>> > >>>> > In all honestly, I am not sure how feasible this is. I don't mind that, >>>> > as >>>> > long as someone else does it :) >>>> > It is just that I am afraid about the amount of work that is involved. >>>> > If you will look at RSB now it is just a set of small components that >>>> > are >>>> > being brought together by the facilities that bind them. >>>> > >>>> >> >>>> >> > Integrating everything is going to be... interesting, shall we say? >>>> >> >>>> >> Indeed - that's why I'm thinking a new implementation that does away >>>> >> with the assumptions and restrictions imposed by MSMQ as a transport >>>> >> might be warranted. Right - couple that with the PHT for subscription >>>> >> storage and saga state storage and you've got a nice little simple >>>> >> framework with minimal dependencies. >>>> >> >>>> >> On Thu, Apr 2, 2009 at 11:05 AM, Ayende Rahien <[email protected]> >>>> >> wrote: >>>> >> > inline >>>> >> > >>>> >> > On Thu, Apr 2, 2009 at 1:54 PM, Matt Burton <[email protected]> >>>> >> > wrote: >>>> >> >> >>>> >> >> > Yeah, we probably need both. >>>> >> >> > The problem is deciding where to implement this. >>>> >> >> >>>> >> >> QueueManager configuration DSL? Or even a parameter object passed >>>> >> >> into >>>> >> >> the ctor that has Endpoint, Path, MaxNumberOfMessagesToRetain, >>>> >> >> TimeToRetainMessages as properties - something along those lines? >>>> >> > >>>> >> > Um, no. The issue is where to implement the _cleanup_ logic. :-) >>>> >> > >>>> >> >> >>>> >> >> > That would still work, actually. >>>> >> >> > If your service isn't there, the message will be queued at the >>>> >> >> > source >>>> >> >> > until >>>> >> >> [snip] >>>> >> >> > So you still get the same (very important) quality. >>>> >> >> >>>> >> >> SOLD :) >>>> >> >> >>>> >> >> Thinking about a service bus implementation on top of this you >>>> >> >> could >>>> >> >> make really a lightweight framework - a lot of the complexity in >>>> >> >> RSB >>>> >> >> goes away. (not that there was that much to begin with in >>>> >> >> comparison >>>> >> >> to NSB / MT :) Is it really as simple as an ITransport >>>> >> >> implementation? >>>> >> >> I guess I'm geared towards small, lightweight, single purpose tools >>>> >> >> these days (Autofac, AutoMapper, etc...) - a really simple >>>> >> >> framework >>>> >> >> built directly on top of RQ seems like a winner to me. (of course >>>> >> >> using ServiceLocator for IoC so I can use Autofac ;) Just my >>>> >> >> thoughts... >>>> >> > >>>> >> > Yes, a lot of the complexity goes away completely. It is not _just_ >>>> >> > ITransport, we also need to implement ISubscriptionStorage, this is >>>> >> > what >>>> >> > I >>>> >> > am doing now. >>>> >> > I am implementing that on the PHT, so that is pretty easy. >>>> >> > Integrating everything is going to be... interesting, shall we say? >>>> >> > > >>>> >> > >>>> >> >>>> >> >>>> > >>>> > >>>> > > >>>> > >>>> >>>> >>> >>> >>> > >>> >> >> > >> > > -- > Inviato dal mio dispositivo mobile > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
