[
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.
