[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602965#action_12602965
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-----------------------------------------

Daniel,

Thank you for doing this. I think we are getting somewhere finally...

The current set of 3rd party libraries in Tuscany use DynamicImport-Package 
rather than generate the real list of imported packages at build time. As a 
result, the import list changes as classes are loaded. 

The Equinox behaviour is correct - there should only be one source for a 
package, so once the package is imported, it should not search locally.

You have another version of xerces in your enviroment, with version 2.9.0 
(Tuscany provides 2.8.1). It looks like your xerces bundle exports 
META-INF.services. Since Tuscany's wstx-asl uses "Dynamic-ImportPackage: *", it 
is getting wired to your xerces bundle version 2.9 while reading some resource 
in META-INF/services. We will be modifying Tuscany's 3rd party bundles to use 
proper import/exports which will avoid this problem, but we need to sort out 
our versioning story first, so that may take a while. In the meantime, would it 
be possible to modify your xerces bundle to stop exporting META-INF.services? I 
dont think META-INF/services should be an exported package anyway - it should 
be private to ensure that bundles can have their own list of services.

- Rajini


> 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
>         Attachments: Libary Versions.xls, test_bundles.zip
>
>
> 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.

Reply via email to