Re: ServletLauncher, was: svn commit: r424013...
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]
Re: ServletLauncher, was: svn commit: r424013...
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. Right, understand the resource/artifact distinction here -- my problem was that I had been under the impression that the classloader injected onto the module implementation was used to load the SCDL (and actually added a comment to that effect.. oops), and so was worried that by using a different mechanism at the top-level for a SCDL file would run into problems when it hit includes. As I grovel through the code I see that SCDL file references are tracked via URLs and included SCDLs have their URL built relative to a parent URL, so the module impl's injected classloader is a red herring. Working on understanding the deployment code; here's a snippet that's unclear to me: In DeployerImpl.deploy(CompositeComponent? parent, CompositeDefinitionI componentDefinition) : DeploymentContext deploymentContext = new RootDeploymentContext(null, xmlFactory, moduleScope, null) For the case where componentDefinition.getImplementation() is an instance of SystemCompositeImplementation, shouldn't the SCDL URL be passed into the RootDeploymentContext? (as opposed to null) 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. I hope to have some thoughts on this later when I free up some brain cycles :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ServletLauncher, was: svn commit: r424013...
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. + +// 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. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletLauncher, was: svn commit: r424013...
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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ServletLauncher, was: svn commit: r424013...
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]
