Resource jsf.js not found when using the OSGi bundle

Details

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

Activity

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.

Leonardo Uribe
added a comment - 21/Feb/11 18:53 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.

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.

Jakob Korherr
added a comment - 22/Feb/11 09:55 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.

Jakob Korherr
added a comment - 22/Feb/11 10:10 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?

Jakob Korherr
added a comment - 22/Feb/11 10:26 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..

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.

Clovis
added a comment - 22/Feb/11 10:57 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.