Can we keep development discussions on this mailing list? Otherwise
not everyone who is involved in the RI development will see the
discussions.
On 29 Dec 2008, at 12:40, Ales Justin wrote:
I moved this discussion here:
-
http://seamframework.org/Community/MetadataAddons#comment56874
Pete Muir wrote:
> On 21 Dec 2008, at 19:38, Stan Silvert wrote:
>> Pete Muir wrote:
>>>>
>>>> And one for the JSF2 deployer
>>>>
>>>> 5) if faces-config.xml is present, automatically add the
>>>> FacesServlet, it's mapping to the .jsf extension.
>> Several questions/comments about this one.
>> At a minimum, the servlet-name should be defined in addition to
>> the extension. The reasons become clear below.
>>
>> It is allowed to have more than one declaration of the
>> FacesServlet. That is because you might want to have two
>> instances with two different configurations and two different
>> mappings. Do we say that if ANY FacesServlet is defined then we
>> don't define another one for WebBeans? Or, do we define an
>> additional one for WebBeans as long as it doesn't use the same
>> default mapping?
>>
>> If the FacesServlet is defined in /WEB-INF/web.xml with the same
>> servlet-name as the WebBeans default, then the entire auto-added
>> FacesServlet should not be added.
> including the mapping.
> This is more a default for JBoss AS, not just for WB I think... I
> think this is a good idea, especially if we choose a sensible name,
> like "Faces Servlet".
>> For the auto-added FacesServlet, should we also define defaults
>> for dispaly-name, description, icon, init-param, load-on-startup,
>> run-as, or security-role-ref?
> display-name (used for GUI tooling) - default
> icon (used for GUI tooling) - default
> description (descriptive text about parent element) - maybe useful
> load-on-startup - we always set this to 1 in Seam.
> run-as - default
> security-role-ref - default
> if people want to override, then they can do.
>> The JSF 1.2 spec 10.1.2 recommends extension mapping to be
>> *.faces. FWIW, I prefer *.jsf, but perhaps we should stick with
>> the spec's recommendation as the default?
> Agreed.
>> Since we key off the presence of a faces-config.xml file, is this
>> any faces-config.xml, or only one found in /WEB-INF?
>> I think that if practical, FacesServlet should be added any time a
>> faces-config.xml is present in any of the locations specified in
>> JSF 1.2 spec section 10.4.2 Application Startup Behavior. What's
>> more, a faces-config file can be specified using a
>> javax.faces.CONFIG_FILES context param in web.xml. Since I assume
>> we plan to support web.xml fragments, a la Servlet 3.0, we also
>> need to look into every web.xml fragment in every jar to see if it
>> defines javax.faces.CONFIG_FILES.
> I was thinking just a faces-config.xml in the war is enough.
> Otherwise, won't get get confusion between app server libs. We need
> something *in the user deployment* to key off. Remember, these are
> only defaults to get people started.
>> It's possible to have a JSF app with no faces-config.xml file. Is
>> a faces-config.xml required for WebBeans?
> No.
>> Are there any considerations for portlets? Portlets don't use the
>> FacesServlet at all but perhaps JSR-301 portlets will need some
>> auto-config as well?
> Up to portal team I think.
>> Does the WebBeans spec say anything about portlets?
> No.
> N.B. This isn't spec driven, this is value-add for the RI/JBoss.
--
----------------------------
Ales Justin
JBoss, a division of Red Hat
----------------------------