Simon Laws wrote:
Hi Sebastien
Some questions as I'm not clear on the WAR as a contribution point...
Simon
[snip]
On 10/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
I investigated a little more and the issue is pretty simple: Tuscany
does not scan for .composite files in JARs placed under WEB-INF/lib.
Because, in host-webapp, it's picking up the application root as a folder
based contribution which is contributed to Tuscany. In the folder based
contribution process it won't unpack jars and look for composites. So you
are saying here this behaviour is observed because the contribution
artifacts are now inside a jar and not because the jar happens to be in
WEB-INF/lib.
Let me try to clarify with an example, an SCA contribution "calculator"
packaged as calculator.war.
Tuscany will pick (using "!" to indicate artifact nesting):
- calculator.war!/someDir/Calculator.composite
- calculator.war!/WEB-INF/classes/Calculator.class
- calculator.war!/WEB-INF/lib/someJar.jar!/Calculator.class (the class
will be available but with limitations, we won't detect if it's an SDO
factory for example)
- calculator.war!/someDir/Calculator.wsdl
- calculator.war!/someDir/Calculator.wsdl!calculatorTypes (<-- denoting
an XSD doc contained in a WSDL doc)
Tuscany does not pick:
- calculator.war!/WEB-INF/lib/someJar.jar!/Calculator.composite
- calculator.war!/WEB-INF/lib/someJar.jar!/Calculator.wsdl
This is not consistent :) we should think about what to do about it.
[snip]
I think it just assumes that the WAR will be unpacked into a directory
structure as part of the WAR deployment process.
Unpacking the WAR does not help much, here's calculator.war unpacked:
Tuscany will pick (using "!" to indicate artifact nesting):
- calculator/someDir/Calculator.composite
- calculator/WEB-INF/classes/Calculator.class
- calculator/WEB-INF/lib/someJar.jar!/Calculator.class (the class will
be available but with limitations, we won't detect if it's an SDO
factory for example)
- calculator/someDir/Calculator.wsdl
- calculator/someDir/Calculator.wsdl!calculatorTypes (<-- denoting an
XSD doc contained in a WSDL doc)
Tuscany does not pick:
- calculator/WEB-INF/lib/someJar.jar!/Calculator.composite
- calculator/WEB-INF/lib/someJar.jar!/Calculator.wsdl
Still not consistent :) we should still think about what to do about it.
We currently support the following SCA contribution packaging
schemes:
- A folder, SCA artifacts (.composite, .componentType files etc.) are
placed under the folder or sub-folders.
- A JAR, SCA artifacts are placed directly in the JAR.
- A WAR, SCA artifacts are placed directly in the WAR.
A WAR isn't really a supported contribution scheme in the sense that the
contribution processor knows what to do with WARs.
IMO the contribution processor should be fixed to implement clear semantics:
- Either we do not support WARs, and we're clear about it
- Or we support WARs and then we follow the normal WAR semantics, i.e.
artifacts inside WEB-INF/lib/*.jar are visible and part of the archive.
IIUC what is happening
is that the WAR is deployed to Tomcat (or whatever) which unpacks it to the
file system before the contents are then contributed, by host-webapp, to
Tuscany. Tuscany then treats it as a folder contribution.
I agree with the sentiment that, from a user perspective, they package the
contributed artifacts in a WAR and it then works. Am just trying to get a
grip on what is actually going on here under the covers :-)
We do not support nesting JARs inside JARs
>From the assembly spec
2830 Contributions do not contain other contributions. If the packaging
format is a JAR file that
2831 contains other JAR files (or any similar nesting of other
technologies), the internal files are not
2832 treated as separate SCA contributions
Correct, I am not suggesting to nest SCA contributions.
or JARs inside WARs.
If we consider a WAR to be a contribution format then this falls under this
spec restriction as well which at least seems consistent. If we wanted a JAR
to act as contributions inside a WAR (assuming we don't consider the WAR as
an SCA contribution format) then we would have to change host-webapp to look
for jars instead of (or as well as) folders.
As you noted, considering JARs as nested contributions would violate the
spec. I think that it would be very confusing.
Classes
and resources present in JARs placed inside a WAR under WEB-INF/lib are
available through the Webapp ClassLoader, but SCA artifacts and other
XML artifacts like WSDL and XSD for example need to be placed directly
under the WAR, i.e. not hidden inside a JAR.
Technically it would be easy to adjust the scanning algorithm to include
JARs inside WARs but we would have to consider this carefully as
allowing for nested archives may cause all kinds of complications (not
really technical problems but confusion and complications in the various
use cases for SCA contributions).
Going back to the calculator example that would simply mean that Tuscany
would now correctly pick:
- calculator/WEB-INF/lib/someJar.jar!/Calculator.composite
- calculator/WEB-INF/lib/someJar.jar!/Calculator.wsdl
Last thought for now: At some point we'll need to support J2EE EARs
containing nested EJB and WAR modules. That will introduce one more
level of nesting (still not saying that we should nest SCA contributions
though).
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
