Well, I went ahead and took a look at this and while it is feasible to implement the ServiceLocator I don't think it's really worth it - what you would wind up with is a set of profiles to support per supported IoC container, since the ServiceLocator is just that, a service locator - not an abstraction over the registration of components. You'd need to have the Windsor module that wires up components along with the Autofac, StructureMap, etc... if you needed to add a default component registration you'd be updating each of those, etc... What would be a better approach, it seems, would be an abstraction over IoC like NSB and MT have created, where you can wire in your container of choice, but I don't know if it's really worth it in the end. RSB is opinionated, and part of that includes the stack it's built on - I'd say keep it that way.
On Thu, Apr 2, 2009 at 12: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? >>> > > >>> > >>> >>> >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
