Joel,
I've done an intial checkin of your patch for OSGi host support. I
did some mods and didn't check in the samples as we have a discussion
ongoing on how best to structure the samples and didn't want to
create more issues for now related to the restructuring.
In terms of changes, we should discuss further but here are some
things I did (besides formatting and things like that):
1. I didn't check in support for OSGi services as component
implementation types. For SCA, our model has typically been that
implementation types are created for artifacts that are deployed and
evolved as part of a composite. Services that are not deployed with
the composite are treated as external and modeled as References. I
think this fits with OSGi as well, whose services are more dynamic in
nature. Given that, I think we should be providing an OSGi binding
that accesses those services as References and publishes SCA
components as OSGi Services.
2. Related to the binding, I started to make a bunch of mods to the
builder and removed the wiring and connector implementation since the
core will provide those now. For example, the core will wire a
Component to a Reference with an OSGi binding and will wire a
Service with an OSGi binding to a target component. I haven't
finished this, but did put some basics in.
3. I added the OSGi project as a runtime project. I was imagining
having a generic OSGi project that provided the binding capabilities
and then platform specific projects for running on various OSGi
implementations such as Equinox, Felix, or Knoplerfish.
4. I started to make specific refactorings in the code to follow some
of the patterns we have in the container. For example, instead of
BundleContextUtil, I was thinking we would have a "system
service" (another SCA component) that is an OSGiHost which allows the
OSGi extension to talk to the OSGI container to do things such as
publish services. I didn't move the code over in BundleContextUtil
yet, though.
5. I also renamed Activator to LauncherActivator as I think the SCA
runtime should be packaged as a bundle and launched through it.
We can discuss the changes in more detail. I think we also need to
figure out a bunch of things, including application deployment,
extension deployment and how classloading will play out. For example,
in our component tree, a composite may have the following classloader
relationships. For system extensions:
Parent Composite Classloader Extension Dependency Classloader(s),
e.g. classes used by an application that uses the extension
|
|
| |
| |
| |
|
|
Composite Extension Classloader
An application composite that uses the extension will have the
following hierarchy:
Parent Application Classloader Composite Extension Classloader
|
|
| |
| |
| |
|
|
Application Composite Classloader
We'll need to map that into OSGi bundles and classloader management.
If you're online tomorrow, I will be happy to chat in more detail.
I'm on googletalk at [EMAIL PROTECTED] or (preferrably) on IRC #tuscany.
Thanks for submitting this and sorry I started to butcher parts of it
so quickly!
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
