Community
Participate
Working Groups
Oracle needs to be able to change the way Facelet libraries are resolved at runtime. This does not change the default behavior of the Facelet registry, but rather adds an internal (could be made API in future releases) extension that allows adopters to change the locators used to find tag libraries. This will also be required by adopters who wish to support MyFaces or other such JSF libraries that do not either (a) bundle their core libraries as taglib.xml files or (b) do not conform to the spec when discovering libraries.
Created attachment 168792 [details] Adds the extension mechanism to override the locators contributed to the Facelet tag registr.
Created attachment 168793 [details] Adds simple noop implementation.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a hotbug request from Oracle. It is required in the adopter product to support enhanced JSF 2.0 features. * Is there a work-around? If so, why do you believe the work-around is insufficient? No reasonable workaround * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Junit attached * Give a brief technical overview. Who has reviewed this fix? See description. * What is the risk associated with this fix? none
What do you mean "This will also be required by adopters who wish to support MyFaces ...? I thought we already supported MyFaces, at least to some degree?
(In reply to comment #4) > What do you mean "This will also be required by adopters who wish to support > MyFaces ...? I thought we already supported MyFaces, at least to some degree? Facelets is a new tag technology (replacing JSP) introduced in JSF 2.0 (actually it existed before but 2.0 is the first spec release that has it). The MyFaces implementation of JSF 2.0 does not bundle the taglib.xml files for the core tags (taglib.xml is basically the Facelet equivalent of a JSP TLD). We need this extensibility to give adopters (Oracle included) the flexibilty to bundle our own version of the taglib.xml for implementation situations like this. We are trying avoid bundling these taglib.xml files within open source for the same reasons we avoided doing so for TLDs.
doh. I see what you mean now. So next question ... how does this interact with bug 309488 and the CQ opened for it (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4100). Do we no longer need that CQ? Or is this an "extra" part of the fix for bug 309488? BTW, I don't object to what you are proposing but 1) want to be sure I understand it and 2) want to be sure we (WTP) still offer functionality "out of the box" and don't end up just having a framework, that users can not really see, unless they get "adopter products". Or, at least not without us all being aware, and explicit about it. Thanks.
One more question, already ... you say > We are trying avoid bundling these taglib.xml files within open source for the > same reasons we avoided doing so for TLDs. Is it the case that TLDs were normally packaged/distributed with the runtimes? And that's where we read them from, when needed? Any idea why that's not the case for JSF 2.0 implementations? Just curious.
(In reply to comment #7) > One more question, already ... you say > > > We are trying avoid bundling these taglib.xml files within open source for the > > same reasons we avoided doing so for TLDs. > > Is it the case that TLDs were normally packaged/distributed with the runtimes? > And that's where we read them from, when needed? > Any idea why that's not the case for JSF 2.0 implementations? > Just curious. In JSF 1.2, the default View Description Langauage(VDL) is JSP and the tags are defined in a TLD (*.tld) per the schema, http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd. These TLD's are part of the runtime implementation. In JSF 2.0, the VDL is XHTML and the equivalent tag library descriptor is based on the schema http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd and the tags are defined in *.taglib.xml. However, the spec doesn't require the the runtime implementation to include this definition. The RI implementation includes it, but MyFaces doesn't.
This all is related to the problem outlined in bug 312345. DW> want to be sure we (WTP) still offer functionality "out of DW> the box" and don't end up just having a framework, that users can not really DW> see, unless they get "adopter products". Or, at least not without us all being DW> aware, and explicit about it. Right now WTP does not offer the same out of the box functionality when MyFaces is used as compared to when Mojarra is used. A user who installs WTP to develop web apps using MyFaces will be missing many crucial JSF features. This is because WTP JSF tooling is unaware of standard JSF tags and relies on JSF implementation to provide such information, which JSF implementations are not required to do. It is an unfortunate shortcoming of JSF specification from the tooling point of view. However, JSF EG's opinion is that standard tags are just that -- standard. They are described in the spec and are not implementation specific. Hence all information about them is available.
The PMC discussed this today and can summarize our conversation as 1) this extensibility is fine, useful, etc. 2) should not be required for MyFaces, or other "standards" support. If the CQ for the xml files is not approved for any reason, the support can be provided by a "direct" implementation of the meta-data. (And, that's no commitment on who or when it would get done, but would remain a goal). thanks all for the discussion and clarifications.
Patches committed to HEAD (3.2RC3)
Resolved.
