On 5/28/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > 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)
Yes, these are two different requirements. And 1) can be handled separately from 2) by using additional attributes in import constraints. But I have assumed that Tuscany will not mandate the use of 3rd party bundles which are distributed with Tuscany, and that Tuscany's 3rd party jars can be substituted with any compatible version of the 3rd party jar which has been bundle-ized separately. That implies that we ultimately rely on import constraints based on version ranges to achieve sharing of classes. So while the easiest solution to 2) may be to make the import version ranges as narrow as possible, 1) requires that version ranges are as broad as possible for sharing classes across Tuscany and applications. At the moment, Tuscany's imports are totally unconstrained, and hence we can achieve 1) fairly easily. But we need to constrain imports to achieve 2). We need to get the right balance between the two so that common usage scenarios of Tuscany do not require specification of complex constraints when using different versions of 3rd party jars in applications. > Simon > Thank you... Regards, Rajini
