Hi Joel,
I discussed your EMail with my colleague Robert.
We have a lot of questions, I assume because we are new to Tuscany and
SCA :-)
>I'm having issues with the Axis2 binding right now.
What is your use case, using the Axis2 binding to invoke an OSGi
Service from a SCA component running outside of the container?
Have you deployed a SOAP bundle in the OSGi container?
(We're using a SOAP bundle provided by the Knopflerfish project, it runs
in the Equinox container).
>dual classloader hierarchy' requirement
What exactly do you mean? Do we want to have different classloaders
for the bindings and the applications?
>The down side is that we lose the capacity to start and stop
>extension bundles,
Our understanding about fragments bundles is the following:
If OSGi bundle B has defined a 'Fragment-Host: bundle A', bundle A will
have one classloader which will be extended by bundle B's exported
classes
as soon bundle B is started. As much we understood the OSGi spec there's
only
one classloader in bundle A which holds all classes from bundle A as
well from
it's fragment bundle B. How can this help to support the 'dual
classloader hierarchy'
requirement for SCA applications?
Fragment bundles can be started and stopped independently from their
host bundle.
If you stop a fragment bundle, the host bundle must be refreshed (or
restarted)
to update the host's classloader. Why would we lose the capacity to
start/stop
extension bundles?
>One of the major pains of porting existing extensions is the assumption
about
>file locations.
I assume you're talking about the scdl files?
>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.
If we understand you correctly, this would mean that we have for a
number of x SCA
components, x Tuscany runtimes running in the OSGi container?
We would prefer a solution where exactly one Tuscany runtime is running.
What about having a Tuscany runtime service in the OSGi container
deployed which scans a given
directly for scdl.files (contained in the JARs of the SCA application
composites)?
For every scdl the defined components will be started in the Tuscany
runtime and services
with OSGi binding will be registered automatically in the OSGi registry.
>void doIt(BundleContext context){
>String APP_FILTER =
>"(&((objectclass=org.apache.tuscany.sca.osgi.core.ApplicationContextSer
v
>ice)(Name="SupplyChainShipper)))";
> ServiceReference[] refs =
>context.getServiceReferences("org.apache.tuscany.sca.osgi.core.Applicat
i
>onContextService"
Is there really a need to register the ApplicationContextService is
OSGi?
I thought we could directly register the service interface provided by
the
SCA component. Otherwise I do not understand how a standard OSGi service
is able to get the reference of the SCA service?
Thanks and best regards
Nicole
-----Original Message-----
From: Hawkins, Joel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 9:47 PM
To: [email protected]
Subject: RE: OSGi Binding
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: [email protected]
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
