On Oct 5, 2006, at 11:28 PM, Jim Marino wrote:
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.
I think the goal here is for a simple solution - if people need
esoteric schemes then OSGi packaging is available.
This may be as simple as loading all dependencies into a isolated
parent anyway and having the builders add the dependencies they want
to share as parents to the application classloader. Parent-first
delegation (assuming the tree is searched before the ones added by
the builders) would result in the common classes being located. If
that works, it's easy for the end-user as they don't need to specify
anything.
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.
I think the proposal above covers both the simple case and the legacy
case (using existing jars).
With the popularity of Eclipse I see more and more artifacts will
become OSGi enabled and hence users will become more familiar with it
and tools will make it easier (if not transparent). However, that's a
future thing.
For portability, OSGi is a standard and that may make it more
acceptable to the OSOA collaboration than another packaging
mechanism. We may be able to persuade them to support both (given the
first allows the use of legacy artifacts as well). That should be a
lively debate :-)
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.
I agree, particularly because it allows the portability of SCA
applications between OSGi and non-OSGI based runtimes.
The other approach is direct deployment using the OSGi host's
deployment mechanisms. I think that may be a feature provided by and
particular to the OSGi integration (perhaps even proprietary to a
specific OSGi implementation - I'd need to check how portable the
service provision/discovery has become).
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
