You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2009/04/15 14:04:04 UTC
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
On Wed, Apr 15, 2009 at 6:01 AM, Vamsavardhana Reddy
<c1...@gmail.com> wrote:
> The contribution classloader for an SCA contribution containing Java EE
> artifacts is not as straight forward as a URL classloader that checks nested
> jars in the contribution for class lookup apart from the classes in the
> archive. Since the scheme used by class loaders for Java EE archives is
> different from the existing ContributionClassLoader (for e.g., in case of a
> WAR archive, the classloader will be using the jars under WEB-INF/lib and
> classes under WEB-INF/classes), we have to come with new class loader
> mechanisms. Currently there is a ContributionClassLoaderProvider utility
> provided through UtilityExtensionPoint and Tuscany is using a
> DefaultContributionClassLoaderProvider.
>
> Some of the ideas that I have are:
> 1. Have the current JavaEE introspection extension point return a class
> loader for the archive introspected.
>
> 2. Have an extension point or a utility to return/resolve(?) a class loader
> based on the URI of the artifact passed as parameter.
>
> Then create a new ContributionClassLoaderProvider to override the default
> one incase the runtime supports Java EE implementation types.
>
> Another aspect that we need to consider is that incase of EAR application,
> there are multiple classloaders at play, like the Application classloader
> with common libraries, EJB classloader with all EJB modules in the EAR and
> one classloader per web module. So, the contribution classloader will have
> to manage more than one classloader under the covers and delegate class
> loading to appropriate class loader.
>
> During the build phase, the Java EE introspection code may be creating
> temporary classloaders (like OpenEJB does at the moment) to obtain the
> metadata required for deployment. And at runtime the classloaders are
> different and in most cases the classes are available in the thread context
> classloader.
>
> It becomes more complicated in the case of nested EARs (i.e., an EAR
> contribution packaging another EAR inside). One way I can think of handling
> this is by viewing the contribution as a heirarchy of logical contributions
> and having implicit imports.
>
> I would like others comments and suggestions so that we can iron out these
> rough edges in contribution classloaders for Java EE contributions.
>
> Thanks,
> Vamsi
>
Hi Vamsi
I'd like to run through and example where this problem is evident. I'm
would expect to see that the resolve fails if it is, for example,
unable to locate a java interface that is say contained within an EJB
jar. Can you point me at a specific example or do I have to make one?
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Wed, Apr 15, 2009 at 7:19 PM, Simon Laws <si...@googlemail.com>wrote:
> On Wed, Apr 15, 2009 at 1:34 PM, Simon Laws <si...@googlemail.com>
> wrote:
> > On Wed, Apr 15, 2009 at 1:24 PM, Vamsavardhana Reddy
> > <c1...@gmail.com> wrote:
> >> I think this problem with locating an interface will not arise in case
> of
> >> EJB jar. Easiest way to recreate this would be to have an interface
> element
> >> under a reference in implementation.web component in a WAR file. You
> can
> >> use one of the web apps from the samples under [1].
> >>
> >> [1]
> https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/samples
> >>
> >> On Wed, Apr 15, 2009 at 5:34 PM, Simon Laws <si...@googlemail.com>
> >> wrote:
> >>>
> >>> On Wed, Apr 15, 2009 at 6:01 AM, Vamsavardhana Reddy
> >>> <c1...@gmail.com> wrote:
> >>> > The contribution classloader for an SCA contribution containing Java
> EE
> >>> > artifacts is not as straight forward as a URL classloader that checks
> >>> > nested
> >>> > jars in the contribution for class lookup apart from the classes in
> the
> >>> > archive. Since the scheme used by class loaders for Java EE archives
> is
> >>> > different from the existing ContributionClassLoader (for e.g., in
> case
> >>> > of a
> >>> > WAR archive, the classloader will be using the jars under WEB-INF/lib
> >>> > and
> >>> > classes under WEB-INF/classes), we have to come with new class loader
> >>> > mechanisms. Currently there is a ContributionClassLoaderProvider
> >>> > utility
> >>> > provided through UtilityExtensionPoint and Tuscany is using a
> >>> > DefaultContributionClassLoaderProvider.
> >>> >
> >>> > Some of the ideas that I have are:
> >>> > 1. Have the current JavaEE introspection extension point return a
> class
> >>> > loader for the archive introspected.
> >>> >
> >>> > 2. Have an extension point or a utility to return/resolve(?) a class
> >>> > loader
> >>> > based on the URI of the artifact passed as parameter.
> >>> >
> >>> > Then create a new ContributionClassLoaderProvider to override the
> >>> > default
> >>> > one incase the runtime supports Java EE implementation types.
> >>> >
> >>> > Another aspect that we need to consider is that incase of EAR
> >>> > application,
> >>> > there are multiple classloaders at play, like the Application
> >>> > classloader
> >>> > with common libraries, EJB classloader with all EJB modules in the
> EAR
> >>> > and
> >>> > one classloader per web module. So, the contribution classloader
> will
> >>> > have
> >>> > to manage more than one classloader under the covers and delegate
> class
> >>> > loading to appropriate class loader.
> >>> >
> >>> > During the build phase, the Java EE introspection code may be
> creating
> >>> > temporary classloaders (like OpenEJB does at the moment) to obtain
> the
> >>> > metadata required for deployment. And at runtime the classloaders
> are
> >>> > different and in most cases the classes are available in the thread
> >>> > context
> >>> > classloader.
> >>> >
> >>> > It becomes more complicated in the case of nested EARs (i.e., an EAR
> >>> > contribution packaging another EAR inside). One way I can think of
> >>> > handling
> >>> > this is by viewing the contribution as a heirarchy of logical
> >>> > contributions
> >>> > and having implicit imports.
> >>> >
> >>> > I would like others comments and suggestions so that we can iron out
> >>> > these
> >>> > rough edges in contribution classloaders for Java EE contributions.
> >>> >
> >>> > Thanks,
> >>> > Vamsi
> >>> >
> >>>
> >>> Hi Vamsi
> >>>
> >>> I'd like to run through and example where this problem is evident. I'm
> >>> would expect to see that the resolve fails if it is, for example,
> >>> unable to locate a java interface that is say contained within an EJB
> >>> jar. Can you point me at a specific example or do I have to make one?
> >>>
> >>> Simon
> >>
> >>
> >>
> >> --
> >> Vamsi
> >>
> >
> > Thanks Vamsi
> >
> > When I said "unable to locate a java interface that is say contained
> > within an EJB jar" what I meant was "unable to local an interface.java
> > which references a java interface contained within an EJB.jar". And
> > I'm particularly thinking of the case where the application composite
> > is in a EAR that contains the EJB jar.
> >
> > I have been looking at the EAR example in itest/contribution-jee but
> > they are failing for me as OpenEJB seems to be struggling with windows
> > back slashes. Does this itest work for you? Also, from my other post,
> > where is the source for the test applications here?
> >
> > Regards
> >
> > Simon
> >
>
> Re. the back slash problem I see you raised
> http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to
> assume you're running with local fixes?
Yes.
>
>
> Any other fixes that I would need to get to the same running state that you
> see?
No.
>
>
> Simon
>
--
Vamsi
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Apr 16, 2009 at 8:47 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Apr 16, 2009 at 8:46 PM, ant elder <an...@gmail.com> wrote:
>>
>>
>> On Thu, Apr 16, 2009 at 6:04 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>>> So, I've put some simple classloader code [1] together to help us
>>> understand the issues. Basically it stores classloaders in
>>> WarModuleInfo and EjbModuleInfo structures and then introduces an SCA
>>> JEE classloader to find the right classes. So back to Vamsi's original
>>> proposal/questions...
>>>
>>> > Some of the ideas that I have are:
>>> > 1. Have the current JavaEE introspection extension point return a class
>>> > loader for the archive introspected.
>>> > 2. Have an extension point or a utility to return/resolve(?) a class
>>> > loader based on the URI of the artifact passed as parameter.
>>>
>>> I took approach 1 here but current the module info structures already
>>> return JEE classes read from the same classloader so returning the
>>> classloader itself seems to unbalance the interface somewhat. Having
>>> access to the separate classloader may allow a solution to the deploy
>>> vs build problem described later but at the moment the new classloader
>>> interface is used at the "resolve" phased which is as close to the
>>> "read" phase as makes no difference.
>>>
>>> > Then create a new ContributionClassLoaderProvider to override the
>>> > default one incase the runtime supports Java EE implementation types.
>>>
>>> Currently the DefaultContributionClassLoaderProvider is not picked up
>>> via the utility extension point so I removed it. This does allow me to
>>> exploit this extension point to install the JEEClassLoaderProvider but
>>> we then couldn't add anything else in the future. Not ideal but OK for
>>> now.
>>>
>>> > Another aspect that we need to consider is that incase of EAR
>>> > application, there are multiple classloaders at play, like the Application
>>> > classloader with common libraries, EJB classloader with all EJB modules
>>> > in the EAR and one classloader per web module. So, the
>>> > contribution classloader will have to manage more than one classloader
>>> > under the covers and delegate class loading to appropriate class loader.
>>>
>>> How to tell which classloader to delegate to? The answer may be that
>>> the class resolution is being performed in the context of a component
>>> whose implementation resolves to a JEE archive (or something in a JEE
>>> archive). However down in the Java class resolution code it doesn't
>>> have this context. Also if we have an EAR with multiple WARs which
>>> each expose references then how to know which SCA reference relates to
>>> which WAR. It may be that there is enough info in the component type
>>> structure to associate a reference with a WAR. I haven't looked yet.
>>> But even if this is the case we would need to be able to feed this
>>> through the interface.java resolution logic which is somewhat
>>> independent at the moment. At the moment my code just looks at the
>>> modules in turn but of course there may be the case that two modules
>>> contain the same class. More investigation required.
>>>
>>> > During the build phase, the Java EE introspection code may be creating
>>> > temporary classloaders (like OpenEJB does at the moment) to obtain
>>> > the metadata required for deployment. And at runtime the classloaders
>>> > are different and in most cases the classes are available in the thread
>>> > context classloader.
>>>
>>> This could be really problematic. The code at the moment assumes that
>>> the classes used to construct the component type are the classes used
>>> at runtime in the binding and wire processing. I don't know what the
>>> proposal is in terms of actually interacting with the runtime is but I
>>> would have to assume that the SCA runtime will be dealing with classes
>>> that the JEE runtime is also dealing with. I don't see how you would
>>> make it work without this. So I can see that it is useful to do
>>> contribution testing with OpenEJB standalone but wouldn't this be
>>> performed by the container if we have an active container. It might be
>>> using OpenEJB also but if what you are saying is that OpenEJB creates
>>> these classloads in the knowledge that it is going to create some more
>>> to actually load and run the JEE artifacts then we have a problem. II
>>> think we need to find a way of getting the runtime classloaders at
>>> component type creation time.
>>>
>>> > It becomes more complicated in the case of nested EARs (i.e., an EAR
>>> > contribution packaging another EAR inside). One way I can think of >
>>> > handling this is by viewing the contribution as a heirarchy of logical
>>> > contributions and having implicit imports.
>>>
>>> We may need a magic JEE import anyhow as this would help us with the
>>> external JEE archive scenario. So worth investigating.
>>>
>>> Simon
>>>
>>> [1]
>>> http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/modules/contribution-jee-impl/src/main/java/org/apache/tuscany/sca/contribution/jee/impl/
>>
>>
>> As an FYI aside there is a project call Cargo for manipulating JEE
>> artifacts and its just had a 1.0 release, maybe it would help.
>>
>> ...ant
>>
>>
>
> ...and the link is http://cargo.codehaus.org/
>
> ...ant
>
>
Thanks for the pointer Ant.
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 16, 2009 at 8:46 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Apr 16, 2009 at 6:04 PM, Simon Laws <si...@googlemail.com>wrote:
>
>> So, I've put some simple classloader code [1] together to help us
>> understand the issues. Basically it stores classloaders in
>> WarModuleInfo and EjbModuleInfo structures and then introduces an SCA
>> JEE classloader to find the right classes. So back to Vamsi's original
>> proposal/questions...
>>
>> > Some of the ideas that I have are:
>> > 1. Have the current JavaEE introspection extension point return a class
>> loader for the archive introspected.
>> > 2. Have an extension point or a utility to return/resolve(?) a class
>> loader based on the URI of the artifact passed as parameter.
>>
>> I took approach 1 here but current the module info structures already
>> return JEE classes read from the same classloader so returning the
>> classloader itself seems to unbalance the interface somewhat. Having
>> access to the separate classloader may allow a solution to the deploy
>> vs build problem described later but at the moment the new classloader
>> interface is used at the "resolve" phased which is as close to the
>> "read" phase as makes no difference.
>>
>> > Then create a new ContributionClassLoaderProvider to override the
>> default one incase the runtime supports Java EE implementation types.
>>
>> Currently the DefaultContributionClassLoaderProvider is not picked up
>> via the utility extension point so I removed it. This does allow me to
>> exploit this extension point to install the JEEClassLoaderProvider but
>> we then couldn't add anything else in the future. Not ideal but OK for
>> now.
>>
>> > Another aspect that we need to consider is that incase of EAR
>> application, there are multiple classloaders at play, like the Application
>> > classloader with common libraries, EJB classloader with all EJB modules
>> in the EAR and one classloader per web module. So, the
>> > contribution classloader will have to manage more than one classloader
>> under the covers and delegate class loading to appropriate class loader.
>>
>> How to tell which classloader to delegate to? The answer may be that
>> the class resolution is being performed in the context of a component
>> whose implementation resolves to a JEE archive (or something in a JEE
>> archive). However down in the Java class resolution code it doesn't
>> have this context. Also if we have an EAR with multiple WARs which
>> each expose references then how to know which SCA reference relates to
>> which WAR. It may be that there is enough info in the component type
>> structure to associate a reference with a WAR. I haven't looked yet.
>> But even if this is the case we would need to be able to feed this
>> through the interface.java resolution logic which is somewhat
>> independent at the moment. At the moment my code just looks at the
>> modules in turn but of course there may be the case that two modules
>> contain the same class. More investigation required.
>>
>> > During the build phase, the Java EE introspection code may be creating
>> temporary classloaders (like OpenEJB does at the moment) to obtain
>> > the metadata required for deployment. And at runtime the classloaders
>> are different and in most cases the classes are available in the thread
>> > context classloader.
>>
>> This could be really problematic. The code at the moment assumes that
>> the classes used to construct the component type are the classes used
>> at runtime in the binding and wire processing. I don't know what the
>> proposal is in terms of actually interacting with the runtime is but I
>> would have to assume that the SCA runtime will be dealing with classes
>> that the JEE runtime is also dealing with. I don't see how you would
>> make it work without this. So I can see that it is useful to do
>> contribution testing with OpenEJB standalone but wouldn't this be
>> performed by the container if we have an active container. It might be
>> using OpenEJB also but if what you are saying is that OpenEJB creates
>> these classloads in the knowledge that it is going to create some more
>> to actually load and run the JEE artifacts then we have a problem. II
>> think we need to find a way of getting the runtime classloaders at
>> component type creation time.
>>
>> > It becomes more complicated in the case of nested EARs (i.e., an EAR
>> contribution packaging another EAR inside). One way I can think of >
>> > handling this is by viewing the contribution as a heirarchy of logical
>> contributions and having implicit imports.
>>
>> We may need a magic JEE import anyhow as this would help us with the
>> external JEE archive scenario. So worth investigating.
>>
>> Simon
>>
>> [1]
>> http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/modules/contribution-jee-impl/src/main/java/org/apache/tuscany/sca/contribution/jee/impl/
>>
>
>
> As an FYI aside there is a project call Cargo for manipulating JEE
> artifacts and its just had a 1.0 release, maybe it would help.
>
> ...ant
>
>
>
...and the link is http://cargo.codehaus.org/
...ant
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 16, 2009 at 6:04 PM, Simon Laws <si...@googlemail.com>wrote:
> So, I've put some simple classloader code [1] together to help us
> understand the issues. Basically it stores classloaders in
> WarModuleInfo and EjbModuleInfo structures and then introduces an SCA
> JEE classloader to find the right classes. So back to Vamsi's original
> proposal/questions...
>
> > Some of the ideas that I have are:
> > 1. Have the current JavaEE introspection extension point return a class
> loader for the archive introspected.
> > 2. Have an extension point or a utility to return/resolve(?) a class
> loader based on the URI of the artifact passed as parameter.
>
> I took approach 1 here but current the module info structures already
> return JEE classes read from the same classloader so returning the
> classloader itself seems to unbalance the interface somewhat. Having
> access to the separate classloader may allow a solution to the deploy
> vs build problem described later but at the moment the new classloader
> interface is used at the "resolve" phased which is as close to the
> "read" phase as makes no difference.
>
> > Then create a new ContributionClassLoaderProvider to override the default
> one incase the runtime supports Java EE implementation types.
>
> Currently the DefaultContributionClassLoaderProvider is not picked up
> via the utility extension point so I removed it. This does allow me to
> exploit this extension point to install the JEEClassLoaderProvider but
> we then couldn't add anything else in the future. Not ideal but OK for
> now.
>
> > Another aspect that we need to consider is that incase of EAR
> application, there are multiple classloaders at play, like the Application
> > classloader with common libraries, EJB classloader with all EJB modules
> in the EAR and one classloader per web module. So, the
> > contribution classloader will have to manage more than one classloader
> under the covers and delegate class loading to appropriate class loader.
>
> How to tell which classloader to delegate to? The answer may be that
> the class resolution is being performed in the context of a component
> whose implementation resolves to a JEE archive (or something in a JEE
> archive). However down in the Java class resolution code it doesn't
> have this context. Also if we have an EAR with multiple WARs which
> each expose references then how to know which SCA reference relates to
> which WAR. It may be that there is enough info in the component type
> structure to associate a reference with a WAR. I haven't looked yet.
> But even if this is the case we would need to be able to feed this
> through the interface.java resolution logic which is somewhat
> independent at the moment. At the moment my code just looks at the
> modules in turn but of course there may be the case that two modules
> contain the same class. More investigation required.
>
> > During the build phase, the Java EE introspection code may be creating
> temporary classloaders (like OpenEJB does at the moment) to obtain
> > the metadata required for deployment. And at runtime the classloaders
> are different and in most cases the classes are available in the thread
> > context classloader.
>
> This could be really problematic. The code at the moment assumes that
> the classes used to construct the component type are the classes used
> at runtime in the binding and wire processing. I don't know what the
> proposal is in terms of actually interacting with the runtime is but I
> would have to assume that the SCA runtime will be dealing with classes
> that the JEE runtime is also dealing with. I don't see how you would
> make it work without this. So I can see that it is useful to do
> contribution testing with OpenEJB standalone but wouldn't this be
> performed by the container if we have an active container. It might be
> using OpenEJB also but if what you are saying is that OpenEJB creates
> these classloads in the knowledge that it is going to create some more
> to actually load and run the JEE artifacts then we have a problem. II
> think we need to find a way of getting the runtime classloaders at
> component type creation time.
>
> > It becomes more complicated in the case of nested EARs (i.e., an EAR
> contribution packaging another EAR inside). One way I can think of >
> > handling this is by viewing the contribution as a heirarchy of logical
> contributions and having implicit imports.
>
> We may need a magic JEE import anyhow as this would help us with the
> external JEE archive scenario. So worth investigating.
>
> Simon
>
> [1]
> http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/modules/contribution-jee-impl/src/main/java/org/apache/tuscany/sca/contribution/jee/impl/
>
As an FYI aside there is a project call Cargo for manipulating JEE artifacts
and its just had a 1.0 release, maybe it would help.
...ant
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
So, I've put some simple classloader code [1] together to help us
understand the issues. Basically it stores classloaders in
WarModuleInfo and EjbModuleInfo structures and then introduces an SCA
JEE classloader to find the right classes. So back to Vamsi's original
proposal/questions...
> Some of the ideas that I have are:
> 1. Have the current JavaEE introspection extension point return a class loader for the archive introspected.
> 2. Have an extension point or a utility to return/resolve(?) a class loader based on the URI of the artifact passed as parameter.
I took approach 1 here but current the module info structures already
return JEE classes read from the same classloader so returning the
classloader itself seems to unbalance the interface somewhat. Having
access to the separate classloader may allow a solution to the deploy
vs build problem described later but at the moment the new classloader
interface is used at the "resolve" phased which is as close to the
"read" phase as makes no difference.
> Then create a new ContributionClassLoaderProvider to override the default one incase the runtime supports Java EE implementation types.
Currently the DefaultContributionClassLoaderProvider is not picked up
via the utility extension point so I removed it. This does allow me to
exploit this extension point to install the JEEClassLoaderProvider but
we then couldn't add anything else in the future. Not ideal but OK for
now.
> Another aspect that we need to consider is that incase of EAR application, there are multiple classloaders at play, like the Application
> classloader with common libraries, EJB classloader with all EJB modules in the EAR and one classloader per web module. So, the
> contribution classloader will have to manage more than one classloader under the covers and delegate class loading to appropriate class loader.
How to tell which classloader to delegate to? The answer may be that
the class resolution is being performed in the context of a component
whose implementation resolves to a JEE archive (or something in a JEE
archive). However down in the Java class resolution code it doesn't
have this context. Also if we have an EAR with multiple WARs which
each expose references then how to know which SCA reference relates to
which WAR. It may be that there is enough info in the component type
structure to associate a reference with a WAR. I haven't looked yet.
But even if this is the case we would need to be able to feed this
through the interface.java resolution logic which is somewhat
independent at the moment. At the moment my code just looks at the
modules in turn but of course there may be the case that two modules
contain the same class. More investigation required.
> During the build phase, the Java EE introspection code may be creating temporary classloaders (like OpenEJB does at the moment) to obtain
> the metadata required for deployment. And at runtime the classloaders are different and in most cases the classes are available in the thread
> context classloader.
This could be really problematic. The code at the moment assumes that
the classes used to construct the component type are the classes used
at runtime in the binding and wire processing. I don't know what the
proposal is in terms of actually interacting with the runtime is but I
would have to assume that the SCA runtime will be dealing with classes
that the JEE runtime is also dealing with. I don't see how you would
make it work without this. So I can see that it is useful to do
contribution testing with OpenEJB standalone but wouldn't this be
performed by the container if we have an active container. It might be
using OpenEJB also but if what you are saying is that OpenEJB creates
these classloads in the knowledge that it is going to create some more
to actually load and run the JEE artifacts then we have a problem. II
think we need to find a way of getting the runtime classloaders at
component type creation time.
> It becomes more complicated in the case of nested EARs (i.e., an EAR contribution packaging another EAR inside). One way I can think of >
> handling this is by viewing the contribution as a heirarchy of logical contributions and having implicit imports.
We may need a magic JEE import anyhow as this would help us with the
external JEE archive scenario. So worth investigating.
Simon
[1] http://svn.apache.org/repos/asf/tuscany/branches/sca-java-1.x/modules/contribution-jee-impl/src/main/java/org/apache/tuscany/sca/contribution/jee/impl/
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Fri, Apr 17, 2009 at 4:28 PM, Simon Laws <si...@googlemail.com>wrote:
> On the issue of finding the correct classloader in the case where
> there are more than on war in an ear.
>
> It may not be a problem in the case that the ear is not sca enhanced
> as the spec doesn't talk about exposing references from wars in this
> case. Don't know if this is a spec issue or not.
It is a spec issue.
>
>
> It still looks like a problem in the case where the ear is sca
> enhanced as it does imply that war references can form part of the
> component type in this case.
>
> Simon
>
--
Vamsi
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
>> Now I have no idea if we support wars inside a contribution (anyone
>> care to comment?). I suspect not at the moment. So I would be more
>> comfortable with documenting a restriction here.
>
> implementation.web is to be used only inside a WAR or an EAR. If the WAR is
> packaged in another contribution, implementation.jee should be used.
>
Interesting Vamsi. I hadn't appreciated from the spec that the archive
attribute of implmementation.jee could refer to a war or ejb jar
archive. I'll add some notes to the scenario list.
As an aside to this I've just checked in changes to allow for
contribution type specific classloading so, using this scheme, an EAR,
WAR or even JAR can all exploit different classloading schemes.
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
On Fri, Apr 17, 2009 at 8:42 PM, Simon Laws <si...@googlemail.com>wrote:
> Ok, well if I can discount the ear as a problematic case due to the
> way that ears are naturally structured then the problematic case
> becomes one of multiple wars in a contribution. I.e.
>
> my.jar - a contribution
> WAR1Nested.war/
> META-INF/
> MANIFEST.MF
> classpath=EJBNested.jar
> WEB-INF
> Web.xml
> lib/
> classes/
> packageb
> ServletA.class
> has reference "serviceReference" of type
> ServiceA.class
> tags/
> page1.jsp
>
> WAR2Nested.war/
> META-INF/
> MANIFEST.MF
> classpath=EJBNested.jar
> WEB-INF
> Web.xml
> lib/
> classes/
> packageb
> ServletA.class
> has reference "serviceReference" of type
> ServiceA.class
> tags/
> page2.jsp
>
> myContribution.contribution
> <component name="componentA">
> <implementation.web web-uri="WAR1Nested.war"/>
> <reference name="serviceReference">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
> <component name="componentB">
> <implementation.web web-uri="WAR2Nested.war"/>
> <reference name="serviceReference">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
>
> Now I have no idea if we support wars inside a contribution (anyone
> care to comment?). I suspect not at the moment. So I would be more
> comfortable with documenting a restriction here.
implementation.web is to be used only inside a WAR or an EAR. If the WAR is
packaged in another contribution, implementation.jee should be used.
> A single war in a
> contribution or indeed the case where the war is the contribution
> don't cause a problem as there is no scope for multi-war classloader
> conflicts.
>
> The promotion case is also OK I think as we only resolve artifacts in
> the scope of their immediate contribution and its imports. Anyone see
> any flaws in this argument?
>
> Simon
>
--
Vamsi
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
snip...
> A war inside a jar
> contribution doesn't seem to me like something we should be trying to
> support, a war inside a zip contribution on the other hand seems
> better.
>
> ...ant
>
OK, well I hadn't caught up with the zip vs jar contribution thread.
Just posted there. In this case I was just thinking "contribution" and
had not considered the jar vs zip vs dir difference. So I'm happy to
discount jar here for the sake of running this thread to ground.
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by ant elder <an...@apache.org>.
On Fri, Apr 17, 2009 at 4:12 PM, Simon Laws <si...@googlemail.com> wrote:
> Ok, well if I can discount the ear as a problematic case due to the
> way that ears are naturally structured then the problematic case
> becomes one of multiple wars in a contribution. I.e.
>
> my.jar - a contribution
> WAR1Nested.war/
> META-INF/
> MANIFEST.MF
> classpath=EJBNested.jar
> WEB-INF
> Web.xml
> lib/
> classes/
> packageb
> ServletA.class
> has reference "serviceReference" of type ServiceA.class
> tags/
> page1.jsp
>
> WAR2Nested.war/
> META-INF/
> MANIFEST.MF
> classpath=EJBNested.jar
> WEB-INF
> Web.xml
> lib/
> classes/
> packageb
> ServletA.class
> has reference "serviceReference" of type ServiceA.class
> tags/
> page2.jsp
>
> myContribution.contribution
> <component name="componentA">
> <implementation.web web-uri="WAR1Nested.war"/>
> <reference name="serviceReference">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
> <component name="componentB">
> <implementation.web web-uri="WAR2Nested.war"/>
> <reference name="serviceReference">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
>
> Now I have no idea if we support wars inside a contribution (anyone
> care to comment?). I suspect not at the moment.
I suspect not too though i've not tried. A war inside a jar
contribution doesn't seem to me like something we should be trying to
support, a war inside a zip contribution on the other hand seems
better.
...ant
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
Ok, well if I can discount the ear as a problematic case due to the
way that ears are naturally structured then the problematic case
becomes one of multiple wars in a contribution. I.e.
my.jar - a contribution
WAR1Nested.war/
META-INF/
MANIFEST.MF
classpath=EJBNested.jar
WEB-INF
Web.xml
lib/
classes/
packageb
ServletA.class
has reference "serviceReference" of type ServiceA.class
tags/
page1.jsp
WAR2Nested.war/
META-INF/
MANIFEST.MF
classpath=EJBNested.jar
WEB-INF
Web.xml
lib/
classes/
packageb
ServletA.class
has reference "serviceReference" of type ServiceA.class
tags/
page2.jsp
myContribution.contribution
<component name="componentA">
<implementation.web web-uri="WAR1Nested.war"/>
<reference name="serviceReference">
<interface.java interface="packagea.ServiceA"/>
</reference>
</component>
<component name="componentB">
<implementation.web web-uri="WAR2Nested.war"/>
<reference name="serviceReference">
<interface.java interface="packagea.ServiceA"/>
</reference>
</component>
Now I have no idea if we support wars inside a contribution (anyone
care to comment?). I suspect not at the moment. So I would be more
comfortable with documenting a restriction here. A single war in a
contribution or indeed the case where the war is the contribution
don't cause a problem as there is no scope for multi-war classloader
conflicts.
The promotion case is also OK I think as we only resolve artifacts in
the scope of their immediate contribution and its imports. Anyone see
any flaws in this argument?
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
I had a chat with Raymond offline on Friday and the bottom line is I
think we need to switch to a classloader strategy that can very
depending on the contribution type as follows.
1/ valid contribution structures (The letters and numbers here refer
to scenarios from the list at [1])
B - EAR is artifact in some contribution (dir, zip, jar etc.) (nested)
E - EAR (WAR or EJB Jar) is a self contained contribution (contrib)
C - EAR is another contribution (other) - same effect as B re. classloading
The implication here is that, as per previous notes on this thread, we
don't deal with the case where a WAR or an EJB Jar appear
independently inside an SCA contribution. Scenarios 1, 2, 4, 7, 8 & 10
are therefore not supported and documented as a restriction
2/ in the case of scenario B the contribution format will be jar, zip,
folder etc and the classloader strategy will be set to be appropriate
to those formats. I.e. similar to what we have at the moment where all
classes are the root of the contribution are loaded. If you need to
reference java resource from interface.java then they need to be
packaged in the contribution itself. We won't pull then from the
nested JEE artifact which is considered isolated from a classloading
point of view. Local message passing is likely to be problematic in
this scenario so should we disallow it?
3/ in the case of scenario E JEE class loader strategies will be in
force for the entire contribution.
4/ The contribution classloader extension point needs to be driven by
the contribution type. We need to record the type of the contribution
based on the extension and possible its contents.
5/ Any classloaders that are provided to load JEE classloaders during
Read/Resolve phases must be the same classloaders as are used by the
JEE container at runtime.
This is an opportunity to remove the contribution structures
dependency on the Java classloader but that may be a change too far
for 1.x so the proposition at the moment is to simply allow the
runtime to choose an appropriate classloader rather than replace the
classloader structures in the runtime.
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration
Re: [DISCUSS] Contribution classloaders when SCA contribution contains Java EE artifacts
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I think we have two things in play here:
1) The SCA contribution: it can be a jar, ear, war, zip, ...
2) The artifacts that are used by the Implementation: for example,
implementation.java references a java class while
implementation.jee/implementation.ejb/implementation.web references a JEE
archive. Typically, the JEE archive is self-contained, and they only have
access to the java classes within the modules following the Class-Path
header in the MANIFEST.MF. What matters is the enclosing module and its
dependencies to other modules.
So we'll have two classloading space, one is the java classes in the
contribution and the other is the java classes packaged in the
implementation artifacts (such as EAR/WAR/JAR).
Now the question is if the java classes in the SCA contribution can be seen
by the implementation artifacts (or componentType) or vice versa (If a
component further configures an implementation with interface.java on either
services or references, or promote a service or reference).
When we develop a JEE application, I don't think we have to know or care if
it's going to be nested into an SCA contribution. From this perspective, any
java classes from the contribution shouldn't have any impacts on the JEE
application itself. If we develop a java component and package it into a jar
as an SCA contribution, the SCA contribution itself is the classloading
space.
Now if we take a JEE application and reuse it in SCA, we can further
configure the interfaces on the component or promotion. By default, we will
inherit the interfaces from the componentType of the JEE app. The java
classes are packaged inside the JEE archive. I also see the opportunity to
override the interface with a java type from the higher level which is not
necessarily visible to the JEE app.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Friday, April 17, 2009 7:51 AM
To: <de...@tuscany.apache.org>; <an...@apache.org>
Subject: Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
>> Is a jar containing nested ear's and war's really a valid thing? We
>> were just discussing jar's containing jar's last week and ruled them
>> out.
>>
>> ...ant
>>
>
> Well in this particular case I was trying to show the ear just as a
> standard thing with wars/jars inside it. As for the ear's relationship
> with the SCA contribution. The spec says
>
> "This specification defines the integration of SCA and Java EE within
> the context of a Java EE application, the use of Java EE components as
> service component implementations, and the deployment of Java EE
> archives either within or as SCA contributions. "
>
> Now, in terms of this particular classloader conundrum it doesn't
> actually make any difference if the ear is the contribution, is inside
> the contribution or indeed is somewhere else. It still comes down to
> the question of whether we need to worry about using war classloaders.
> And if we do how to we distinguish which one to use. I'm trying to
> think of why we would but I'm coming to the conclusion that maybe we
> don't have to. Or is that just wishful thinking?
>
> Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
> Is a jar containing nested ear's and war's really a valid thing? We
> were just discussing jar's containing jar's last week and ruled them
> out.
>
> ...ant
>
Well in this particular case I was trying to show the ear just as a
standard thing with wars/jars inside it. As for the ear's relationship
with the SCA contribution. The spec says
"This specification defines the integration of SCA and Java EE within
the context of a Java EE application, the use of Java EE components as
service component implementations, and the deployment of Java EE
archives either within or as SCA contributions. "
Now, in terms of this particular classloader conundrum it doesn't
actually make any difference if the ear is the contribution, is inside
the contribution or indeed is somewhere else. It still comes down to
the question of whether we need to worry about using war classloaders.
And if we do how to we distinguish which one to use. I'm trying to
think of why we would but I'm coming to the conclusion that maybe we
don't have to. Or is that just wishful thinking?
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by ant elder <an...@gmail.com>.
On Fri, Apr 17, 2009 at 3:34 PM, Simon Laws <si...@googlemail.com> wrote:
> On Fri, Apr 17, 2009 at 11:58 AM, Simon Laws <si...@googlemail.com> wrote:
>> On the issue of finding the correct classloader in the case where
>> there are more than on war in an ear.
>>
>> It may not be a problem in the case that the ear is not sca enhanced
>> as the spec doesn't talk about exposing references from wars in this
>> case. Don't know if this is a spec issue or not.
>>
>> It still looks like a problem in the case where the ear is sca
>> enhanced as it does imply that war references can form part of the
>> component type in this case.
>>
>> Simon
>>
>
> Ok, so here is a more detailed description of a scenario of the type
> that is causing me to think about how to find the right classloader...
>
> my.jar - a contribution
> EARAppcompNestedImplicit.ear
> EJBNested.jar/
> META-INF/
> ejb-jar.xml
> MANIFEST.MF
> packagea/
> ServiceA.class
> ServiceAImpl.class
> WAR1Nested.war/
> META-INF/
> MANIFEST.MF
> classpath=EJBNested.jar
> WEB-INF
> Web.xml
> lib/
> classes/
> packageb
> ServletA.class
> has reference "serviceReference" of type ServiceA.class
> tags/
> page1.jsp
> WAR2Nested.war/
> META-INF/
> MANIFEST.MF
> classpath=EJBNested.jar
> WEB-INF
> Web.xml
> lib/
> classes/
> packageb
> ServletA.class
> has reference "serviceReference" of type ServiceA.class
> tags/
> page2.jsp
> META-INF/
> application.xml
> application.composite
> <component name="componentA">
> <implementation.web web-uri="WAR1Nested.war"/>
> <reference name="serviceReference">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
> <component name="componentB">
> <implementation.web web-uri="WAR2Nested.war"/>
> <reference name="serviceReference">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
> <reference name="reference1" promotes="componentA/serviceReference"/>
> <reference name="reference2" promotes="componentB/serviceReference"/>
>
> myContribution.contribution
> <component name="TopLevelComponent">
> <implementation.jee archive="EARAppcompNestedExplicit.ear"/>
> <reference name="reference1" target="someOtherComponentService">
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> <reference name="reference2" target="someOtherComponentService"/>
> <interface.java interface="packagea.ServiceA"/>
> </reference>
> </component>
>
> Can I rely on the reference types (packagea.ServiceA in this case)
> being in the EAR so that I never have to look in the appropriate WAR
> classloader for them?
>
> The Tuscany runtime is currently coded to resolve interface
> definitions against THE contribution or its imports. It takes no
> account of a situation where the interface may have to be looked up in
> the context of the component/contract that it describes. To the extent
> that the interface model in question has no clue about which
> component/contract it belongs to and classloading only operates at the
> contribution level.
>
> I could of course go in probably pass more information about to look
> up a module/classloader based on the name of the reference and hence
> find the correct WAR that is providing the reference. However I'm a
> little nervous that the JEE people are going to say that typically the
> interface class will be in the ear anyhow so you don't need to bother
> with this. The question is does typically = exclusively. Looking for
> some help from JEE people here.
>
> Simon
>
Is a jar containing nested ear's and war's really a valid thing? We
were just discussing jar's containing jar's last week and ruled them
out.
...ant
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Apr 17, 2009 at 11:58 AM, Simon Laws <si...@googlemail.com> wrote:
> On the issue of finding the correct classloader in the case where
> there are more than on war in an ear.
>
> It may not be a problem in the case that the ear is not sca enhanced
> as the spec doesn't talk about exposing references from wars in this
> case. Don't know if this is a spec issue or not.
>
> It still looks like a problem in the case where the ear is sca
> enhanced as it does imply that war references can form part of the
> component type in this case.
>
> Simon
>
Ok, so here is a more detailed description of a scenario of the type
that is causing me to think about how to find the right classloader...
my.jar - a contribution
EARAppcompNestedImplicit.ear
EJBNested.jar/
META-INF/
ejb-jar.xml
MANIFEST.MF
packagea/
ServiceA.class
ServiceAImpl.class
WAR1Nested.war/
META-INF/
MANIFEST.MF
classpath=EJBNested.jar
WEB-INF
Web.xml
lib/
classes/
packageb
ServletA.class
has reference "serviceReference" of type ServiceA.class
tags/
page1.jsp
WAR2Nested.war/
META-INF/
MANIFEST.MF
classpath=EJBNested.jar
WEB-INF
Web.xml
lib/
classes/
packageb
ServletA.class
has reference "serviceReference" of type ServiceA.class
tags/
page2.jsp
META-INF/
application.xml
application.composite
<component name="componentA">
<implementation.web web-uri="WAR1Nested.war"/>
<reference name="serviceReference">
<interface.java interface="packagea.ServiceA"/>
</reference>
</component>
<component name="componentB">
<implementation.web web-uri="WAR2Nested.war"/>
<reference name="serviceReference">
<interface.java interface="packagea.ServiceA"/>
</reference>
</component>
<reference name="reference1" promotes="componentA/serviceReference"/>
<reference name="reference2" promotes="componentB/serviceReference"/>
myContribution.contribution
<component name="TopLevelComponent">
<implementation.jee archive="EARAppcompNestedExplicit.ear"/>
<reference name="reference1" target="someOtherComponentService">
<interface.java interface="packagea.ServiceA"/>
</reference>
<reference name="reference2" target="someOtherComponentService"/>
<interface.java interface="packagea.ServiceA"/>
</reference>
</component>
Can I rely on the reference types (packagea.ServiceA in this case)
being in the EAR so that I never have to look in the appropriate WAR
classloader for them?
The Tuscany runtime is currently coded to resolve interface
definitions against THE contribution or its imports. It takes no
account of a situation where the interface may have to be looked up in
the context of the component/contract that it describes. To the extent
that the interface model in question has no clue about which
component/contract it belongs to and classloading only operates at the
contribution level.
I could of course go in probably pass more information about to look
up a module/classloader based on the name of the reference and hence
find the correct WAR that is providing the reference. However I'm a
little nervous that the JEE people are going to say that typically the
interface class will be in the ear anyhow so you don't need to bother
with this. The question is does typically = exclusively. Looking for
some help from JEE people here.
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On the issue of finding the correct classloader in the case where
there are more than on war in an ear.
It may not be a problem in the case that the ear is not sca enhanced
as the spec doesn't talk about exposing references from wars in this
case. Don't know if this is a spec issue or not.
It still looks like a problem in the case where the ear is sca
enhanced as it does imply that war references can form part of the
component type in this case.
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Apr 17, 2009 at 2:28 AM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Apr 16, 2009, at 3:11 AM, Simon Laws wrote:
>
> On Wed, Apr 15, 2009 at 9:44 PM, Kevan Miller <ke...@gmail.com>
> wrote:
>
> On Apr 15, 2009, at 9:49 AM, Simon Laws wrote:
>
> Re. the back slash problem I see you raised
>
> http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to
>
> assume you're running with local fixes?
>
> I've fixed this in OpenEJB 3.0.2-SNAPSHOT and 3.1.1-SNAPSHOT. I haven't been
>
> able to deploy the SNAPSHOTs, however. So, you'll have to build locally,
>
> until SNAPSHOTS are available.
>
> --kevan
>
>
> Hey, thanks Kevan.
>
> K. SNAPSHOT is deployed. There's a new patch on TUSCANY-2935.
> --kevan
Thanks Kevan
Re: [DISCUSS] Contribution classloaders when SCA contribution contains Java EE artifacts
Posted by Kevan Miller <ke...@gmail.com>.
On Apr 16, 2009, at 3:11 AM, Simon Laws wrote:
> On Wed, Apr 15, 2009 at 9:44 PM, Kevan Miller
> <ke...@gmail.com> wrote:
>>
>> On Apr 15, 2009, at 9:49 AM, Simon Laws wrote:
>>
>> Re. the back slash problem I see you raised
>> http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to
>> assume you're running with local fixes?
>>
>> I've fixed this in OpenEJB 3.0.2-SNAPSHOT and 3.1.1-SNAPSHOT. I
>> haven't been
>> able to deploy the SNAPSHOTs, however. So, you'll have to build
>> locally,
>> until SNAPSHOTS are available.
>> --kevan
>>
>
> Hey, thanks Kevan.
K. SNAPSHOT is deployed. There's a new patch on TUSCANY-2935.
--kevan
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 15, 2009 at 9:44 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Apr 15, 2009, at 9:49 AM, Simon Laws wrote:
>
> Re. the back slash problem I see you raised
> http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to
> assume you're running with local fixes?
>
> I've fixed this in OpenEJB 3.0.2-SNAPSHOT and 3.1.1-SNAPSHOT. I haven't been
> able to deploy the SNAPSHOTs, however. So, you'll have to build locally,
> until SNAPSHOTS are available.
> --kevan
>
Hey, thanks Kevan.
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution contains Java EE artifacts
Posted by Kevan Miller <ke...@gmail.com>.
On Apr 15, 2009, at 9:49 AM, Simon Laws wrote:
>
> Re. the back slash problem I see you raised
> http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to
> assume you're running with local fixes?
I've fixed this in OpenEJB 3.0.2-SNAPSHOT and 3.1.1-SNAPSHOT. I
haven't been able to deploy the SNAPSHOTs, however. So, you'll have to
build locally, until SNAPSHOTS are available.
--kevan
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 15, 2009 at 1:34 PM, Simon Laws <si...@googlemail.com> wrote:
> On Wed, Apr 15, 2009 at 1:24 PM, Vamsavardhana Reddy
> <c1...@gmail.com> wrote:
>> I think this problem with locating an interface will not arise in case of
>> EJB jar. Easiest way to recreate this would be to have an interface element
>> under a reference in implementation.web component in a WAR file. You can
>> use one of the web apps from the samples under [1].
>>
>> [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/samples
>>
>> On Wed, Apr 15, 2009 at 5:34 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>>> On Wed, Apr 15, 2009 at 6:01 AM, Vamsavardhana Reddy
>>> <c1...@gmail.com> wrote:
>>> > The contribution classloader for an SCA contribution containing Java EE
>>> > artifacts is not as straight forward as a URL classloader that checks
>>> > nested
>>> > jars in the contribution for class lookup apart from the classes in the
>>> > archive. Since the scheme used by class loaders for Java EE archives is
>>> > different from the existing ContributionClassLoader (for e.g., in case
>>> > of a
>>> > WAR archive, the classloader will be using the jars under WEB-INF/lib
>>> > and
>>> > classes under WEB-INF/classes), we have to come with new class loader
>>> > mechanisms. Currently there is a ContributionClassLoaderProvider
>>> > utility
>>> > provided through UtilityExtensionPoint and Tuscany is using a
>>> > DefaultContributionClassLoaderProvider.
>>> >
>>> > Some of the ideas that I have are:
>>> > 1. Have the current JavaEE introspection extension point return a class
>>> > loader for the archive introspected.
>>> >
>>> > 2. Have an extension point or a utility to return/resolve(?) a class
>>> > loader
>>> > based on the URI of the artifact passed as parameter.
>>> >
>>> > Then create a new ContributionClassLoaderProvider to override the
>>> > default
>>> > one incase the runtime supports Java EE implementation types.
>>> >
>>> > Another aspect that we need to consider is that incase of EAR
>>> > application,
>>> > there are multiple classloaders at play, like the Application
>>> > classloader
>>> > with common libraries, EJB classloader with all EJB modules in the EAR
>>> > and
>>> > one classloader per web module. So, the contribution classloader will
>>> > have
>>> > to manage more than one classloader under the covers and delegate class
>>> > loading to appropriate class loader.
>>> >
>>> > During the build phase, the Java EE introspection code may be creating
>>> > temporary classloaders (like OpenEJB does at the moment) to obtain the
>>> > metadata required for deployment. And at runtime the classloaders are
>>> > different and in most cases the classes are available in the thread
>>> > context
>>> > classloader.
>>> >
>>> > It becomes more complicated in the case of nested EARs (i.e., an EAR
>>> > contribution packaging another EAR inside). One way I can think of
>>> > handling
>>> > this is by viewing the contribution as a heirarchy of logical
>>> > contributions
>>> > and having implicit imports.
>>> >
>>> > I would like others comments and suggestions so that we can iron out
>>> > these
>>> > rough edges in contribution classloaders for Java EE contributions.
>>> >
>>> > Thanks,
>>> > Vamsi
>>> >
>>>
>>> Hi Vamsi
>>>
>>> I'd like to run through and example where this problem is evident. I'm
>>> would expect to see that the resolve fails if it is, for example,
>>> unable to locate a java interface that is say contained within an EJB
>>> jar. Can you point me at a specific example or do I have to make one?
>>>
>>> Simon
>>
>>
>>
>> --
>> Vamsi
>>
>
> Thanks Vamsi
>
> When I said "unable to locate a java interface that is say contained
> within an EJB jar" what I meant was "unable to local an interface.java
> which references a java interface contained within an EJB.jar". And
> I'm particularly thinking of the case where the application composite
> is in a EAR that contains the EJB jar.
>
> I have been looking at the EAR example in itest/contribution-jee but
> they are failing for me as OpenEJB seems to be struggling with windows
> back slashes. Does this itest work for you? Also, from my other post,
> where is the source for the test applications here?
>
> Regards
>
> Simon
>
Re. the back slash problem I see you raised
http://issues.apache.org/jira/browse/OPENEJB-1005 so is it safe to
assume you're running with local fixes?
Any other fixes that I would need to get to the same running state that you see?
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 15, 2009 at 1:24 PM, Vamsavardhana Reddy
<c1...@gmail.com> wrote:
> I think this problem with locating an interface will not arise in case of
> EJB jar. Easiest way to recreate this would be to have an interface element
> under a reference in implementation.web component in a WAR file. You can
> use one of the web apps from the samples under [1].
>
> [1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/samples
>
> On Wed, Apr 15, 2009 at 5:34 PM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> On Wed, Apr 15, 2009 at 6:01 AM, Vamsavardhana Reddy
>> <c1...@gmail.com> wrote:
>> > The contribution classloader for an SCA contribution containing Java EE
>> > artifacts is not as straight forward as a URL classloader that checks
>> > nested
>> > jars in the contribution for class lookup apart from the classes in the
>> > archive. Since the scheme used by class loaders for Java EE archives is
>> > different from the existing ContributionClassLoader (for e.g., in case
>> > of a
>> > WAR archive, the classloader will be using the jars under WEB-INF/lib
>> > and
>> > classes under WEB-INF/classes), we have to come with new class loader
>> > mechanisms. Currently there is a ContributionClassLoaderProvider
>> > utility
>> > provided through UtilityExtensionPoint and Tuscany is using a
>> > DefaultContributionClassLoaderProvider.
>> >
>> > Some of the ideas that I have are:
>> > 1. Have the current JavaEE introspection extension point return a class
>> > loader for the archive introspected.
>> >
>> > 2. Have an extension point or a utility to return/resolve(?) a class
>> > loader
>> > based on the URI of the artifact passed as parameter.
>> >
>> > Then create a new ContributionClassLoaderProvider to override the
>> > default
>> > one incase the runtime supports Java EE implementation types.
>> >
>> > Another aspect that we need to consider is that incase of EAR
>> > application,
>> > there are multiple classloaders at play, like the Application
>> > classloader
>> > with common libraries, EJB classloader with all EJB modules in the EAR
>> > and
>> > one classloader per web module. So, the contribution classloader will
>> > have
>> > to manage more than one classloader under the covers and delegate class
>> > loading to appropriate class loader.
>> >
>> > During the build phase, the Java EE introspection code may be creating
>> > temporary classloaders (like OpenEJB does at the moment) to obtain the
>> > metadata required for deployment. And at runtime the classloaders are
>> > different and in most cases the classes are available in the thread
>> > context
>> > classloader.
>> >
>> > It becomes more complicated in the case of nested EARs (i.e., an EAR
>> > contribution packaging another EAR inside). One way I can think of
>> > handling
>> > this is by viewing the contribution as a heirarchy of logical
>> > contributions
>> > and having implicit imports.
>> >
>> > I would like others comments and suggestions so that we can iron out
>> > these
>> > rough edges in contribution classloaders for Java EE contributions.
>> >
>> > Thanks,
>> > Vamsi
>> >
>>
>> Hi Vamsi
>>
>> I'd like to run through and example where this problem is evident. I'm
>> would expect to see that the resolve fails if it is, for example,
>> unable to locate a java interface that is say contained within an EJB
>> jar. Can you point me at a specific example or do I have to make one?
>>
>> Simon
>
>
>
> --
> Vamsi
>
Thanks Vamsi
When I said "unable to locate a java interface that is say contained
within an EJB jar" what I meant was "unable to local an interface.java
which references a java interface contained within an EJB.jar". And
I'm particularly thinking of the case where the application composite
is in a EAR that contains the EJB jar.
I have been looking at the EAR example in itest/contribution-jee but
they are failing for me as OpenEJB seems to be struggling with windows
back slashes. Does this itest work for you? Also, from my other post,
where is the source for the test applications here?
Regards
Simon
Re: [DISCUSS] Contribution classloaders when SCA contribution
contains Java EE artifacts
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
I think this problem with locating an interface will not arise in case of
EJB jar. Easiest way to recreate this would be to have an interface element
under a reference in implementation.web component in a WAR file. You can
use one of the web apps from the samples under [1].
[1] https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/samples
On Wed, Apr 15, 2009 at 5:34 PM, Simon Laws <si...@googlemail.com>wrote:
> On Wed, Apr 15, 2009 at 6:01 AM, Vamsavardhana Reddy
> <c1...@gmail.com> wrote:
> > The contribution classloader for an SCA contribution containing Java EE
> > artifacts is not as straight forward as a URL classloader that checks
> nested
> > jars in the contribution for class lookup apart from the classes in the
> > archive. Since the scheme used by class loaders for Java EE archives is
> > different from the existing ContributionClassLoader (for e.g., in case of
> a
> > WAR archive, the classloader will be using the jars under WEB-INF/lib and
> > classes under WEB-INF/classes), we have to come with new class loader
> > mechanisms. Currently there is a ContributionClassLoaderProvider utility
> > provided through UtilityExtensionPoint and Tuscany is using a
> > DefaultContributionClassLoaderProvider.
> >
> > Some of the ideas that I have are:
> > 1. Have the current JavaEE introspection extension point return a class
> > loader for the archive introspected.
> >
> > 2. Have an extension point or a utility to return/resolve(?) a class
> loader
> > based on the URI of the artifact passed as parameter.
> >
> > Then create a new ContributionClassLoaderProvider to override the default
> > one incase the runtime supports Java EE implementation types.
> >
> > Another aspect that we need to consider is that incase of EAR
> application,
> > there are multiple classloaders at play, like the Application classloader
> > with common libraries, EJB classloader with all EJB modules in the EAR
> and
> > one classloader per web module. So, the contribution classloader will
> have
> > to manage more than one classloader under the covers and delegate class
> > loading to appropriate class loader.
> >
> > During the build phase, the Java EE introspection code may be creating
> > temporary classloaders (like OpenEJB does at the moment) to obtain the
> > metadata required for deployment. And at runtime the classloaders are
> > different and in most cases the classes are available in the thread
> context
> > classloader.
> >
> > It becomes more complicated in the case of nested EARs (i.e., an EAR
> > contribution packaging another EAR inside). One way I can think of
> handling
> > this is by viewing the contribution as a heirarchy of logical
> contributions
> > and having implicit imports.
> >
> > I would like others comments and suggestions so that we can iron out
> these
> > rough edges in contribution classloaders for Java EE contributions.
> >
> > Thanks,
> > Vamsi
> >
>
> Hi Vamsi
>
> I'd like to run through and example where this problem is evident. I'm
> would expect to see that the resolve fails if it is, for example,
> unable to locate a java interface that is say contained within an EJB
> jar. Can you point me at a specific example or do I have to make one?
>
> Simon
>
--
Vamsi