For the webapp host, the default application is contained in the
host environment (e.g. it contains JSPs, Servlets et al that are
part of the webapp). The default composite has a classloader that
is a child of the webapp one so has a classpath that is all the
application code + any <dependency>'s specified in the composite scdl.
In this way we get the isolation we need between the application
code and the runtime implementation.
Where this bites is when there are resources (classes) that need to
be shared between the application programming model and the
implementation. The way in which that happens depends on the nature
of the sharing.
At one level, the easy solution is to introduce those classes into
the host classloader so that they are shared between the
application side and the runtime side. This is what we do with the
SCA API classes, and what a user can do in the webapp host by
adding the classes to the webapp classloader (e.g. by putting them
in WEB-INF/classes or a jar in WEB-INF/lib). There are no problems
with this if the runtime code loads classes correctly (using the
appropriate classloader which is most probably not the TCCL).
A more complex case is where a composite at some arbitrary depth
down the application tree wants to share a class with a system
component (such as an extension) that is at some other arbitrary
depth down the runtime tree. We have two solutions on the table for
this:
1) we can support ordinary jars by adding multi-parent support to
the composite classloader. This would work in conjunction with the
XML dependency mechanism by allowing the dependency to be loaded in
an isolated classloader which would then be one parent of the
runtime component and one parent of the application component. The
extension would determine which resources it wanted to share with
the application and which it would want to keep priviate; for
example, the AXIOM databinding might choose to share axiom-api but
would keep the impl private.
This makes sense. We will need to work out the specifics of how
extension dependencies are marked as visible to application
composites, probably in the dependency element. I don't think we need
to be as granular as OSGi.
2) we can support OSGi bundles using the import/export semantics of
the OSGi classloader. This would require users and extension
providers to package their composites as OSGi bundles.
I'm wondering whether we may want to take a simpler approach. Systems
developers may not have difficulty creating OSGi bundles but this
would be a significant complication for application developers (it
would require them to import extension dependencies in a manifest).
Also, this will mean that applications/extensions packaging would not
be portable across host environments.
For deploying to a OSGi container, we may still want to use the
classloader structuring above and have the Tuscany runtime deployed
in a bundle. Applications and extensions would be deployed to
directories accessible to the directory scanner and they would be
loaded in the context of the runtime bundle. Tuscany would then take
over and impose its classloading hierarchy on the composite trees.
The runtime could use OSGi services by importing them through a
reference configured with an OSGi binding. Likewise, the runtime
could export services to the OSGi host through a service configured
with the OSGi binding. Some system services (e.g. HTTP transport,
work manager, etc.) could be OSGi services that were imported through
the OSGi binding.
The above approach would allow applications and extensions developers
to use a common packaging and deployment model across runtime hosts.
Thoughts?
Jim
IMO we need to do both - although OSGi is very flexible it brings
quite a bit of baggage with it which users may not want to opt in
to. Although more and more resources are making things available as
OSGi bundles not everything does. We also need to support legacy
applications/libraries that do not have the metadata that OSGi
requires.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
