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.


> +
> +        // REVIEW: Not sure how reliable it is to rely on the
> thread context classloader as having
> +        // reasonable semantics across a variety of servlet
> containers.. if "not very", the thread
> +        // context loader works for Tomcat, so perhaps this class
> needs to become container-specific.
> +        launcher.setApplicationLoader(Thread.currentThread
> ().getContextClassLoader());

The TCCL must be set by the app server so this will be consistent.
You might want to wrap it in a doPrivileged block.

Cool -- I looked in the specs, but I couldn't find a guarantee that
the TCCL would be set to a webapp scoped loader during listener
execution, though it seemed like only the natural thing to expect.

I'm about to add a new module under sca/runtime to build a package
very similar to the "standalone" one -- basically it will have all the
same JARs except launcher.jar will be replaced with something that
just has the system SCDL files in it, and without the bin/boot
directory structure.. the idea being that said package could be
unzipped directly into e.g. tomcat's shared/lib or into a WEB-INF/lib
and be immediately used.  Thoughts?
This is great. Now what would be really cool is if we defined a client model for JSP ;-) People have kicked around the idea of modeling JSPs as managed code, specifically components. We could have a taglib with tags similar to JSTL usebean where services would be injected as references into the page context. It would also be interesting if we could allow injection onto a servlet as well but I'm not sure we would have access to the proper hooks in all servlet engines to do that.

Jim

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to