AW: Make sca-api.jar an OSGi bundle
Hi, I second the proposal of adding OSGi metadata to the jars. Some months ago we had a similar discussion on this list, there we said, that we should not generate OSGi Bundles at build time, but generate OSGi bundles out of the JAR files on the fly. We tried this out (it's easy for simple bundles/Jars), but for bundles that require other bundles it's difficult. We do not have enough information for the mapping to OSGi in the scdl files (e.g. should we use required bundle, import etc. ?) Currently we are talking only about the sca-api.jar, but the next question will be about other jars like axis, which should be used in the OSGi container as well. To keep it simple it would propose to generate the required bundles already at build time. Best regards Nicole -Ursprüngliche Nachricht- Von: Mike Edwards [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 6. Juli 2007 14:45 An: tuscany-dev@ws.apache.org Betreff: Re: Make sca-api.jar an OSGi bundle Venkat, I'm in favour of adding OSGi metadata to relevant jars to enable them to act as OSGi bundles. I think that OSGi is in a different space than other runtimes and that supporting it is a good idea. Other comments inline... Yours, Mike Venkata Krishnan wrote: Hi, This seems ok since you say it does not have side effects for other consumers. However, I wonder if we can keep doing this for accomodating other runtimes as well - am not sure what the others might want or if they'd need something not as simple as this - just postulating here ;-). OSGi is less another runtime and more a whole class of runtimes, so in that sense it is special. OSGi is a framework for organizing runtimes into logical chunks. Many runtimes use OSGi - the most famous being Eclipse. I think that we should make it easy for Tuscany SCA (and SDO for that matter) to fit into a runtime that is using OSGi. To do that ideally requires us to add some OSGi metadata to relevant jar files. Or, seeing it from the other side I wonder if it would be ok to consider specific inclusions in OSGi bundles to facilitate their handling in a SCA runtime. This is looking at it the other way around. I believe that this is the work that Rajini and others are already doing in building an implementation.osgi .../ for Tuscany, to allow stuff built using OSGi to work cleanly within Tuscany. So, from what I am able to comprehend, I'd prefer to avoid this tie in. Maybe we should also hear what others have to say. It is no tie-in. Adding OSGi metadata does not make any of our JARs unusable by anyone else and it does not force the use of OSGi - and the handling of the OSGi metadata in the build process can be pretty simple, I believe. There is a whole separate question about whether we should consider building the whole Tuscany SCA runtime using OSGi. There are merits to that, but also potential downsides - however, we can have a completely separate debate about that some other time, since it has nothing to do with Rajini's current proposal. Thanks - Venkat On 7/6/07, Rajini Sivaram [EMAIL PROTECTED] wrote: Hello, Could we convert sca-api.jar to an OSGi bundle so that bundles used by the OSGi implementation type can import SCA annotations and interfaces? This may be already being addressed in the other OSGi related work, but the change is simple and will enable the support for SCA annotations in OSGi bundles to progress. Converting sca-api.jar to an OSGi bundle would just need the addition of a few entries in the manifest file for the jar, and will not affect any other modules using the jar file as a regular jar. Thank you... Regards, Rajini - 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]
AW: Contribute to SCA-OSGi integration
Hi Graham, I'm still not sure if the proposal is consistent. Let my explain my concerns: Every OSGi container provides an OSGi registry. In the OSGi enterprise expert group we are currently discussing that proxies for other services (e.g. EJB stateless Bean which is accessible via IIOP) will be created and registered in the OSGi registry. From this point of view, your proposal for the implementation.osgi is consistent. But do we want to have different behaviour for different SCA implementations types? Do you expect for example that an implementation.ejb adds remote proxies to the JNDI service? Or what about implementation.net or implementation.c, do we need now a registry for all implementation types? I still think that explicit bindings are better. What do the others on the list think? Thanks Nicole P.S.: Graham, Tim told me today that you are going to be at the F2F in Munich next week. Looking forward to meeting you there :-) -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 17:10 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole, My turn to chip in :-) I think both approaches are valid and tackle two different goals. If I understand correctly, then the binding approach does not hand the responsibility for the OSGi bundles and services to SCA. So this is more of a peer-to-peer runtime view. I think this approach is appealing if you want to keep OSGi outside the SCA domain for either organizational reasons, or because you don't want to model some existing OSGi application in SCA. The implementation.osgi approach is trying to take an SCA assembly view of the problem where you want to describe and manage the assembly of the OSGi assets with other implementation technologies. Here SCA is responsible for managing the OSGi bundles (installation, activation), and ensuring their external dependencies are resolved. I've inlined some additional comments below. On 19/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, I would prefer a solution where you declare explicitly the bindings, not an implicit registration of services. Please find below a snippet of the OSGi prototype provided by Joel some time ago: service name=RetailerService target=RetailerComponent interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer/ referenceRetailerComponent/reference /service component name=RetailerComponent implementation.java class=test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl/ reference name=warehouse target=WarehouseComponentWarehouseComponent/reference /component RetailerComponent will not be registered automatically (without a service). The Service tag provides the information via which binding the RetailerComponent will be accessible, in this case via an OSGi Binding. The SCA runtime detects the OSGi binding and registers the RetailerComponent as OSGi service in the OSGi registry. The Client uses a reference with OSGi binding to access the RetailerService: component name=CustomerComponent implementation.java class=test.sca.osgi.binding.client.impl.CustomerComponentImpl/ reference name=retailer target=RetailerServiceRetailerService/reference /component reference name=RetailerService override=may multiplicity=0..n target=Nothing interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer filter=(objectclass=test.sca.osgi.binding.supplychain.Retailer) immediate=false/ /reference In this case the SCA runtime looks up the Retailer OSGi service in the registry and injects it into the CustomerComponent which is the client. From my point of view we need such an OSGi Binding for the communication of SCA components running in different implementation types. If we have only an OSGi implementation type I would use instead of an OSGi binding the OSGI R4 DS (Declarative Services) or Spring OSGi. Both approaches allow OSGi bundles to talk to SCA components built using different implementation types. For the binding approach it's whatever the service with the OSGi binding is wired to in SCA. For the implementation.osgi approach, it's whatever the component reference is wired to. The runtime needs to make good on this relationship. So, an SCA component with an implementation type of OSGi can be directly wired to an SCA component with an implementation of Java, or BPEL, etc... Questions/Remarks to you proposal: A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. From my point of view the provider (in this case Retailer) should decide how
AW: Contribute to SCA-OSGi integration
Hi Graham, OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) I'm still not sure if I understand your scenario correctly. What do you mean with non-OSGi SCA Component, where will it be declared? My understanding is that the non-OSGi SCA Component will be deployed in another implementation type, e.g. in Java or Spring implementation type. To be able to wire the OSGi SCA Component with the non-OSGi SCA component you will need a binding. The other scenario I could imagine is that you are talking about a simple POJO or Spring Bean which will be injected via Dependency Injection, e.g. in the Spring implementation type or in the OSGi implementation type with Spring-OSGi support. Could you please describe what you have in mind, e.g. where you are planning to declare the non-OSGi SCA Component? Thanks Nicole -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 13. Juni 2007 10:07 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Hi Nicole/Rajini, I'm wondering if there is some confusion over terminology and the scenarios being discussed. I believe Rajini is only referring to OSGi bundles integrated into SCA through an implementation.osgi /. So in these scenarios both components are SCA components. Perhaps for clarity we should refer to the ones implemented using OSGi bundles as OSGi SCA components. So, for scenario 1, I think we have: OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) In this scenario the OSGi SCA Component implementation will look up and expect to find a service in the OSGi Registry. The SCA wiring states that that service is provided by the non-OSGi SCA Component and therefore Tuscany must register a proxy service (a proxy to the non-OSGi SCA Component) in the OSGi Registry. The OSGi SCA Component implementation will be unaware that it is calling a non-OSGi SCA Component. For scenarios 2, I think we have: non-OSGi SCA Component (e.g. POJO) -- local wire -- OSGi SCA Component In this scenario, Tuscany knows that the target component is implemented by an OSGi bundle and it must look-up the target service in the OSGi Registry. Of course, it could easily be me that's confused, but I don't see where bindings come into these scenarios. I do think it would be good to expand the scenarios to include bindings thoughts, and perhaps, Nicole, you could elaborate on the scenarios you describe. For example, I'm not sure the OSGi components you refer to are SCA. I think you may be thinking of more a peer-to-peer view of OSGi and SCA. Regards, Graham. On 12/06/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service
AW: Contribute to SCA-OSGi integration
Hi Rajini, I would prefer a solution where you declare explicitly the bindings, not an implicit registration of services. Please find below a snippet of the OSGi prototype provided by Joel some time ago: service name=RetailerService target=RetailerComponent interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer/ referenceRetailerComponent/reference /service component name=RetailerComponent implementation.java class=test.sca.osgi.binding.retailer_warehouse.impl.RetailerComponentImpl/ reference name=warehouse target=WarehouseComponentWarehouseComponent/reference /component RetailerComponent will not be registered automatically (without a service). The Service tag provides the information via which binding the RetailerComponent will be accessible, in this case via an OSGi Binding. The SCA runtime detects the OSGi binding and registers the RetailerComponent as OSGi service in the OSGi registry. The Client uses a reference with OSGi binding to access the RetailerService: component name=CustomerComponent implementation.java class=test.sca.osgi.binding.client.impl.CustomerComponentImpl/ reference name=retailer target=RetailerServiceRetailerService/reference /component reference name=RetailerService override=may multiplicity=0..n target=Nothing interface.java interface=test.sca.osgi.binding.supplychain.Retailer/ osgi:binding.osgi service=test.sca.osgi.binding.supplychain.Retailer filter=(objectclass=test.sca.osgi.binding.supplychain.Retailer) immediate=false/ /reference In this case the SCA runtime looks up the Retailer OSGi service in the registry and injects it into the CustomerComponent which is the client. From my point of view we need such an OSGi Binding for the communication of SCA components running in different implementation types. If we have only an OSGi implementation type I would use instead of an OSGi binding the OSGI R4 DS (Declarative Services) or Spring OSGi. Questions/Remarks to you proposal: A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. From my point of view the provider (in this case Retailer) should decide how it is accessible, not the client. What happens if Retailer is not declared in the same composite? Are you going to search for matching components in the complete SCA domain? The Customer bundle will lookup the OSGi registry for the retailer as if it were a normal OSGi service. What about dependency injection? Will it also be supported? Looking forward to discussing these topics further with you :-) Best regards Nicole -Ursprüngliche Nachricht- Von: Rajini Sivaram [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 19. Juni 2007 10:04 An: tuscany-dev@ws.apache.org Betreff: Re: Contribute to SCA-OSGi integration Nicole, Here is an example scenario, taken from the supplychain sample in Tuscany. Customer and Warehouse are OSGi bundles, Retailer has a Java implementation. A proxy service is registered in the OSGi registry for the Retailer by the Tuscany OSGi implementation provider when CustomerComponent is processed. The Customer bundle will lookup the OSGi registry for the retailer as if it were a normal OSGi service. The Retailer Java component has its warehouse reference injected by Tuscany with an instance of the Warehouse, which is registered by the Warehouse bundle and looked up by the Tuscany OSGi implementation provider in the OSGi registry. component name=CustomerComponent implementation.osgi bundle=Customer bundleLocation=file:target/Customer.jar / reference name=retailer target=RetailerComponent/ /component component name=RetailerComponent implementation.java class= supplychain.retailer.JavaRetailerComponentImpl / reference name=warehouse target=WarehouseComponent/ /component component name=WarehouseComponent implementation.osgi bundle=Warehouse bundleLocation=file:target/Warehouse.jar / reference name=shipper target=ShipperComponent / /component Thank you... Regards, Rajini On 6/19/07, Wengatz, Nicole [EMAIL PROTECTED] wrote: Hi Graham, OSGi SCA Component -- local wire -- non-OSGi SCA Component (e.g. POJO) I'm still not sure if I understand your scenario correctly. What do you mean with non-OSGi SCA Component, where will it be declared? My understanding is that the non-OSGi SCA Component will be deployed in another implementation type, e.g. in Java or Spring implementation type. To be able to wire the OSGi SCA Component with the non-OSGi SCA component you will need a binding. The other scenario I could imagine is that you are talking about a simple POJO or Spring Bean which
Re: Contribute to SCA-OSGi integration
Hi Rajini, good to hear that you're going to contribute to SCA-OSGi :-) We wrote a paper about the different possibilities of combining OSGi and SCA for the SCA drumbeat end of march. You can find it on the OSOA homepage: http://www.osoa.org/display/Main/SCA+Resources. The paper contains a high level description of the OSGi Binding, implementation type and OSGi host. Would be great to get some comments from you. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. Well, this is one option, but not the only one. If for example the non-OSGi SCA component provides a SOAP service binding, a SOAP proxy will be injected. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. Yes, if the non-OSGi SCA component has declared a reference with OSGi binding. If the OSGi component has declared a JMS service binding, the non-OSGi SCA component could use JMS instead of OSGi binding :-) Best regards Nicole Hello, I would like to contribute to the SCA-OSGi integration activities. I have been looking at the existing OSGi binding implementation in Tuscany which exposes SCA services as OSGi services. Even though this binding is no longer working with the latest Tuscany builds, the samples were very useful to understand the scenarios. I was also looking at the notes on the mailing list (they are slightly old - dated Nov 2006) which talk about an OSGi host and also an OSGi implementation type. Is there any ongoing work in these areas? Graham Charters and I have been investigating the use of an OSGi implementation type which will enable existing OSGi bundles to be run as SCA components under Tuscany. We are particulary interested in the scenario where Tuscany is in control. If components of OSGi implementation type are specified in the composite, Tuscany starts up an OSGi runtime and deploys the OSGi bundles corresponding to the components into the OSGi runtime. If there are references from the OSGi component to other non-OSGi SCA components, a proxy service is registered by the Tuscany runtime with the OSGi registry so that the OSGi bundles can access these SCA services as normal OSGi services. References from non-OSGi components to OSGi components are resolved by looking up the OSGi registry. We would like to obtain feedback on using this approach and also would like to get involved in the ongoing support for SCA-OSGi integration. Thank you... Regards, Rajini
OSGi Virtual Bundle Creation
Hi Joel, I've come to the conclusion that we need to develop some packaging conventions for deploying apache functionality into OSGi. I'm aware of the Eclipse Orbit project, which is providing some common packaging of Apache (and other non-eclipse) projects for consumption within Eclipse. Is this something that Apache should be doing for itself, either on a per-project basis, or under the province of a project like Felix? I believe that if we adopt some common conventions, it'd make generating virtual bundles (and supporting OSGi as an optional deployment target in general) a good bit easier. I agree fully, that we have to define some conventions. I had a look to the Apache bundles in the sample and found (at least) the following different types: 1) Bundle which contains a JAR File, all packages will be exported. Example: org.apache.commons.logging_1.1.0 Plugin 2) Bundle which contains a JAR File and requires other bundles and has to import packages Examples: org.apache.neethi Plugin, org.apache.axis2 Plugin 3) Fragment Bundle which contains a JAR file, all packages will be exported Example: org.apache.axiom.dom Plugin How can the OSGi Deployer/Provisioning service know, what type of (virtual) bundle has to be created? The next question I have is about the Tuscany Bindings. I had a look to the OSGi tuscany_databinding_axiom plugin. It has a required Plugin entry for org.apache.axiom.api. This dependency is not part of the SCDL, from where can I get this information at virtual bundle creation time? Any thoughts ? Thanks and best regards Nicole -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 11:01 PM To: tuscany-dev@ws.apache.org Subject: OSGi sample posted Jim, Nicole, I've posted my OSGi sample on my people.apache.org site - http://people.apache.org/~jhawkins/Tuscany/TuscanySample.zip There's a readme that describes the sample and how to run it. I've also included a snapshot of my Eclipse work area. The Tuscany binaries are based on a synch of HEAD performed yesterday. I've got a few things to finish up (like support for scdl imports) before creating a patch I'd be happy with, so please bear with me. I've come to the conclusion that we need to develop some packaging conventions for deploying apache functionality into OSGi. I'm aware of the Eclipse Orbit project, which is providing some common packaging of Apache (and other non-eclipse) projects for consumption within Eclipse. Is this something that Apache should be doing for itself, either on a per-project basis, or under the province of a project like Felix? I believe that if we adopt some common conventions, it'd make generating virtual bundles (and supporting OSGi as an optional deployment target in general) a good bit easier. 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]
RE: OSGi sample posted
Hi Joel, sorry for the late reply. I had a look to your prototype (thanks for providing it), it runs fine on my machine. Some questions/comments: 1) What's the relation between the folder projects and the folder plugins? Is there a maven/ant script to build the content of the plugins folder? I imported the projects into Eclipse and found some compile problems in org.apache.axis2 and tuscany_osgi_sca_binding_axis2. But since the plugins folder does not contain tuscany-osgi-sca-binding-axis2, I got the impression that's not used currently (maybe could be deleted?). 2) The config directory under TuscanySample could be deleted, the configuration directory contains the required configuration, isn't it? 3) Shipper You provided two implementations, Java and Spring. In the implementation (the Java Class) there shouldn't be any difference? Why are the service and reference tags sub-tags of implementation-spring? I thought, implementation, reference and service should be on the same level? 4) WebService Access from Shipper to Customer How does it work exactly? Is the reference entry (SCACustomer) really required? My impression it that the entry property name=customer ref=SCACustomer/ together with the CustomerService.wsdl is enough (at least it still worked after deleting the reference entry in spring_sample.scdl file :-) Thanks and best regards Nicole -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 11:01 PM To: tuscany-dev@ws.apache.org Subject: OSGi sample posted Jim, Nicole, I've posted my OSGi sample on my people.apache.org site - http://people.apache.org/~jhawkins/Tuscany/TuscanySample.zip There's a readme that describes the sample and how to run it. I've also included a snapshot of my Eclipse work area. The Tuscany binaries are based on a synch of HEAD performed yesterday. I've got a few things to finish up (like support for scdl imports) before creating a patch I'd be happy with, so please bear with me. I've come to the conclusion that we need to develop some packaging conventions for deploying apache functionality into OSGi. I'm aware of the Eclipse Orbit project, which is providing some common packaging of Apache (and other non-eclipse) projects for consumption within Eclipse. Is this something that Apache should be doing for itself, either on a per-project basis, or under the province of a project like Felix? I believe that if we adopt some common conventions, it'd make generating virtual bundles (and supporting OSGi as an optional deployment target in general) a good bit easier. 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]
OSGi-Binding: Generation of Bundles
Hi Joel and Jim, I'm trying to find out what's the best way for us to create for the SCA extensions (packaged as JAR) the required OSGi bundles. Currently I see two possibilities: 1) Maven-OSGi-Plugin The Maven OSGi Plugin (under development at the Apache Felix project) allows you to generate OSGi bundles out of standard JARs. You have to configure the path to the manifest (which could be a standard java manifest). Additonal headers like Bundle-ClassPath, Export/Import-Package, Bundle-Activator can be defined. Configuration happens in the pom.xml file. From my point of view we could use it for the OSGi container. The only 'problem' is that the values in the pom.xml have to be hardcoded, we cannot get them easily out of the scdl file. Further information can be found here: http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html 2) Creation of virtual bundles One other possibility which might fit for Tuscany is to generate virtual bundles on the fly out of the JARs. The OSGi-Spring integration provides this virtual bundle functionality, see: http://www.springframework.org/osgi/specification I had a look to the Source Code. The spring-osgi-core bundle provides a class VirtualBundleFactoryBean which allows you to create a bundle. It provides methods to set the version, the artifactId, groupId, exports, imports etc. The bundle does only exist in the RAM, not on the disc, it's virtual. I could imagine having something like an Extension-Directory-Listener-Bundle which read the configured information out of the scdl files in the extension JARs and creates via the VirtualBundleFactoryBean for every extension a bundle. Does every extension bundle require its own bundle context? I'm asking because this might be difficult to achieve with this approach. What do you think, can we use one of the proposed possibilities? Thanks Nicole - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bundles and OSGi
Hi Joel,
I have some problems to get your latest prototype running.
In the source files I got from you the OSGiHost seems to be packaged in
spi.host, e.g.:
import org.apache.tuscany.spi.host.OSGiHost in class OSGiReference
In my installation it's in:
org.apache.tuscany.host.osgi.OSGiHost;
What's the right location?
This difference caused some problems with the Manifests. I was
not able to start the Equinox bundle and the binding-osgi could
not import the OSGiHost. After adapting manifests and source files
I was able to start the four tuscany-osgi bundles :-)
BUT, when starting the test bundles, I get the following exception:
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://tuscany.apache.org/xmlns/osgi/1.0}binding.osgi
[{http://tuscany.apache.org/xmlns/osgi/1.0}binding.osgi]
Context stack trace: [default_shipper]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImp
l.java:92)
at
org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:84)
at
org.apache.tuscany.core.loader.ServiceLoader.load(ServiceLoader.java:1)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImp
l.java:94)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(Co
mpositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(Co
mpositeLoader.java:1)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImp
l.java:94)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImp
l.java:112)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeL
oader.
loadFromSidefile(CompositeComponentTypeLoader.java:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeL
oader.
load(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeL
oader.
load(CompositeComponentTypeLoader.java:1)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(Load
erRegistryImpl.java:163)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101
)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:7
6)
at
org.apache.tuscany.sca.osgi.core.deployer.OSGiDeployer.deploy(OSGiDeploy
er.java:42)
at
org.apache.tuscany.core.runtime.AbstractRuntime.deployApplicationScdl(Ab
stractRuntime.java:136)
at
org.apache.tuscany.sca.osgi.core.runtime.OSGiRuntime.startApplication(OS
GiRuntime.java:127)
at
org.apache.tuscany.sca.osgi.core.impl.AbstractSCAComponentManager.
addBundleComponents(AbstractSCAComponentManager.java:144)
at
org.apache.tuscany.sca.osgi.core.impl.AbstractSCAComponentManager.
processStartedBundle(AbstractSCAComponentManager.java:173)
at
org.apache.tuscany.sca.osgi.core.impl.AbstractSCAComponentManager.
bundleChanged(AbstractSCAComponentManager.java:189)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent
(BundleContextImpl.java:1206)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventMana
ger.java:189)
at
org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchrono
us(ListenerQueue.java:141)
at
org.eclipse.osgi.framework.internal.core.Framework.publishBundleEvent(Fr
amework.java:1432)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHo
st.java:326)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractB
undle.java:329)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framewor
k.java:1037)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles
(StartLevelManager.java:573)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(Start
LevelManager.java:495)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLev
el(StartLevelManager.java:275)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent
(StartLevelManager.java:455)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventMana
ger.java:189)
at
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventMa
nager.java:291)
It seems that tuscany is not recognizing the OSGi-Binding anymore. Any
idea what could
be the problem?
Thanks
Nicole
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bundles and OSGi
Hi Jeremy, This worries me a little as I would not like to think that the only OSGi implementation that was supported was Eclipse's. When is 4.1 due and/or does, for example, Felix offer something similar to this? BuddyClassLoading is an alternative to the dynamic import feature. It's currently only supported in Eclipse, but the Equinox team is planning to contribute the design specifications for the upcoming OSGi R4.1 release, see: http://wiki.eclipse.org/index.php/OSGi_R4.1_work Therefore I expect that Felix is going to support it as well. But it seems that there is no need to use it for Tuscany, we can probably use required-bundle or dynamic imports. For the generation of bundles 'on the fly' we should hava a look to the Spring-OSGi integration and the maven support. Best regards Nicole -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 2:45 PM To: tuscany-dev@ws.apache.org Subject: RE: Bundles and OSGi Hi Jeremy, I think this investigation is geared more towards optimization for a particular platform, rather than exclusive support. I agree with you that our base target should be the OSGi R4 spec, which currently has broad support in the OSGi community. What Nicole is investigating are possible mechanisms for generating OSGi bundles 'on the fly', so that we can install extensions into an OSGi runtime without necessarily requiring them to be pre-packaged (with full-blown OSGi manifests). This is one of Jim's requests - support for a common extension packaging format regardless of the target runtime. Specialization for a particular OSGi implementation (i.e. using BuddyClassLoaders) doesn't seem unreasonable in that context, so long as we support the general case as well. Of course, if the SCA spec were to embrace and extend the OSGi manifest format... :-) Cheers, Joel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Boynes Sent: Thursday, November 16, 2006 6:45 AM To: tuscany-dev@ws.apache.org Subject: Re: Bundles and OSGi On 11/15/06, Hawkins, Joel [EMAIL PROTECTED] wrote: -Original Message- From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 15, 2006 10:23 AM To: Hawkins, Joel Cc: Jim Marino; Wengatz, Nicole; Jasny, Robert Subject: RE: Bundles and OSGi I performed now some tests with BuddyClassLoader. The core bundle gets an entry 'Eclipse-BuddyPolicy: registered' and the other bundles register at the core bundle. If the core bundle requires classes it searches in the registered buddies. The performance seems to bad a little bit worser (but still in milliseconds). After the core bundle loaded a class from one of the other bundles (e.g. B) you cannot refresh bundle B. If you would like to update bundle B you have to refresh the core and again all bundles get refreshed. BuddyClassLoading is not part of OSGi R4, but part of Eclipse. Eclipse guys are planning to bring it into OSGI R4.1. This worries me a little as I would not like to think that the only OSGi implementation that was supported was Eclipse's. When is 4.1 due and/or does, for example, Felix offer something similar to this? -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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]
RE: OSGi Binding
, when running on OSGi I think it would be good if an extension could be contributed as a pure jar (no OSGi manifest entries) and then have the runtime somehow dynamically export the classes that need to be shared (essentially performing the task of a manifest file). This will allow us to avoid special extension packaging for different runtimes. What do you guys think? Jim Thanks, Joel -Original Message- From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 2:48 AM To: tuscany-dev@ws.apache.org Subject: RE: OSGi Binding Sure. I could be available. Nicole, what Timezone are you in? I'm PST, Joel, I believe you are CST. I'm CET (Germany). Having the IRC in the evening (e.g. 19:00 CET or later) would be fine for me. I assume it's anyway easier for me to attend from home (due to the companies firewall). Best regards Nicole -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 11:14 PM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding On Nov 9, 2006, at 6:44 AM, Hawkins, Joel wrote: I think an IRC might be helpful. Comments below: Sure. I could be available. Nicole, what Timezone are you in? I'm PST, Joel, I believe you are CST. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:12 AM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding ...services. I would also like to avoid proxying the OSGi services if possible. Can you define what you mean by proxying the OSGi service? Sorry if I'm being dense. Are you referring to support for an optimized wire? Yes basically an optimized wire so we don't need to proxy. 2. The OSGi container would isolate SCA application composites according to its classloader semantics. Currently, Tuscany has two composite trees, an application and system tree: Runtime | /\ /\ / Root System Composite / Root Application Composite Why only one root application composite? The code I have today hosts one root system composite and multiple root application composites (applications pretty much correspond to bundles). Sorry, I'm ASCII-art challenged. The above tree could be extended to include multiple leaves. The root application composite can contain 0..n composite children, which would correspond to application deployed in the runtime. I just tried t simplify it here to highlight that there are two sides of the runtime tree. The reason I did this was so that I could name the individual applications (for external management, etc). My reading of the Host API was that there was a Highlander model (there can only be one) when it comes to applications, which makes sense in the context of a web-app deployment, but not as much under OSGi. Yes agreed. We don't have the Highlander model here. App composites would be deployed as children of the root app composite (or children of those children). What made me think that was that the root application composite had a name. The root composites may contain child composites. The system composite tree contains runtime extensions such as Axis. Each composite has its own classloader. This maintains isolation between application composites and runtime extensions.We plan on introducing a multi-parent classloader for system composites. This is arises from the need to support scenarios where application code may need to access dependencies associated with a system extension. For example, application code may need to access classes in Spring. These classes need to be shared with the application composite classloader. We were planning on loading dependencies that needed to be shared in a parent classloader of the system extension classloader. The former classloader would then also become a parent of the application classloader (which would have multiple parents). Comments below at the end of the extension discussion. One issue is going to be reconciling this scheme with OSGi's classloading infrastructure. In relation to this, I was thinking we would want a common packaging mechanism for Tuscany extensions across host environments. For example, the Axis2 extension should not have to be repackaged or modified when deployed on Tomcat or Equinox. Application composites, however, could be bundles. I was thinking there would be one Tuscany runtime deployed to an OSGi container. This would get bootstrapped (as Joel mentioned) by a BundleActivator and would look similar to the web app launcher with one exception. Namely, while the web app launcher boots the runtime in a separate classloader, the BundleActivator would not need to do this and would instead boot Tuscany in the bundle classloader. The Tuscany runtime bundle would consequently have to export classes used by applications such as SCA API
RE: OSGi Binding
Tuesday 8 PST works for me. Thanks Nicole -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 8:05 PM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding Monday early morning is bad for me (I have a meeting starting early). Could we do Tuesday 8PST? I have a similar problem with corporate firewalls. One way I found around this is to tunnel IRC traffic through an SSH connection to an external shell account (Joel, you may be able to use your Apache shell account). I use OS X TunnelManager to automate this and I believe Putty on Windows will work. Of course, I'm not telling anyone to break corporate security policy... :-) If this time doesn't work for people let me know some alternatives that would work. I'll respond to the questions below separately. Jim On Nov 10, 2006, at 7:53 AM, Hawkins, Joel wrote: Hi guys, I'm EST (just barely). Like Nicole, I'm stuck behind a corporate firewall. Today's looking problematic for me. I'm game for either Monday (I'll just work from home) or possibly sometime this weekend. Some questions in the meantime: A runtime can have multiple root system composites, each isolated from another, and each system composite may have multiple root application composites. Do I (finally) have it right? Is it sufficient for the root system composites to be isolated with respect to wiring (in other words, based on visibility of components available within the root system composite), or must they be isolated based on class loaders as well. I'd like to make sure that the fragment bundle solution is insufficient before we go off and re-invent fragment bundles. ;-) Thanks, Joel -Original Message- From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 2:48 AM To: tuscany-dev@ws.apache.org Subject: RE: OSGi Binding Sure. I could be available. Nicole, what Timezone are you in? I'm PST, Joel, I believe you are CST. I'm CET (Germany). Having the IRC in the evening (e.g. 19:00 CET or later) would be fine for me. I assume it's anyway easier for me to attend from home (due to the companies firewall). Best regards Nicole -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 11:14 PM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding On Nov 9, 2006, at 6:44 AM, Hawkins, Joel wrote: I think an IRC might be helpful. Comments below: Sure. I could be available. Nicole, what Timezone are you in? I'm PST, Joel, I believe you are CST. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:12 AM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding ...services. I would also like to avoid proxying the OSGi services if possible. Can you define what you mean by proxying the OSGi service? Sorry if I'm being dense. Are you referring to support for an optimized wire? Yes basically an optimized wire so we don't need to proxy. 2. The OSGi container would isolate SCA application composites according to its classloader semantics. Currently, Tuscany has two composite trees, an application and system tree: Runtime | /\ /\ / Root System Composite / Root Application Composite Why only one root application composite? The code I have today hosts one root system composite and multiple root application composites (applications pretty much correspond to bundles). Sorry, I'm ASCII-art challenged. The above tree could be extended to include multiple leaves. The root application composite can contain 0..n composite children, which would correspond to application deployed in the runtime. I just tried t simplify it here to highlight that there are two sides of the runtime tree. The reason I did this was so that I could name the individual applications (for external management, etc). My reading of the Host API was that there was a Highlander model (there can only be one) when it comes to applications, which makes sense in the context of a web-app deployment, but not as much under OSGi. Yes agreed. We don't have the Highlander model here. App composites would be deployed as children of the root app composite (or children of those children). What made me think that was that the root application composite had a name. The root composites may contain child composites. The system composite tree contains runtime extensions such as Axis. Each composite has its own classloader. This maintains isolation between application composites and runtime extensions.We plan on introducing a multi-parent classloader for system composites. This is arises from the need to support scenarios where application code may need to access dependencies associated with a system extension. For example, application code may need to access classes
RE: OSGi Binding
Hi, thanks for providing the information :-) I like Joels idea to use fragment bundles. Seems to be a good way to solve the classloading challenge. Is there any document available describing the composite trees? @Joel: What exactly is Equinox-specific in your osgi.equinox bundle? Thanks Nicole -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 3:44 PM To: tuscany-dev@ws.apache.org Subject: RE: OSGi Binding I think an IRC might be helpful. Comments below: -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:12 AM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding ...services. I would also like to avoid proxying the OSGi services if possible. Can you define what you mean by proxying the OSGi service? Sorry if I'm being dense. Are you referring to support for an optimized wire? 2. The OSGi container would isolate SCA application composites according to its classloader semantics. Currently, Tuscany has two composite trees, an application and system tree: Runtime | /\ /\ / Root System Composite / Root Application Composite Why only one root application composite? The code I have today hosts one root system composite and multiple root application composites (applications pretty much correspond to bundles). The reason I did this was so that I could name the individual applications (for external management, etc). My reading of the Host API was that there was a Highlander model (there can only be one) when it comes to applications, which makes sense in the context of a web-app deployment, but not as much under OSGi. What made me think that was that the root application composite had a name. The root composites may contain child composites. The system composite tree contains runtime extensions such as Axis. Each composite has its own classloader. This maintains isolation between application composites and runtime extensions.We plan on introducing a multi-parent classloader for system composites. This is arises from the need to support scenarios where application code may need to access dependencies associated with a system extension. For example, application code may need to access classes in Spring. These classes need to be shared with the application composite classloader. We were planning on loading dependencies that needed to be shared in a parent classloader of the system extension classloader. The former classloader would then also become a parent of the application classloader (which would have multiple parents). Comments below at the end of the extension discussion. One issue is going to be reconciling this scheme with OSGi's classloading infrastructure. In relation to this, I was thinking we would want a common packaging mechanism for Tuscany extensions across host environments. For example, the Axis2 extension should not have to be repackaged or modified when deployed on Tomcat or Equinox. Application composites, however, could be bundles. I was thinking there would be one Tuscany runtime deployed to an OSGi container. This would get bootstrapped (as Joel mentioned) by a BundleActivator and would look similar to the web app launcher with one exception. Namely, while the web app launcher boots the runtime in a separate classloader, the BundleActivator would not need to do this and would instead boot Tuscany in the bundle classloader. The Tuscany runtime bundle would consequently have to export classes used by applications such as SCA API. Applications would be deployed as bundles as well. It would be nice if we could listen to bundles coming online and check for SCA scdl (configuration files). If one is found, we load the bundle as an application composite and stick it in the runtime application tree. The classloader for this composite would be the bundle's. The bundle itself would have to import certain SCA packages (i.e. the ones exported by the runtime bundle). I think I've got this. The hard part is going to be figuring out how to deal with extensions. Specifically, in the case I mentioned above where application code needs to reference certain extension classes. I would like to avoid having special packaging for Tuscany extensions when deployed to an OSGi container versus the Servlet container. So, we could deploy the same Axis2 extension to Tuscany on an OSGi container and Tuscany on a Servlet container. This would mean the runtime would have to behave slightly differently depending on this host. In this respect, perhaps what we could do is instead of creating a parent classloader to the extension and also having it as a parent to the application, we could have OSGi manage this? One way to do this would be for a particular extension to use just the bundle classloader and programmatically
RE: OSGi Binding
Sure. I could be available. Nicole, what Timezone are you in? I'm PST, Joel, I believe you are CST. I'm CET (Germany). Having the IRC in the evening (e.g. 19:00 CET or later) would be fine for me. I assume it's anyway easier for me to attend from home (due to the companies firewall). Best regards Nicole -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 11:14 PM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding On Nov 9, 2006, at 6:44 AM, Hawkins, Joel wrote: I think an IRC might be helpful. Comments below: Sure. I could be available. Nicole, what Timezone are you in? I'm PST, Joel, I believe you are CST. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 1:12 AM To: tuscany-dev@ws.apache.org Subject: Re: OSGi Binding ...services. I would also like to avoid proxying the OSGi services if possible. Can you define what you mean by proxying the OSGi service? Sorry if I'm being dense. Are you referring to support for an optimized wire? Yes basically an optimized wire so we don't need to proxy. 2. The OSGi container would isolate SCA application composites according to its classloader semantics. Currently, Tuscany has two composite trees, an application and system tree: Runtime | /\ /\ / Root System Composite / Root Application Composite Why only one root application composite? The code I have today hosts one root system composite and multiple root application composites (applications pretty much correspond to bundles). Sorry, I'm ASCII-art challenged. The above tree could be extended to include multiple leaves. The root application composite can contain 0..n composite children, which would correspond to application deployed in the runtime. I just tried t simplify it here to highlight that there are two sides of the runtime tree. The reason I did this was so that I could name the individual applications (for external management, etc). My reading of the Host API was that there was a Highlander model (there can only be one) when it comes to applications, which makes sense in the context of a web-app deployment, but not as much under OSGi. Yes agreed. We don't have the Highlander model here. App composites would be deployed as children of the root app composite (or children of those children). What made me think that was that the root application composite had a name. The root composites may contain child composites. The system composite tree contains runtime extensions such as Axis. Each composite has its own classloader. This maintains isolation between application composites and runtime extensions.We plan on introducing a multi-parent classloader for system composites. This is arises from the need to support scenarios where application code may need to access dependencies associated with a system extension. For example, application code may need to access classes in Spring. These classes need to be shared with the application composite classloader. We were planning on loading dependencies that needed to be shared in a parent classloader of the system extension classloader. The former classloader would then also become a parent of the application classloader (which would have multiple parents). Comments below at the end of the extension discussion. One issue is going to be reconciling this scheme with OSGi's classloading infrastructure. In relation to this, I was thinking we would want a common packaging mechanism for Tuscany extensions across host environments. For example, the Axis2 extension should not have to be repackaged or modified when deployed on Tomcat or Equinox. Application composites, however, could be bundles. I was thinking there would be one Tuscany runtime deployed to an OSGi container. This would get bootstrapped (as Joel mentioned) by a BundleActivator and would look similar to the web app launcher with one exception. Namely, while the web app launcher boots the runtime in a separate classloader, the BundleActivator would not need to do this and would instead boot Tuscany in the bundle classloader. The Tuscany runtime bundle would consequently have to export classes used by applications such as SCA API. Applications would be deployed as bundles as well. It would be nice if we could listen to bundles coming online and check for SCA scdl (configuration files). If one is found, we load the bundle as an application composite and stick it in the runtime application tree. The classloader for this composite would be the bundle's. The bundle itself would have to import certain SCA packages (i.e. the ones exported by the runtime bundle). I think I've got this. The hard part is going to be figuring out how to deal with extensions. Specifically, in the case I mentioned above where application code needs to
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).
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: tuscany-dev@ws.apache.org
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
RE: OSGi Binding
Hi Joel, it would be great if you could send us your sample code :-) Playing with the source code will help us to understand. I have some comments to your EMail: I don't want to propose something antithetical to OSGi's philosophy. We had the OSGi R4 Declarative Service(DS) specification in mind. In the bundle manifest you can configure the component.xml files for the components contained in the bundle. The DS 'scans or searches for the component.xml files and is reponsible for the dependency management (as defined in the component.xml files) and activation/registration of components. We thought that the proposed Tuscany runtime service could do something similar to the DS. The next question (which is not easy to answer for me) is if every SCA component should get its own Tuscany runtime. I would say this depends on the view or the level of integration. From my understanding we're currently talking about SCA/Tuscany embedded in OSGi. That's one level of integration. Another level of integration might be an OSGi based SCA container. For SCA embedded in OSGi I have one Tuscany runtime (which consists of a small number of OSGi bundles) in mind and which is able to host many SCA components. For OSGi based SCA container I have an OSGi container in mind, which supports 'out-of-the-box' SCA. We could have an entry in the Manifest pointing to the scdl file (like today a link to the component.xml file). Every OSGi service can use the full feature set of SCA. In addition we have implementation types like an EJB implementation type. The implementation type itself would provided in another OSGi bundle, e.g. an EJB container running in an OSGi bundle. All EJBs will be deployed in the EJB container bundle. This would mean we have SCA components written in EJB technology running in one OSGi bundle and SCA components written in 'OSGi technology' running in separate bundles. Best regards Nicole -Original Message- From: Hawkins, Joel [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 4:55 PM To: tuscany-dev@ws.apache.org Cc: Jasny, Robert Subject: RE: OSGi Binding 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
