Where do you see all this fitting in with the M2 release? I'd like an M2 release real soon, what do you think we need for that and how about leaving all the OSGi stuff for after M2?
...ant On 10/6/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> 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]
