On 10/10/09 12:26 PM, Cay Horstmann wrote:
> Ryan Lubke wrote:
>> On 10/10/09 6:12 AM, Cay Horstmann wrote:
>>> Should Glassfish add a web-fragment.xml to jsf-impl.jar so that
>>> users can deploy JSF applications without having to provide a
>>> boilerplate web.xml file?
>> We won't be adding a web-fragement.xml to jsf-impl.jar. The primary
>> reason is if Mojarra is installed as a global library, this would cause
>> Mojarra to be bootstrapped for every application whether or not it
>> used JSF. Not ideal.
>>
>> We *will* be adding a ServletContainerInitializer instead but we have
>> had to ship it disabled due to issues with the web container.
>> It will be re-enabled upon our next integration which will be some
>> time next week.
>
> Thanks! Does that help with the web.xml boilerplate?
Only as far as the FacesServlet mapping is concerned.
The ServletContainerInitializer will map the FacesServlet to /faces/*,
*.jsf, and *.faces
if any of the following conditions are met:
- Any of the classes included in the web application are annotated with
JSF 2.0 annotations (excludes @ManagedProperty), or extend/implement
UIComponent, Validator, Converter, or Renderer.
- If any of the context init parameters start with 'javax.faces.' or
'com.sun.faces.'
- If the WEB-INF/faces-config.xml is preset
Note that if the FacesServlet is already mapped, we won't add any of the
default mappings
listed above.
With this in place, you can deploy a JSF application with no web.xml or
faces-config.xml
as long as some class included in the application matches the criteria
described in the first
bullet item above.
If you want to control JSF state saving, or the project stage, you will
still need to add
those options yourself.
>
> Cay
>