dev@glassfish.java.net

issue 12914

From: Sheetal Vartak <sheetal.vartak_at_oracle.com>
Date: Thu, 14 Oct 2010 10:48:04 -0700

Hello,

I'm trying to fix issue 12914. Some history about that...
There were some issues related to the JSF configuration resource providers because of which the OSGiFaces/FaceletsConfigResourceProvider classes were added/introduced. But with a few fixes in the past, the JSF config providers are now able to look up all the resources (***faces-config.xml) via the bundle and jar protocol.

We need to get rid of one of the config resource providers in order to avoid dups. I would rather have the OSGi ones removed than the JSF ones since they are needed in a non-GF env.

Does anyone have any comments/suggestions regarding this?

 Also currently, the JSF config resource providers look up the resources twice (once via jar protocol and then via the bundle protocol). But some logic can be added in order to not do this twice.

On the same note, there is no way I can disable the JSF config resource providers and give full control to the OSGi faces/facelets config resource providers just for the GF env. Are the OSGi faces/facelets config resource providers better (performance wise) than the JSF ones? If so, we can try to make changes in order to give full control only in the Glassfish scenario.

In the scenario where we would like to continue using the JSF providers in GF env, how can we disable the OSGi faces/facelets providers? Is this possible in a production env via a property change or so? Also we would need to make sure that the JSF config resource providers return the list of resources looked up either via jar or bundle protocol. Sahoo is out on a conference hence the email to a wider audience.

Thanks
Sheetal