Hi guys - answers (and more questions) inline:
-----Original Message-----
From: Wengatz, Nicole [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 10:32 AM
To: tuscany-dev@ws.apache.org
Cc: Jasny, Robert
Subject: RE: OSGi Binding
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).
I've got an Axis2 bundle that we use for apache Muse. I'd like to try
the Knoplerfish bundle. I'll pop out to their site and grab it. Thanks!
>>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?
Well, in equinox, if you try to stop a fragment bundle you get:
org.osgi.framework.BundleException: A fragment bundle cannot be stopped:
[EMAIL PROTECTED]:file:../../../../workspaces/CORONA_SCA/tuscany-binding
-osgi/
You can uninstall/re-install to you hearts content, and that will
require a refresh.
Perhaps this is an equinox problem?
>>One of the major pains of porting existing extensions is the
assumption
>>about
>>file locations.
>I assume you're talking about the scdl files?
Yup. And wsdls. And schema. ;-)
>>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?
Yes.
>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.
It seems like your requirement would be met by just deploying one big
scdl for your application. My view of an OSGi host for Tuscany is
somewhere between an app server (where Tuscany components would
communicate over a remotable interface like WS) and a plain old SCA
composite (where components are directly wired). By supporting multiple
SCA applications in a single OSGi, you can provide a degree of isolation
that isn't possible when dumping everything into a single SCA runtime.
You'll have the ability to stop and restart portions of your SCA
'fabric'. Plus, you can provide fast inter-application communication
using the OSGi service binding mechanism. I thought it was kind of nice!
I really want to stay away from any type of scanning solution, as that
seems antithetical to OSGi's philosophy. Of couse, I'm willing to be
voted down!
>>void doIt(BundleContext context){
>>String APP_FILTER =
>>"(&((objectclass=org.apache.tuscany.sca.osgi.core.ApplicationContextSe
r
>>v
>>ice)(Name="SupplyChainShipper)))";
>> ServiceReference[] refs =
>>context.getServiceReferences("org.apache.tuscany.sca.osgi.core.Applica
t
>>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?
If an SCA component is bound as an OSGi service, all you need to do is
use the typical OSGi service registry code. If an SCA component isn't
bound and an osgi service, but you want to interact with it from
outside, the thought was that you could resolve the SCA context
containing the desired component and invoke it directly.
I'll send you my sample code. That might make it clearer. I'm trying
(really!) to get this stuff back in sync so that I can give Jim another
patch.
Cheers,
Joel
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]
