On 5/15/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Rajini Sivaram wrote: > >> Hello, >> >> Following on from the discussion in thread [1], and based on Sebastien's >> comments [2], we need to make a decision on the best way forward to >> OSGi-enable third party libraries used by Tuscany. >> >> The options we have are: >> >> >> 1. Add OSGi manifest entries to all 3rd party jars in the Tuscany >> distribution. Existing OSGi tools like maven-bundle-plugin and >> maven-pax-plugin can be used to generate these bundles. The new manifest >> entries will not have any impact when Tuscany is run outside OSGi. For >> signed jars and jars with license restrictions, it may be necessary to >> generate a bundle with the jar embedded into it, resulting in separate >> jars >> for OSGi and non-OSGi. But these should hopefully be small in number. >> 2. Use non-OSGi mechanism to enable Tuscany bundles running inside >> OSGi to refer to jars outside OSGi. >> 3. Create virtual bundles on the fly for 3rd party jars. At the >> moment, itest/osgi-tuscany does this using auto-generated naive >> manifests. >> If we are to use virtual bundles going forward, manifest entries for the >> virtual bundles should be created at build time, and stored in one of >> the >> Tuscany jars. >> >> I believe that if we are serious about making OSGi-enablement of Tuscany a >> first class option, we should consider doing 1). For the longer term to >> support versioning of 3rd party jars, 1) will provide a standard OSGi >> mechanism. As more and more 3rd-party libraries are being OSGi-enabled, >> this >> can be seen as an intermediate step which enables users of Tuscany to >> install Tuscany in the same standard OSGi way, into an OSGi runtime. >> > > I agree and think we should do (1) everywhere we can. > > >> 3) works, and looks easier to roll out, but I would imagine that OSGi >> users >> of Tuscany would end up creating their own variants of 1) if we support >> only >> 3). And it feels like a wrapper (or rather it is a wrapper), with >> manifests >> and their matching 3rd party libs stored separately. >> > > How about an interim variation of (3) for the 3rd party JARs that we > initially can't cover with (1):
+1 > For each 3rd party foo.jar, a foo-osgi.jar containing the bundle manifest > that'll turn foo.jar into an OSGi virtual bundle, and I mean a proper bundle > manifest with actual specific imports / exports instead of the naive *. If we were to use virtual bundles in the long term, I would definitely agree that we need proper bundle manifests. But for an interim solution, I am not sure what it buys us (performance perhaps, but not sure yet). If we use maven-bundle-plugin with all defaults (no explicit import/exports etc) to convert foo.jar into foo-osgi.jar, we will get something like: Export-Package: org.foo, org.foo.impl Import-Package: javax.xml.stream, org.bar The naive bundle manifest generated in itest/osgi-tuscany would generate Export-Package: org.foo, org.foo.impl DynamicImport-Package: * In both cases, we export all packages in foo.jar, In the first case, maven-bundle-plugin calculates the actual packages imported by classes in foo.jar, and imports all of them at build time. In the second case, we dont calculate the imports at build time, instead when Foo tries to use XMLStreamReader, the package javax.xml.stream is dynamically imported. In both cases, the same set of import-export wiring will be done by OSGi, only the timing of the wiring is different. The main difference is what happens when Foo tries to load org.bar.impl.Bar using Class.forName. The first one throws an exception, the second one dynamically imports org.bar.impl. Since this is a third party library where we have no control of what is or isn't imported, we have no choice but to add org.bar.impl to the imports in the first one. So I dont really think the second one is as bad as it looks (for an interim solution). > I'm just throwing this up in the air to see any reactions from OSGi-skilled > people in the group :) > > Maybe it's a stupid idea? but that would provide the level of modularity > that we're expecting from OSGi, instead of mashing everything up in a > central tuscany- manifest.jar which pretty much kills the benefits of using > OSGi IMO. Since osgi-tuscany has been changing a lot recently, it may help to summarize what we have at the moment. So here goes: 1. All Tuscany modules are built with OSGi manifest headers using maven-bundle-plugin. So they contain explicit import/exports. Packages are not marked private, so all packages are exported from the modules. Imports are calculated by maven-bundle-plugin, and in some cases, we add additional imports for classes that are dynamically imported using Class.forName. So we now have around 100 bundles corresponding to Tuscany modules (eg. tuscany-contribution-2.0-incubating-SNAPSHOT.jar is an OSGi bundle) 2. Third party jars are installed into OSGi as individual virtual bundles, each with a manifest that exports all packages in the bundle, and imports everything dynamically (DynamicImport-Package: *). So we now have around 100 virtual bundles corresponding to 3rd party jars (eg. xercesImpl-2.8.1.jar becomes a virtual bundle in OSGi) 3. We currently dont have a mechanism to determine which of the 200 bundles from 1) and 2) are required by a sample. Bundle provisioning is orthogonal to how we package bundles in the first place. So we should have a separate discussion on this - should we use OSGi bundle repository (OBR) which is not a standard? SpringSource use their own mechanism, not based on OBR. Anyway, what we have at the moment, is a manifest.jar file in itest/osgi-tuscany, generated in the same way as tuscany-sca-manifest.jar (basically maven does the dependency management). The bundle activator in manifest.jar installs all the bundles referred to in its jar classpath. Tuscany modules are installed as real bundles and 3rd party libs as virtual bundles. So in itest/osgi-tuscany, we have a manifest.jar bundle which installs the entire Tuscany (all 200 bundles). The cut-down version of calculator that Graham is building, uses different maven dependencies (but the same bundle activator) to generate a different manifest.jar. Because the jar classpath is smaller, this installs 60 or so bundles. In both cases, the application installs a single bundle (manifest.jar), which causes the subset of Tuscany referred to in its Jar classpath to be installed into OSGi. This is a temporary solution until we decide on the longer term solution to enable applications to install subsets of Tuscany. I dont believe that we are sacrificing modularity by using this approach since this has no impact on the actual bundles themselves. Personally I would like to convert 3rd party jars into real bundles wherever possible, using virtual bundles with naive manifests generated on the fly for others as an interim solution. But if you still think that we should use proper manifests for virtual bundles as well, we can look into it. > Thoughts? >> >> >> [1] http://markmail.org/message/tybuyxoaddjjrpbx >> [2] http://markmail.org/message/wbuixok3x3hazjqq >> >> Thank you... >> >> Regards, >> >> Rajini >> >> > -- > Jean-Sebastien > -- Thank you... Regards, Rajini
