@Joel: What exactly is Equinox-specific in your osgi.equinox bundle?
Thanks
Nicole
-----Original Message-----
From: Hawkins, Joel [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 3:44 PM
To: [email protected]
Subject: RE: OSGi Binding
I think an IRC might be helpful. Comments below:
-----Original Message-----
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 1:12 AM
To: [email protected]
Subject: Re: OSGi Binding
...services. I would also like to avoid proxying the OSGi services if
possible.
Can you define what you mean by proxying the OSGi service? Sorry if
I'm
being dense. Are you referring to support for an optimized wire?
2. The OSGi container would isolate SCA application composites
according to its classloader semantics.
Currently, Tuscany has two composite trees, an application and system
tree:
Runtime
|
/\
/ \
/ Root System Composite
/
Root Application Composite
Why only one root application composite? The code I have today
hosts one
root system composite and multiple root application composites
(applications pretty much correspond to bundles). The reason I did
this
was so that I could "name" the individual applications (for external
management, etc). My reading of the Host API was that there was a
Highlander model (there can only be one) when it comes to
applications,
which makes sense in the context of a web-app deployment, but not as
much under OSGi. What made me think that was that the root application
composite had a name.
The root composites may contain child composites. The system
composite tree contains runtime extensions such as Axis. Each
composite has its own classloader. This maintains isolation between
application composites and runtime extensions.We plan on introducing
a multi-parent classloader for system composites. This is arises from
the need to support scenarios where application code may need to
access dependencies associated with a system extension. For example,
application code may need to access classes in Spring. These classes
need to be shared with the application composite classloader. We were
planning on loading dependencies that needed to be shared in a parent
classloader of the system extension classloader. The former
classloader would then also become a parent of the application
classloader (which would have multiple parents).
Comments below at the end of the extension discussion.
One issue is going to be reconciling this scheme with OSGi's
classloading infrastructure. In relation to this, I was thinking we
would want a common packaging mechanism for Tuscany extensions across
host environments. For example, the Axis2 extension should not have
to be repackaged or modified when deployed on Tomcat or Equinox.
Application composites, however, could be bundles. I was thinking
there would be one Tuscany runtime deployed to an OSGi container.
This would get bootstrapped (as Joel mentioned) by a BundleActivator
and would look similar to the web app launcher with one exception.
Namely, while the web app launcher boots the runtime in a separate
classloader, the BundleActivator would not need to do this and would
instead boot Tuscany in the bundle classloader. The Tuscany runtime
bundle would consequently have to export classes used by
applications such as SCA API.
Applications would be deployed as bundles as well. It would be nice
if we could listen to bundles coming online and check for SCA scdl
(configuration files). If one is found, we load the bundle as an
application composite and stick it in the runtime application tree.
The classloader for this composite would be the bundle's. The bundle
itself would have to import certain SCA packages (i.e. the ones
exported by the runtime bundle).
I think I've got this.
The hard part is going to be figuring out how to deal with
extensions. Specifically, in the case I mentioned above where
application code needs to reference certain extension classes. I
would like to avoid having special packaging for Tuscany extensions
when deployed to an OSGi container versus the Servlet container. So,
we could deploy the same Axis2 extension to Tuscany on an OSGi
container and Tuscany on a Servlet container. This would mean the
runtime would have to behave slightly differently depending on this
host. In this respect, perhaps what we could do is instead of
creating a parent classloader to the extension and also having it as
a parent to the application, we could have OSGi manage this? One way
to do this would be for a particular extension to use just the bundle
classloader and programmatically export packages that need to be
shared (is there an OSGi api to do this, I recall a "dynamic export/
import")? One the application side, the bundle import those packages.
OSGi has a concept known as a Bundle Fragment. A fragment is
packaged as
a separate bundle, but at runtime acts is if it were packaged directly
as part of the host bundle. My thought was to package runtime
extensions
as fragments, and designate the sca kernel bundle as the bundle host.
Add to that a mechanism to populate the system composite tree with the
extensions, and you've got something that (to me) sounds very much
like
what you've described above. Application bundles could specify a
dependency on the sca kernel bundle, at inherit classloader access to
all the extensions as a result.
What this doesn't do is allow you to hide extensions from particular
applications. Is this a requirement? From your diagram above (where
there's a single system composite tree) I'm assuming its not, but of
course I could be wrong :-).
Do you guys think this makes sense? I have some skeletal code checked
into the OSGi and Equinox projects.
Also, I would like to try and get any code checked into the trunk
since this will make things easier. Joel, when you get things synced
back up submit a patch and I can apply it. Similarly, Nicole, if you
have code that could benefit from being checked in, let me know.
I'll get back to the patch. There's some code in there I need to
remove
- it was placed in as part of a demo I did at EclipseWorld that
showed a
sample WSDM integration using a management annotation. Sorry for the
delay on that - swarms of distractions here.
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the
named addressee or an authorized designee, you may not copy or use it,
or disclose it to anyone else. If you received it in error please
notify
us immediately and then destroy it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
