[JERSEY-1124] ServiceFinder not returning services in META-INF/services Created: 27/Apr/12  Updated: 10/Sep/15  Resolved: 17/Dec/12

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.9.1, 2.0
Fix Version/s: 2.0-m11, 2.0

Type: Bug Priority: Critical
Reporter: charlesk40 Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 6 hours
Original Estimate: Not Specified

Tags: 1_13-blocker


Shouldn't the servicesUrls return when we have services defined in META-INF/services even if we have BUNDLE_VERSION defined?


private static Enumeration<URL> filterServiceURLsWithVersion(String serviceName, Enumeration<URL> serviceUrls) {
0217. if (BUNDLE_VERSION == null || !serviceUrls.hasMoreElements())
0218. return serviceUrls;

Comment by Martin Matula [ 02/May/12 ]

This was intentional due to various versioning issues we have been facing in GlassFish which has a particular version of Jersey on system classpath. But it created a lot of other issues. So we are most likely going to remove this restriction in the next update. Assigning to Michal.

Comment by charlesk40 [ 02/May/12 ]

Can some one explain in more detail what will be removed or changed?
Thank you.

Comment by Michal Gajdos [ 22/May/12 ]

We are considering to remove the constraint that enforces you to use the same version of Jersey additions (e.g. jersey-oauth, jersey-atom, ..) as the jersey-core (ServiceFinder) has. This constraint is influencing services registered via META-INF/services mechanism (e.g. in GlassFish it's not possible to use jersey-oauth that has different version than Jersey libraries bundled in the GlassFish). Will be resolved in 1.13.

Comment by Pavel Bucek [ 24/May/12 ]

just short question:

do you have some usecase for which Jerseys ServiceFinder doesn't work correctly? "serviceUrls" can still be returned even if BUNDLE_VERSION is not null, checking mechanism is more complex than this single check. Its purpose is to deny loading JERSEY providers from different JERSEY versions, it should not affect you at all (unless you are repackaging Jersey). (BUNDLE_VERSION is taken from manifest of jar where jersey-core/ServiceFinder impl resides).

more details will be greatly appreciated / this is somehow sensitive and hard to test problem and change might cause regressions in lots of places/products.

Comment by charlesk40 [ 24/May/12 ]

We have a bundle that includes all the jersey jars as embeded dependencies.

So something like:
application.jar (bundle)
— jersey-core.jar
— jersey-x.jar
/services (Contains some providers we would like Jersey to pickup using the ServiceFinder)

Since we have the BUNDLE_VERSION defined, and because of the check that I have mentioned, providers don't get picked up.

Comment by Pavel Bucek [ 24/May/12 ]

have you gone any further in your debugging session? Can you tell us which condition you don't meet?

it will most likely be somewhere in ServiceFinder.compatibleManifest method.

Comment by sameerShah [ 25/May/12 ]

After debugging this issue further, the compatibleManifest method returns false

if(moduleVersion != null &&
                    (!moduleVersion.equals(MODULE_VERSION_VALUE)) ||
                        (symbolicName != null &&
                        (BUNDLE_SYMBOLIC_NAME.startsWith("com.sun.jersey") ^ symbolicName.startsWith("com.sun.jersey")))) {
                return false;

The values for the variables are as follows:
modulleVersion = 1.4
BUNDLE_SYMBOLIC_NAME = com.sun.jersey.jersey-core
SymbolicName = com.abc.testBundle

Does this help?

Comment by Pavel Bucek [ 25/May/12 ]

yes, thanks! just one more info needed - MODULE_VERSION_VALUE.

most helpful thing would be striping down your project and send minimal reproducible case, but I understand it can be difficult..

Comment by Pavel Bucek [ 25/May/12 ]

aha! This might be already fixed. I've just tried to recreate your case and noticed one (significant) difference:

if(moduleVersion != null &&
        (!moduleVersion.equals(MODULE_VERSION_VALUE) ||
            (symbolicName != null &&
            (BUNDLE_SYMBOLIC_NAME.startsWith("com.sun.jersey") ^ symbolicName.startsWith("com.sun.jersey"))))) {
    return false;

(misplaced parenthesis)

Can you please try Jersey 1.13 and verify if your issue is still valid?

Comment by Pavel Bucek [ 31/May/12 ]

any update?

Comment by sameerShah [ 31/May/12 ]

I tried with 1.13 build but still no change.

moduleVersion : 1.13-b01
BUNDLE_SYMBOLIC_NAME = com.sun.jersey.jersey-core
SymbolicName = com.abc.testBundle

The change in the parenthesis does not help. since the if condition still resolves to true and hence the compatibleManifest function returns false.

Comment by Michal Gajdos [ 25/Jun/12 ]

Fixed for 1.13.

Comment by Jakub Podlesak [ 22/Nov/12 ]

This should be fixed also in 2.0 Jersey version. Mira just bumped into an issue related to the check when integrating Jersey 2.0-m10 into GF.

Generated at Sun Feb 26 16:17:11 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.