OSGi host

[Jim Marino <jm...@myromatours.com>]

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 jim.marino@gmail 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org