On 5/3/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Simon Nash wrote:
> > Here is the complete list of dependencies loaded by the code in
> > tuscany-sca-all-1.0-incubating-SNAPSHOT.jar when starting the
> > Tuscany core runtime.
> >
> > (XML parsing)
> > stax-api-1.0.1.jar
> > wstx-asl-3.2.0.jar
> >
> > (SCA APIs)
> > sca-api-1.0-incubating-SNAPSHOT.jar
> >
> > (used by JettyRuntimeModuleActivator)
> > jetty-util-6.1.0.jar
> > jetty-6.1.0.jar
> > servlet-api-2.5.jar
> >
> > (used by SDOAxiomModuleActivator)
> > axiom-api-1.2.4.jar
> > sdo-api-r2.1-1.0-incubating-SNAPSHOT.jar
> >
> > (used by WSDLInterfaceRuntimeModuleActivator)
> > wsdl4j-1.6.2.jar
> > XmlSchema-1.3.1.jar
> >
> > (used by TomcatRuntimeModuleActivator)
> > catalina-6.0.10.jar
> > coyote-6.0.10.jar
> > juli-6.0.10.jar
> >
> > (used by Axis2ModuleActivator)
> > axis2-kernel-1.2.jar
> > commons-logging-1.1.jar
> > axiom-impl-1.2.4.jar
> >
> > (used by JAXBDataBindingModuleActivator)
> > jaxb-api-2.0.jar
> >
> > I'm concerned about the large number of these. The first 3 cannot
> > reasonably be eliminated. All the others should only be loaded when
> > the extensions that need them are loaded, either based on runtime
> > configuration settings or (preferably) on encountering SCDL that
> > pulls them in.
> >
> > Has anyone been thinking about how to enable a more dynamic approach
> > to optionally pulling in these dependencies? If not, I am happy to
> > look into this further.
> >
> > Simon
> >
> >
> Simon,
>
> I agree with you that we shouldn't always load all extensions and
their
> dependencies.
>
> What you're seeing is a side effect of tuscany-sca-all.jar and
> tuscany-sca-manifest.jar. Tuscany-sca-all.jar is a brute force
approach
> as it munges all the Tuscany code in one JAR and declares the
activation
> of all our extensions in a single file under META-INF/services
generated
> by the build. The result is what you're seeing, all extensions
activated
> at runtime start. If you run applications like we have configured the
> samples in our regular build, you won't run into that issue at all.
>
> I think there's many ways to handle this:
> a) document how to configure the runtime's classpath with the correct
> dependencies, depending on which bindings and component implementation
> types you are planning to run on this runtime.
> b) come up with 3 or 4 more targeted JARs, smaller than
tuscany-sca-all,
> for use in a client, a web server, with or without our most popular
> bindings and component implementation types.
> c) move the META-INF/services/...ModuleActivator file out of the JAR,
> allowing the system administrator to control what gets activated
> d) generate that file from the contents of the composites that a given
> runtime is supposed to be running (this is equivalent to what our
Maven
> WAR plugin was doing before)
> e) remove the 3 lines of code that aggressively start all modules in
> AbstractRuntime.java:157 and make a small change to ModuleActivator
and
> SimpleRuntimeImpl to only start a module as necessary.
>
> I wanted to do (e) later as an optimization but didn't think that
it was
> really necessary right now. We could do it now, if we decide to
continue
> with tuscany-sca-all.jar. However, after having experimented a little
> more with this today, I would actually favor option (b) now. I started
> to prefer option (b) after having loaded some of the samples from the
> distro in Eclipse (to see what the developer experience was going
to be
> and the steps to do it), and I'm not sure I really like to have the
big
> tuscany-sca-all JAR plus all its dependencies loaded in all my Eclipse
> projects...
>
> Thoughts?
+1 to doing (e) right away
Option (b) sounds good but its not trivial to come up with something
good
that keeps things really simple for users. I'd like to see some specific
proposals to discuss before anything is done.
If we were to split Tomcat and Jetty out so we have two different -all-
jar's then we have to document and explain that, describe it in all the
samples etc, and that just starts to make things look complicated to
a new
Tuscany user.
One thing we could do for now is only support Jetty in the all jar and
remove Tomcat. The Tuscany Tomcat module will still be in the modules
directory so its there if anyone wants it.
Another thing to help could be to change the scope of some of the
dependencies to 'provided' so they're not used by default, for
example the
various scripting language engines don't need to always be included
as its
easy enough add the extra js.jar or whatever to the classpath for
samples
that require it. Requiring a user to also add to the classpath the
tuscany-implementation-script jar, the bsf jar the script engine jar and
whatever other dependencies the script requires make things look
complicated
and doesn't sounds so good to me though.
...ant
