[ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600398#action_12600398 ]
Rajini Sivaram commented on TUSCANY-2343: ----------------------------------------- Am I right in assuming that you are using the 5 bundles generated using itest/osgi-tuscany? These bundles have been superceded by a finer-grained set of (roughly) 200 bundles, where each Tuscany module is converted to a separate bundle, and each third party jar is converted on-the-fly to a separate bundle. itest/osgi-tuscany/tuscany-osgi-installer generates a bundle containing the list of Tuscany modules and 3rd party jars and a bundle activator which installs those. To install Tuscany into an OSGi runtime, you should install and start tuscany-sca-osgi-installer.jar. Does this JIRA correspond to the first issue described in http://markmail.org/message/noszcnhr6shqmjt2 ? If so, could you try out the latest version of itest/osgi-tuscany, using the installer bundle? We haven't yet tackled versioning issues with Tuscany, and clearly the coarse grain bundles which were used earlier cannot handle versioning of individual 3rd party jars. The bundles generated by tuscany-sca-osgi-installer.jar for 3rd party jars are versioned (and the version number is the same as the jar version). So it should enable sharing of jars across Tuscany and applications if the application is able to use the same version as Tuscany. If you want to use a different version of 3rd party jar in the application, and force Tuscany to use that version, you can modify the maven dependencies in the installer to exclude the jar (as long as the versions are compatible). Would this be sufficient to handle your scenario? There is still the outstanding issue of version numbers in Tuscany imports. This will be an issue if we want to provide isolation and force either two Tuscany extensions, or a Tuscany extension and an application to use two different versions of a 3rd party library. As we are only beginning to look at versioning in Tuscany, it will be very useful for us to understand the usage scenarios. The level of versioning we add to import statements in Tuscany modules will really depend on whether we are trying to tackle sharing or isolation of classloaders. Could you give some more detail on the scenario that you are using? > OSGi bundle design leads to class loading issues > ------------------------------------------------ > > Key: TUSCANY-2343 > URL: https://issues.apache.org/jira/browse/TUSCANY-2343 > Project: Tuscany > Issue Type: Bug > Reporter: Georg Schmidt > > Currently the design of the OSGi bundles leads to class loading exceptions. > There seem to be several reasons for this behavior: > * reexporting of all libraries without version numbers > * imports without version numbers > Please use distinct bundles for 3rd party libraries. That would lead to > easier reusage of your bundles in a larger OSGi project. > The current status leads to undefined system behaviour due to the OSGi class > loading concept. > Please tell if you see a way, how we could support you by achieving this > goal. (If a solution is interesting for you) We are willing to contribute > because its a critical project issue for us. > The problems occur with the current snapshot release. Sorry, I do not know > which version to take. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.