Tuscany runtime dependencies

[Simon Nash <na...@hursley.ibm.com>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Tuscany runtime dependencies

[Jean-Sebastien Delfino <js...@apache.org>]

Simon Laws wrote:
> On 5/3/07, ant elder <an...@gmail.com> wrote:
>>
>> On 5/3/07, Jean-Sebastien Delfino <js...@apache.org> 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
>>
> Some other alternatives...
>
> (f) A first step to (b).Create
> required.jat - all the stuff you need to have
> compatible.jar - all the stuff that can live together but could be 
> split up
> in the future into specific flavours
> ????.jar - jars for the things that we want to optionally include, e.g.
> tomcat/jetty
>
> (g) Alternatively, from (d), use maven to generate jars for each 
> sample. Not
> very flexible if you want to change or extend the sample but what you 
> see is
> what you get. However would probably need some "all" type jars also.
>
> I note that we could use the ant target to generate specific build.xml 
> for
> each sample but this makes the ant script ant like which is maybe not 
> ideal
> and doesn't match binary distro.
>
> So I would certainly make change (e) now. I would happily stick with 
> the all
> jar now but if we have to split it how about (f).
>
> Simon
>

Ok,  I'm going to look into (e), I should have it done some time later 
today or tomorrow morning.

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Tuscany runtime dependencies

[Simon Laws <si...@googlemail.com>]

On 5/3/07, ant elder <an...@gmail.com> wrote:
>
> On 5/3/07, Jean-Sebastien Delfino <js...@apache.org> 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
>
Some other alternatives...

(f) A first step to (b).Create
required.jat - all the stuff you need to have
compatible.jar - all the stuff that can live together but could be split up
in the future into specific flavours
????.jar - jars for the things that we want to optionally include, e.g.
tomcat/jetty

(g) Alternatively, from (d), use maven to generate jars for each sample. Not
very flexible if you want to change or extend the sample but what you see is
what you get. However would probably need some "all" type jars also.

I note that we could use the ant target to generate specific build.xml for
each sample but this makes the ant script ant like which is maybe not ideal
and doesn't match binary distro.

So I would certainly make change (e) now. I would happily stick with the all
jar now but if we have to split it how about (f).

Simon

Re: Tuscany runtime dependencies

[ant elder <an...@gmail.com>]

On 5/3/07, Jean-Sebastien Delfino <js...@apache.org> 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

Re: Tuscany runtime dependencies

[Jean-Sebastien Delfino <js...@apache.org>]

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?

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org