On Jul 20, 2006, at 5:14 PM, Ken Tam wrote:
On 7/20/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:On Jul 20, 2006, at 11:16 AM, [EMAIL PROTECTED] wrote: > + /** > + * Default application SCDL path used if no > "applicationScdlPath" param is specified > + * > + * REVIEW: this doesn't work as expected right now because we > are using the webapp classloader > + * directly, which doesn't include the root of the webapp. > + */ > + public static final String DEFAULT_APPLICATION_SCDL_PATH = > "WEB-INF/default.scdl"; > + > You can get the URL of the resource from the ServletContext e.g. URL scdl = servletContextEvent.getServletContext().getResource("/ WEB-INF/default.scdl"); note the leading "/" is required.Thought about having a ServletLauncher that extends of Launcher and overrides bootRuntime() to use a different mechanism for SCDL resolution (ie, ServletContext.getResource, not the application classloader, which is the current implied contract for Launcher), but.. I was worried about was doing this to load the initial SCDL, but still having the rest of the code (thinking specifically about the code that handles SCDL includes) use the application classloader and thus resolve differently (or just fail).. haven't gotten around to drilling into that code to see whether it supports different strategies for doing resource loading.
I think we need to be careful of the distinction between resource loading and artifact loading.
At the top level here we are specifying how the primordial SCDL artifact will be loaded - we are defining that it is a resource in WEB-INF and so using a (ServletContext based) resource loader to load it is OK.
However, that SCDL will contain references to other artifacts that may not be resources that are part of the webapp or which may not even be physical resources at all.
There are certain types of artifact that we know that we will need to deal with because they are referenced by the SCA specifications (e.g Java classes, WSDLs) ; there are other types that will be contributed as part of Tuscany extensions (e.g. Groovy scripts).
I think some form of artifact repository will be needed but we should work out the form and the API implementations can use to access it. I've hinted before at possibly basing something on Maven's repository and would be curious what people think.
-- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
