Issue Details (XML | Word | Printable)

Key: JERSEY-1124
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Michal Gajdos
Reporter: charlesk40
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
jersey

ServiceFinder not returning services in META-INF/services

Created: 27/Apr/12 12:23 AM   Updated: 11/Mar/14 04:20 PM   Resolved: 17/Dec/12 10:42 AM
Component/s: core
Affects Version/s: 1.9.1, 2.0
Fix Version/s: 2.0-m11, 2.0

Time Tracking:
Original Estimate: Not Specified
Remaining Estimate: 0 minutes
Remaining Estimate - 0 minutes
Time Spent: 6 hours
Time Spent - 6 hours

Tags: 1_13-blocker
Participants: charlesk40, Jakub Podlesak, Martin Matula, Michal Gajdos, Pavel Bucek and sameerShah


 Description  « Hide

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

http://java.net/projects/jersey/sources/svn/content/trunk/jersey/jersey-core/src/main/java/com/sun/jersey/spi/service/ServiceFinder.java?rev=5697

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



Martin Matula added a comment - 02/May/12 03:22 PM

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.


charlesk40 added a comment - 02/May/12 03:53 PM

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


Michal Gajdos added a comment - 22/May/12 08:48 PM

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.


Pavel Bucek added a comment - 24/May/12 05:06 PM

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.


charlesk40 added a comment - 24/May/12 05:17 PM

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
— META-INF/MANIFEST.MF (Contains the BUNDLE_VERSION OSGi header)
/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.


Pavel Bucek added a comment - 24/May/12 05:32 PM

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.


sameerShah added a comment - 25/May/12 12:26 AM - edited

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?


Pavel Bucek added a comment - 25/May/12 08:25 AM

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..


Pavel Bucek added a comment - 25/May/12 02:05 PM - edited

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?


Pavel Bucek added a comment - 31/May/12 01:35 PM

any update?


sameerShah added a comment - 31/May/12 10:39 PM

I tried with 1.13 build but still no change.

moduleVersion : 1.13-b01
MODULE_VERSION_VALUE: 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.


Michal Gajdos added a comment - 25/Jun/12 12:01 PM

Fixed for 1.13.


Jakub Podlesak added a comment - 22/Nov/12 05:54 PM

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.