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" <[email protected]>
Sent: Friday, April 17, 2009 7:51 AM
To: <[email protected]>; <[email protected]>
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
