[
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600437#action_12600437
]
Rajini Sivaram commented on TUSCANY-2343:
-----------------------------------------
Georg,
Thank you for the details on your scenario. It has been very helpful. For now,
I think we have enough information to make progress. When we start introducing
more versioning information in the jars, it will be very useful to run these
against your scenario first.
With tuscany-sca-osgi-installer.jar, 3rd party jars are installed with the
actual jar versions. In the example you used of servlet api, the bundle
installed will have:
Bundle-SymbolicName: org.apache.tuscany.sca.3rdparty.servlet-api-2.5
Bundle-Version: 2.5
Import statements in Tuscany however do not specify a version range. So Tuscany
can use a different version of javax.servlet installed by an application and
share classes from javax.servlet.
As long as the version range used by the application contains the version 2.5,
Tuscany and the application will use the same definitions of javax/servlet
(either from this bundle or the one installed by the application). If the
application uses a version range (eg. version=2.6) which does not match
Tuscany's, the application and Tuscany could end up using javax.servlet from
different bundles - in this case the application will always use 2.6, but
Tuscany may use 2.6 or 2.5 as chosen by the OSGi framework since it does not
specify a version range in its import).
The issues that we need to address for versioning import statements are:
1) Version ranges specified in import statements should be broad enough to
enable sharing. eg. If Tuscany is able to work with versions between
2.4.8-2.6.2 of javax.servlet, the version range should include the entire range
of those versions, enabling applications to choose the version.
2) Version ranges should be narrow enough to enable isolation when we want two
versions to coexist. eg. If one Tuscany extensionA wants to use version 3.1 of
foo.jar and another extensionB (or the application) wants to use 3.3 of the
same jar, where classes of the jar are not required to be shared, we should be
able to specify narrow ranges of versions in the import of org.foo, so that the
extensions use different versions.
3) Versions introduced by tools like the maven-bundle-plugin cannot really
provide us 1) and 2). So we will need to carefully analyse the usage of all 3rd
party jars to introduce proper version ranges in imports. Hence scenarios like
yours can be very useful to ensure that we get it right.
Back to tuscany-sca-osgi-installer.jar - this is not built as part of the main
build in Tuscany. So you need to run maven from itest/osgi-tuscany. You should
then be able to install and start this bundle. You should see around 200
bundles installed when bundle.start() returns.
You will need to modify the build script only if you want to disable the
installation of a 3rdparty jar.
1) If the JAXB bundle you are using is the same version (eg. 2.6.1) as the one
installed by Tuscany, you wont need to change anything. A single bundle will be
chosen as exported by the framework.
2) If the JAXB bundle you are using is of a different version (eg. 2.6.2), and
the application's import statements use a range which includes both 2.6.1 and
2.6.2, you dont need to change anything. The same export will be used for both
application and Tuscany.
3) If the application uses a version range that is different (application
requires 2.6.2), you should change the Tuscany installer build script to
exclude version 2.6.1, to ensure that Tuscany does not pick that one.
Hope this helps.
> 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.
