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]