jersey
  1. jersey
  2. JERSEY-1124

ServiceFinder not returning services in META-INF/services

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.9.1, 2.0
    • Fix Version/s: 2.0-m11, 2.0
    • Component/s: core
    • Labels:
      None

      Description

      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;

        Activity

        Hide
        Martin Matula added a comment -

        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.

        Show
        Martin Matula added a comment - 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.
        Hide
        charlesk40 added a comment -

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

        Show
        charlesk40 added a comment - Can some one explain in more detail what will be removed or changed? Thank you.
        Hide
        Michal Gajdos added a comment -

        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.

        Show
        Michal Gajdos added a comment - 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.
        Hide
        Pavel Bucek added a comment -

        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.

        Show
        Pavel Bucek added a comment - 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.
        Hide
        charlesk40 added a comment -

        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.

        Show
        charlesk40 added a comment - 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.
        Hide
        Pavel Bucek added a comment -

        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.

        Show
        Pavel Bucek added a comment - 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.
        Hide
        sameerShah added a comment - - 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?

        Show
        sameerShah added a comment - - 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?
        Hide
        Pavel Bucek added a comment -

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

        Show
        Pavel Bucek added a comment - 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..
        Hide
        Pavel Bucek added a comment - - 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?

        Show
        Pavel Bucek added a comment - - 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?
        Hide
        Pavel Bucek added a comment -

        any update?

        Show
        Pavel Bucek added a comment - any update?
        Hide
        sameerShah added a comment -

        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.

        Show
        sameerShah added a comment - 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.
        Hide
        Michal Gajdos added a comment -

        Fixed for 1.13.

        Show
        Michal Gajdos added a comment - Fixed for 1.13.
        Hide
        Jakub Podlesak added a comment -

        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.

        Show
        Jakub Podlesak added a comment - 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.

          People

          • Assignee:
            Michal Gajdos
            Reporter:
            charlesk40
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 6 hours
              6h