Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312731

Summary:

Resolver should be configurable to allow bundles to supply packages that are supplied by the JDK

Product:

[Eclipse Project] Equinox

Reporter:

Andy McCright <andymc>

Component:

Framework

Assignee:

Thomas Watson <tjwatson>

Status:

VERIFIED FIXED

QA Contact:

Severity:

major

Priority:

CC:

aniefer, dj.houghton, sanjeeb.sahoo, tjwatson

Version:

unspecified

Flags:

dj.houghton: review+
aniefer: review+

Target Milestone:

3.6 RC2

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
patch	none

Description Andy McCright

2010-05-12 18:55:39 EDT

Build Identifier: 3.6 M6

In our Java EE environment we have a bundle that exports javax.transaction package and contains the EE implementation classes - such as UserTransaction.  This bundle exports the package at a version higher than 0.0.0 (which is the version number that the system bundle uses for the JDK's implementation).

That package is also defined in Java SE 6, but does not contain classes from Java EE.

For bundles that use the "DynamicImport-Package: *" attribute, they are resolved to the system bundle which cannot find the Java EE classes even though the system bundle exports the javax.transaction package at a lowmer version number than our bundle.

Tom W. mentioned that this was due to bug 138422.  This new behavior (post-138422) seems incorrect according to the OSGi spec - but nevertheless, it would be nice if this behavior were configurable via the config.ini file.

Reproducible: Always

Steps to Reproduce:
1. Create a bundle (in our case, javax.j2ee.jta) that exports package javax.transaction at version "6.0.0" and contains class javax.transaction.UserTransaction.
2. Create a second bundle that imports the javax.transaction package without specifying a version (in our environment, we use "DynamicImport-Package: *").
3. Attempt to load the javax.transaction.UserTransaction class from the second bundle -- should fail with a NoClassDefFoundError.

Comment 1 Thomas Watson

2010-05-13 12:06:28 EDT

I am willing to add a configuration, but if you have a bundle that needs a particular version of a package then you better make sure you have matching attributes that ensure you get what you need.  The framework is free to wire you up to any export which it views matches a particular package constraint.

Even if we have an option that does not prefer the system packages you may still find your bundles getting wired to the wrong version.

Comment 2 Thomas Watson

2010-05-13 12:08:37 EDT

Created attachment 168404 [details]
patch

Comment 3 Thomas Watson

2010-05-13 12:09:13 EDT

DJ please review.

Comment 4 Thomas Watson

2010-05-13 12:12:11 EDT

Andrew, please review.

Comment 5 Andy McCright

2010-05-14 15:03:30 EDT

Tom,

Thanks for the quick response!

My initial sniff test of the patch passed when setting osgi.resolver.preferSystemPackages=false in the config.ini.  

I have kicked off a larger batch of automated tests and will let you know the results.

Thanks again,

Andy

Comment 6 Thomas Watson

2010-05-17 10:44:09 EDT

Patch released for RC2.

Comment 7 Thomas Watson

2010-11-04 09:37:30 EDT

*** Bug 329314 has been marked as a duplicate of this bug. ***