jersey
  1. jersey
  2. JERSEY-276

l10n resource bundles are not picked up at GlassFish v3 Jersey bundle

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: core
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      276

      Description

      at GlassFish v3 with integrated Jersey, l10n messages are not displayed correctly,
      even if appropriate resource bundle properties file is present at
      jersey-gf-bundle.jar module at glassfish/modules directory

      how to reproduce:

      install Jersey into GFv3 via GFv3 UC client, then go to
      glassfish/jersey/samples/helloworld-webapp and change package name
      in src/main/webapp/WEB-INF/web.xml to a non-existing package,
      then mvn clean package, and try to deploy, you will get:

      remote failure: Exception while deploying the app : java.lang.Exception:
      java.lang.IllegalStateException: ContainerBase.addChild: start:
      LifecycleException: com.sun.jersey.api.container.ContainerException: [failed to
      localize] no.root.res.in.res.cfg()

        Activity

        Hide
        gdavison added a comment -

        This is also a problem if you are using jersey-archive under web logic server.
        This makes it really hard for users to diagnose even simple issues.

        We would be keen to see a fix for this as soon as possible.

        how to reproduce:

        Deploy a jax-rs service to weblogic that will fail. For example a GET with
        parameters that are not @QueryParam or mapped to the path.

        @Path("/hello")
        public class Hello
        {
        @GET
        public String sayHello(String param)

        { return "Hello " + param; }

        }

        You may need to apply some of the workarounds detailed in:

        http://kingsfleet.blogspot.com/2008/10/running-jax-rcjerseyjsr311-on-weblogic.html

        Having said that I think this is a general bug rather than one specific to
        weblogic. I will be happy to retest when a fix is in.

        Show
        gdavison added a comment - This is also a problem if you are using jersey-archive under web logic server. This makes it really hard for users to diagnose even simple issues. We would be keen to see a fix for this as soon as possible. how to reproduce: Deploy a jax-rs service to weblogic that will fail. For example a GET with parameters that are not @QueryParam or mapped to the path. @Path("/hello") public class Hello { @GET public String sayHello(String param) { return "Hello " + param; } } You may need to apply some of the workarounds detailed in: http://kingsfleet.blogspot.com/2008/10/running-jax-rcjerseyjsr311-on-weblogic.html Having said that I think this is a general bug rather than one specific to weblogic. I will be happy to retest when a fix is in.
        Hide
        sandoz added a comment -

        The archive redistributes the individual jars directly available from the repo.

        I am wondering if this is a class loading issue with the localization helper
        classes when loading the property files containing the strings.

        There is a similar issue with GF.

        Show
        sandoz added a comment - The archive redistributes the individual jars directly available from the repo. I am wondering if this is a class loading issue with the localization helper classes when loading the property files containing the strings. There is a similar issue with GF.
        Hide
        japod added a comment -

        L10n works correctly with grizzly when taking the jars from the archive.
        This seems to be reproducible only on servlet containers.
        With GlassFish v3, i blamed OSGi, but it is apparently not related.
        I am going to try it out with Tomcat as well, and see how to fix this.

        Show
        japod added a comment - L10n works correctly with grizzly when taking the jars from the archive. This seems to be reproducible only on servlet containers. With GlassFish v3, i blamed OSGi, but it is apparently not related. I am going to try it out with Tomcat as well, and see how to fix this.
        Hide
        japod added a comment -

        The cause is in com.sun.istack.localization package, which is bundled not only
        with Jersey, but also with jaxb jar. I am on vacation the next week, but going
        to fix this quickly now by copying 4 classes from commons-istack to different
        package
        within jersey workspace. Also need to change the istack-commons maven plugin,
        so that it accepts a parameter for l10n utility classes package name.
        Since need to wait till the the plugin change propagates to the maven
        repository, the fix may took some hours.

        I have verified this should fix the issue for GFv3.

        After i return back, would like to review the solution.

        Show
        japod added a comment - The cause is in com.sun.istack.localization package, which is bundled not only with Jersey, but also with jaxb jar. I am on vacation the next week, but going to fix this quickly now by copying 4 classes from commons-istack to different package within jersey workspace. Also need to change the istack-commons maven plugin, so that it accepts a parameter for l10n utility classes package name. Since need to wait till the the plugin change propagates to the maven repository, the fix may took some hours. I have verified this should fix the issue for GFv3. After i return back, would like to review the solution.
        Hide
        japod added a comment -

        Fixed in the main trunk. The changes should be hopefully propagated to the maven
        repository by Monday. Then to verify on GlassFish v3, you can download the jar
        archive from [1], check it does not contain com.sun.istack package, and
        replace glassfing/modules/jersey-gf-bundle.jar with the downloaded jar. For the
        archive based scenario, the com.sun.istack package should be missing at the
        jersey-core.jar.

        [1]http://download.java.net/maven/2/com/sun/jersey/glassfish/v3/osgi/jersey-gf-bundle/1.1.2-ea-SNAPSHOT/jersey-gf-bundle-1.1.2-ea-SNAPSHOT.jar

        Show
        japod added a comment - Fixed in the main trunk. The changes should be hopefully propagated to the maven repository by Monday. Then to verify on GlassFish v3, you can download the jar archive from [1] , check it does not contain com.sun.istack package, and replace glassfing/modules/jersey-gf-bundle.jar with the downloaded jar. For the archive based scenario, the com.sun.istack package should be missing at the jersey-core.jar. [1] http://download.java.net/maven/2/com/sun/jersey/glassfish/v3/osgi/jersey-gf-bundle/1.1.2-ea-SNAPSHOT/jersey-gf-bundle-1.1.2-ea-SNAPSHOT.jar
        Hide
        japod added a comment -

        Verified for GlassFish and also for standalone archive scenario
        as per http://kingsfleet.blogspot.com/2009/08/useful-localization-fix-in-jersey.html

        Show
        japod added a comment - Verified for GlassFish and also for standalone archive scenario as per http://kingsfleet.blogspot.com/2009/08/useful-localization-fix-in-jersey.html

          People

          • Assignee:
            Jakub Podlesak
            Reporter:
            Jakub Podlesak
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: