Community
Participate
Working Groups
Build Identifier: I20100520-1744 In JSF 2.0, Faces Servlet declaration is not necessary in web descriptor. However, when configuring JSF facet for existing JSF 2.0 project, it is impossible to avoid web.xml being modified by insertion of servlet and mapping declarations. Besides, for web.xml of version 3.0, namespace xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" is inserted, which is an annoyance. Could it be possible to add a configuration property to data model for JSF facet installer, that would prevent undesirable modifications to web descriptor? (e.g. IJSFFacetInstallDataModelProperties.SERVLET_IMPLICIT true/false; available for servlet version 2.0; in UI represented by a check box that enables/disables other inputs for servlet name and mapping.) Reproducible: Always Steps to Reproduce: 1. Import into Eclipse a JSF 2.0 project, which is not a facet project. 2. Convert it into Faceted project and add Dynamic Web Module Facet 3.0. 3. Reopen properties, and select JavaServer Faces facet to configure. Configuration is filled with default value in 'JSF servlet name' input field, and it would not permit to have it empty, or in any other way to indicate that no servlet declaration should be inserted into web descriptor.
We will review this to see if we can make a non-UI change that adopters can use.
Bug 343324 has been logged to deal with the unused xmlns:web generation.
The JSF facet install delegate checks for a servlet in the web app model, finds none (which, in a Servlet 3.0 app, could be a bug in itself, since any annotated servlets/mappings found on the classpath should be in the web app model), then updates the model, which, in turn, causes WTP to write (or update) a web.xml file. At this late stage in the Indigo release cycle (almost M7), it is too late to add UI or change data models. We could offer a system property that would prevent the logic that modifies the web app model from running, effectively meaning that any existing web.xml file is left untouched and no new web.xml file is created. Would this be beneficial?
Yes, if JSF facet install delegate checks that property every time before modifying web.xml, then tool that invokes JSF facet addition may adjust the property, and set it back afterwards.
Raghu/Ian, Doesn't this qualify for an allowed fix if approved by PMC since the current behavior is broken for any JEE6 usage no matter if new or existing project as far as I can see ?
Request PMC review and pre-approval to fix this issue which requires a change in UI post-M6. We will implement the fix and attach a patch if approved. * 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. The current implementation of the JSF Facet indirectly forces the creation of the web.xml file which is an incorrect behavior for one use case of JEE6 that uses Servlet 3.0 and JSF 2.0 technologies. * Is there a work-around? If so, why do you believe the work-around is insufficient? No suitable workaround. See comment 3 for a non-UI fix. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? NA * Give a brief technical overview. Who has reviewed this fix? See comment 3 * What is the risk associated with this fix? low
Fine with me to fix this, but unclear if you mean by system-property-workaround, or a "real" fix with new UI. Either is fine with me ... just saying its unclear. Plus, normally PMC approval/review is requested after a concrete fix is proposed via patch ... that's part of any risk/benefit trade-off ... but, again, in principle, I'm fine with fixing this. Sounds pretty important. This is not a regression, I assume? Just an aspect of JSF 2.0 that's not been well tested? Just curious.
(In reply to comment #7) > Fine with me to fix this, but unclear if you mean by > system-property-workaround, or a "real" fix with new UI. Either is fine with me > ... just saying its unclear. The real-fix with the UI change in the JSF Facet related pages > > Plus, normally PMC approval/review is requested after a concrete fix is > proposed via patch ... that's part of any risk/benefit trade-off ... but, > again, in principle, I'm fine with fixing this. Sounds pretty important. > This was a pre-approval request given it involves a UI change post-M6. We will submit a patch for review > This is not a regression, I assume? Just an aspect of JSF 2.0 that's not been > well tested? Just curious. Not a regression.
Created attachment 193891 [details] UI, data model, and utility class changes to allow skipping web.xml configuration
Patch now attached - would PMC please consider for M7? Thanks, - Ian
Fix submitted at 2011/04/25 09:37AM PDT.
Forgot to toggle status - fixed.
Please review if this can be released for the M7 build
Released changes to M7
New Gerrit change created: https://git.eclipse.org/r/114285
Gerrit change https://git.eclipse.org/r/114285 was merged to [master]. Commit: http://git.eclipse.org/c/jsf/webtools.jsf.git/commit/?id=c58980a8326f3de7f2da4c418b06dc04bfcd9b17
