MyFaces Core
  1. MyFaces Core
  2. MYFACES-3044

Resource jsf.js not found when using the OSGi bundle

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.3
    • Fix Version/s: 2.0.5
    • Component/s: None
    • Labels:
      None

      Description

      First there is a
      WARNING: Resource referenced by resourceName jsf.js and libraryName javax.faces not found in call to ResourceHandler.createResource. It will be silenty ignored.
      and later a NullPointerException

      Using javax.faces.PROJECT_STAGE=Development, the class loader was trying to load META-INF/internal-resources/javax.faces/jsf-uncompressed-full.js (so I added the "package" META-INF.internal-resources.javax.faces to the list of exported packages of myfaces-bundle.jar). But then I changed it from Development to Production, and myfaces tried to load something else (and I decided to write a bug).

        Issue Links

          Activity

          Hide
          Leonardo Uribe added a comment -

          If PROJECT_STAGE=Development is used, MyFaces loads the uncompressed version on META-INF/internal-resources, but if is production, the compressed version on META-INF/resources/javax.faces is used. I checked and both files are on proper locations, so this issue can be closed as invalid, because the current behavior is the expected one.

          Show
          Leonardo Uribe added a comment - If PROJECT_STAGE=Development is used, MyFaces loads the uncompressed version on META-INF/internal-resources, but if is production, the compressed version on META-INF/resources/javax.faces is used. I checked and both files are on proper locations, so this issue can be closed as invalid, because the current behavior is the expected one.
          Hide
          Jakob Korherr added a comment -

          I disagree that this is the expected behavior.

          Users will use our OSGi-bundle also if ProjectStage==Development and not only in Production. So if we do not fix it, users would have to use ProjectStage==Production for development too and that's just wrong!

          Also it should be really easy to fix. From the dev-list: add META-INF.internal-resources.javax.faces and META-INF.services to the exported packages in MANIFEST.MF.

          Show
          Jakob Korherr added a comment - I disagree that this is the expected behavior. Users will use our OSGi-bundle also if ProjectStage==Development and not only in Production. So if we do not fix it, users would have to use ProjectStage==Production for development too and that's just wrong! Also it should be really easy to fix. From the dev-list: add META-INF.internal-resources.javax.faces and META-INF.services to the exported packages in MANIFEST.MF.
          Hide
          Jakob Korherr added a comment -

          Adding this to the export packages of the maven-bundle-plugin configuration should fix this issue:

          META-INF.internal-resources.javax.faces;version="$

          {project.version}",
          META-INF.resources;version="${project.version}

          ",
          META-INF.services;version="$

          {project.version}

          "

          However, I am not sure if this is the expected thing to do here. Is anyone here more familiar with OSGi?

          Show
          Jakob Korherr added a comment - Adding this to the export packages of the maven-bundle-plugin configuration should fix this issue: META-INF.internal-resources.javax.faces;version="$ {project.version}", META-INF.resources;version="${project.version} ", META-INF.services;version="$ {project.version} " However, I am not sure if this is the expected thing to do here. Is anyone here more familiar with OSGi?
          Hide
          Jakob Korherr added a comment -

          Maybe this issue can also be fixed without adding these entries to the MANIFEST.MF, but by changing the resource loading mechanism to use multiple ClassLoaders..

          Show
          Jakob Korherr added a comment - Maybe this issue can also be fixed without adding these entries to the MANIFEST.MF, but by changing the resource loading mechanism to use multiple ClassLoaders..
          Hide
          Jakob Korherr added a comment -

          Maybe MYFACES-3051 can solve this issue!

          Show
          Jakob Korherr added a comment - Maybe MYFACES-3051 can solve this issue!
          Hide
          Clovis added a comment -

          I don't know if you are willing to add exported packages every time someone realizes that, for some configuration, a file from a non-exported package is required... For example, with PROJECT_STATE=Production, META-INF.resources.javax.faces is also needed as exported package.

          Show
          Clovis added a comment - I don't know if you are willing to add exported packages every time someone realizes that, for some configuration, a file from a non-exported package is required... For example, with PROJECT_STATE=Production, META-INF.resources.javax.faces is also needed as exported package.
          Hide
          Jakob Korherr added a comment -

          Hehe, yes. That's why I am trying to fix this issue via MYFACES-3051.

          Show
          Jakob Korherr added a comment - Hehe, yes. That's why I am trying to fix this issue via MYFACES-3051 .
          Hide
          Jakob Korherr added a comment -

          code committed in MYFACES-3051 fixes this problem (confirmed by Clovis Seragiotto on the mailing list).

          Show
          Jakob Korherr added a comment - code committed in MYFACES-3051 fixes this problem (confirmed by Clovis Seragiotto on the mailing list).

            People

            • Assignee:
              Jakob Korherr
              Reporter:
              Clovis
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development