Hi Joe, There is a plan to add WAR packaging support for NRE in version 1.1 M2. It will let the Restlet component (manager) automatically make the decision for classpath authority for you. Your URIs will look like "war://app/scripts/init.groovy" instead. See details at: http://restlet.tigris.org/issues/show_bug.cgi?id=76
Best regards, Jerome 2007/7/28, Joe Holloway <[EMAIL PROTECTED]>: > > 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. > > > >
