I hope this isn't threadjacking, but I wanted to see if I could generalize this conversation a little bit.
I haven't actually played with Spring integration yet, but I have had to work around the way the CLAP protocol works inside the NRE. When loading classpath resources, it allows you to specify a classloading authority as "system", "thread" or "class". This works, but it feels a bit limiting. In my opinion, the Restlet should be able to simply say "use this classloader" and not have to encode something in the URI or worry about overriding the context class loader. Going a step further, this feels like a concern that is better suited for Inversion of Control design patterns. In other words, I would want to express my URI as "app/scripts/init.groovy" instead of "clap://thread/app/scripts/init.groovy". On the surface, this may seem trivial, but having to specify "thread" as the classloading authority is limiting in that I'm having to hardwire this decision into a URI instead of deferring to the container to tell me where to load resources. So, what I'm wondering is if Richard's comments could be generalized as an RFE for a formal "restlet container" integrated into the NRE? The "restlet container" would allow each restlet to define its own sandbox, including the classloader, restlet context and IoC container. I think the CLAP protocol could then be simplified (or maybe even deprecated) and just defer to the container for URIs that have no scheme. I guess what I'm saying is +1 for Richard's comments, but rethinking this could solve some other design quirks in addition to better Spring integration. Richard Wallace <rwallace <at> thewallacepack.net> writes: > > > > > Hello, > > > > I've looked at the existing Spring integration work that has gone on and > > it looks pretty good. But it doesn't really do what I would like it to > > do. The way understand it, it really is only managing the component, > > application, and routing. >
