High Nicole, Jim and other OSGi interested guys,
Nicole - I think your usage scenarios all look reasonable. I've been
able to get the local ones working (demoed at Eclipse world), but I
haven't had much luck yet with the remote ones. I'm having issues with
the Axis2 binding right now - I'm hoping they're fixed in the latest
trunk, but it's not building for me at present. :-(
I've been working some on this myself whilst M2 has been winding down -
mainly focusing on the classloader issues. I've come to the following
conclusions:
1. The best way to handle extensions is as fragment bundles. This
greatly simplifies the work required to deal with dependencies, as it
allows us to leverage the OSGi spec to support the 'dual classloader
hierarchy' requirement for SCA applications. The down side is that we
lose the capacity to start and stop extension bundles, but I'm really
not sure how big of a problem that is. We do retain the ability to start
and stop application-level composites, which seems more important to me.
2. One of the major pains of porting existing extensions is the
assumption about file locations. Ideally, an extension or application
packaged as an OSGi bundle would expect resolve resources based on the
bundle. If we could come up with some sort of system service to provide
this function that would be most helpful.
What are your thoughts on config multiplicities in the OSGi runtime?
What I've currently got is a base system config (the set of scdls under
a "tuscany" folder in an equinox bundle), which gets extended by every
fragment bundle with any scdls under their respective "tuscany" folders.
For each bundle with an application composite (scdls under an "sca"
folder), I create a Tuscany runtime using the extended system config,
and run the application composite inside it. Each application composite
gets an OSGi service associated with it (I couldn't think of any better
way for a non-SCA code to run SCA components). The usage looks something
like this (for my supplychain example)
void doIt(BundleContext context){
String APP_FILTER =
"(&((objectclass=org.apache.tuscany.sca.osgi.core.ApplicationContextServ
ice)(Name="SupplyChainShipper)))";
ServiceReference[] refs =
context.getServiceReferences("org.apache.tuscany.sca.osgi.core.Applicati
onContextService", APP_FILTER);
ApplicationContextService service =
ApplicationContextService)context.getService(reference);
Shipper shipper =
service.getAppContext().locateService(Shipper.class, "ShipperService");
shipper.processShipment("Some order");
}
Does this seem reasonable?
I'd like to get this ball rolling again as well. Shame on me for letting
it sit still so long!
Cheers,
Joel
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 1:22 PM
To: tuscany-dev@ws.apache.org
Cc: [EMAIL PROTECTED]
Subject: OSGi Binding
Hi Jim, Joel and other OSGi interested guys,
I would like to support the OSGi<->SCA integration activities.
I wrote down my understanding of the OSGi Binding, e.g. which
integration use cases could be solved with this binding.
It would be great if you could have a look to the attachment and
tell me if you share my thoughts.
I'm looking forward to discussing with you :-)
@Joel: I would like to help you to get the OSGi Binding running. Any
ideas how I could help you?
Thanks and best regards
Nicole
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]
