One comment inline.
Simon
Rajini Sivaram (JIRA) wrote:
[ 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.
It seems like this is coupling two things that are not the same:
1. whether or not the extensions need to share the same loaded classes
2. which version of the dependency the two extensions can tolerate (for their
own compatibility needs)
Simon
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.
