You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/07/21 01:47:20 UTC
ServletLauncher, was: svn commit: r424013...
On Jul 20, 2006, at 11:16 AM, kentam@apache.org 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Deployment, was: ServletLauncher, ...
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 21, 2006, at 1:54 PM, Ken Tam wrote:
<snip/>
>
> Working on understanding the deployment code; here's a snippet that's
> unclear to me:
>
> In DeployerImpl.deploy(CompositeComponent<?> parent,
> CompositeDefinition<I> 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)
The ComponentDefinition that is at the root of the deployment does
not have any SCDL associated with it - it was created in memory by
the thing that called the deployer. So at that time there is no
scdlLocation for the deployment context (which is why it is null).
That component is implemented by a SystemCompositeImplementation
which has a name that identifies which composite to use. It also
contains a scdlLocation which is a used by the implementation loader
as a (really really strong) hint on where to find the SCDL. When it
recurses into that composite then the loader pushes that location
into the child context as the scdlLocation that was actually used
(for the purposes or resolving other relative locations).
There is a subtle distinction here about what it means to "deploy" a
composite. As a "type" of thing, a composite is insubstantial and
cannot actually be physically materialized. Instead, you create an
"instance" of a component that is implemented by that type.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ServletLauncher, was: svn commit: r424013...
Posted by Ken Tam <ke...@gmail.com>.
> 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,
CompositeDefinition<I> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ServletLauncher, was: svn commit: r424013...
Posted by Jeremy Boynes <jb...@apache.org>.
On Jul 20, 2006, at 5:14 PM, Ken Tam wrote:
> On 7/20/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On Jul 20, 2006, at 11:16 AM, kentam@apache.org 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ServletLauncher, was: svn commit: r424013...
Posted by Jim Marino <jm...@myromatours.com>.
On Jul 20, 2006, at 5:14 PM, Ken Tam wrote:
> On 7/20/06, Jeremy Boynes <jb...@apache.org> wrote:
>>
>> On Jul 20, 2006, at 11:16 AM, kentam@apache.org 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: ServletLauncher, was: svn commit: r424013...
Posted by Ken Tam <ke...@gmail.com>.
On 7/20/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> On Jul 20, 2006, at 11:16 AM, kentam@apache.org 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org