That was my thinking. On Sat, Apr 4, 2009 at 8:47 PM, Matt Burton <[email protected]> wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
