J2EE deployment integration was one of the to-do items for the spec
group (it hasn't been done yet). In terms of the scenario you
outlined, I think it would be cleaner to package fragments in the jar
files and the sca.module file in the war. This means there is one
module per war but I think that is the cleanest approach (and it's
what we support with Tomcat) since modules are generally things that
are evolved and deployed together, it avoids having to deal with
child classloaders, and it makes mapping module components to URIs
much easier.
Longer term I don't think this will provide a very robust deployment
model for the scenarios SCA is designed for and we have been looking
at OSGi as a more flexible mechanism. I'm planning
to do an OSGi integration when we finish up with the JavaOne release
if you are interested. I believe others are interested in deploying
to Geronimo so we will need to figure out a broader J2EE deployment
story sometime soon (if you would like to help for Tuscany, just jump
in by proposing some ideas to the list).
Does the first way of packaging outlined above meet your needs?
Jim
On May 1, 2006, at 1:46 PM, meeraj kunnumpurath wrote:
Thanks Jim.
I was also thinking about how an SCA deployment unit would be
loaded within the context of a J2EE container. For example, if two
module JAR files are included in the WEB-INF\lib directory of a WAR
file, then would we need to child classloaders to the WAR
classloader responsible for loading each of the SCA modules. Or is
there a different behaviour expected in terms of classloader
hierarchy as part of the SCA runtime? Also, does SCA assembly model
define how SCA modules are expected to be deployed in a J2EE
environment?
Ta
Meeraj
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: Location of sca.module
Date: Mon, 1 May 2006 13:14:55 -0700
There should be one module file per deployment unit. To get the
intended behavior I believe you want (i.e. a module definition
composed of a number of fragments), use sca.fragment files and
places them in the classpath as they will be merged during load.
On a file system, the directories would just need to be on the
classpath.
That said, the SCA deployment story needs a lot of work (some of
which is currently underway). Having only one "top-level"
sca.module file per deployment unit is a good thing since the URI
is defined there. I'm not too keen on the classpath merge with
multiple fragments and we've discussed a plan to move to more of
an "include" style (i.e. sca.module can include a bunch of
fragments or fragments can "include themselves" into a module).
Let me know if you run into issues with the existing approach or
have ideas on making things better.
Jim
On May 1, 2006, at 7:44 AM, meeraj kunnumpurath wrote:
Hi,
Could someone please shed some light on the expected behaviour
when more than one sca.module file is found within the scope of
the thread context classloader? The spec requires a packaged
module JAR file to have exactly one sca.module file at the root.
Would this require each module JAR to be loaded by its own
classloader. Also, how would this work if the deployemnt unit is
a folder in the file- system?
Thanks in advance
Meeraj
-- _______________________________________________
Search for businesses by name, location, or phone number. -Lycos
Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/
default.asp?SRC=lycos10
--
_______________________________________________
Search for businesses by name, location, or phone number. -Lycos
Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/
default.asp?SRC=lycos10
