Nicole, Jim - I'm working on a sample now that combines the Spring container with OSGi and Axis2 bindings. As soon as I can get it working, I'll post it to my people.apache.org area for download. Having some issues as Spring appears to be unwilling to resolve a non-java reference (I was attempting to reference an Axis2-bound service from within a Spring bean). It's an interesting use case, and should help us uncover some of the 'challenges' of creating virtual bundles.
Cheers, Joel -----Original Message----- From: Wengatz, Nicole [mailto:[EMAIL PROTECTED] Sent: Monday, November 27, 2006 10:45 AM To: [email protected] Subject: RE: OSGi-Binding: Generation of Bundles Hi Jim, your use case (with Foo, Bar and Application) seems to be doable with virtual bundles. We are going to develop a demo deployer/provisioning service which scans a directory, takes the scdl out of the jar, generates the virtual bundle and installs and starts it. The demo should prove the use case/concept. Do you have any scdl example containing dependencies which we should use as example? The OSGi binding demo should be submitted by Joel. Thanks Nicole -----Original Message----- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: Saturday, November 25, 2006 8:33 PM To: [email protected] Subject: Re: OSGi-Binding: Generation of Bundles Hi Nicole, Comments below. One general thing is if you have code it is better to submit it as small patches, even if incomplete, than one big patch. That makes our job committing it a little easier and also allows people to comment or get involved early on. So, even if it is still rough, we could add the code into the sandbox (the likely place if it is a work in progress) or trunk and work on it incrementally. Let me know. Jim On Nov 24, 2006, at 12:37 PM, Wengatz, Nicole wrote: > 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 > I've used the plugin to generate bundles for the OSGi launcher in the trunk and ran into a bunch of problems with it being too aggressive about transitive dependencies (going down to the JDK's internal classes). I haven't used it enough though to have a good opinion either way as whether to use it. That aside, my inclination would be option 2 as you outlined below. > 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. > I'm not sure. What we need is the ability to have the following: There is an Extension which is distributed as two jars, Foo and Bar. Foo contains the "core" extension classes which must be isolated from an application. Bar contains classes an application may use to interact with the extension. Bar would therefore need to be visible to the application and Foo would need to be visible to Bar. It could also be the case that Bar may need to be visible to Foo. Here is what I think this would look like in OSGi: Foo -----> imports Bar Bar -----> imports Foo Application ---> imports Bar I think the best thing would be if we could have virtual bundles created out of the jars. For example, the SCDLs for Foo and Bar would declare their dependencies (the format is being worked on in the spec group for this, Jeremy, do you want to comment more here?). The SCDL information would be loaded and the bundle would be created. The application could work the same way or it could also be a native OSGi bundle, which would mean no virtual bundle would need to be created in that case. Does this seem doable with virtual bundles? Jim > > 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] > --------------------------------------------------------------------- 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] 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]
