On 10/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > 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.
So we see that someJar.jar is a valid artifact of the (in this case) folder based contribution. This artifact is recognized as a java artifact but is left alone in terms of further contribution processing, i.e. the jar is considered as a black box as far as contribution processing is concerned. It is used later by Java but the Tuscany runtime is not expecting to find any SCA artifacts in there. > 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. The spec does go on to say. 2832... It is up to the implementation to determine whether the 2833 internal JAR file should be represented as a single artifact in the contribution hierarchy or 2834 whether all of the contents should be represented as separate artifacts. So we have the freedom to make this happen. It would at least be consistent to index every artifact that is present under the top level contribution regardless of how artifacts are packaged in the contribution. Would we though need to represent the jar as both a single artifact and as separate artifacts, e.g. if it were an OSGi bundle would it need to be presented to OSGi as such. > 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 What you are saying is that it would identify these as artifacts of the contribution. If you them wanted to add the composite to the domain or refer to the WSDL from a binding you could do so. 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). Mmmm, interesting. We either explode them of consider the WAR / EJB as artifacts. A component implemented as a WAR? Possible I guess. -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
