Sorry, this is a TODO item/discussion piece :-) On 20 Dec 2008, at 17:55, Pete Muir wrote: > The idea here is that a Web Beans RI app requires certain > configuration applied by default (see below), and we should try to > provide this configuration by default when in JBoss 5. The user can > still override this configuration using the relevant XML. We've talked > about this before, but never done anything with it :-) > > Here are the rules > > 1) ejb-jar.xml > > If web-beans.xml is present in the ejb module's META-INF, > automatically add the Web Beans RI SessionBeanInterceptor (see > attached ejb-jar.xml for how we currently configure it). The user > can't disable this interceptor. > > > 2) jboss-app.xml > > If web-beans.xml is present in the ejb-module's META-INF, > automatically enable classloader isolation. Any settings in > jboss-app.xml override. Is it possible to explicitly disable > classloader isolation? Is this change from the jboss default too > confusing? Another option is to disable if a jboss-app.xml is present. > > 3) jboss-web.xml > > If web-beans.xml is present in the war's WEB-INF or META-INF, > automatically enable classloader isolation. Any settings in > jboss-web.xml override. Is it possible to explicitly disable > classloader isolation? Is this change from the jboss default too > confusing? Another option is to disable if a jboss-app.xml is present. > > 4) web.xml > If web-beans.xml is present in the war's WEB-INF or META-INF or the > ejb module's META-INF automatically add the WebBeansListener servlet > listener > > And one for the JSF2 deployer > > 5) if faces-config.xml is present, automatically add the FacesServlet, > it's mapping to the .jsf extension. > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev

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.

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?

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?

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.

It's possible to have a JSF app with no faces-config.xml file. Is a faces-config.xml required for WebBeans?

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?

Does the WebBeans spec say anything about portlets?

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 ----------------------------

Ales and I have now done most of this, you now no longer need to configure any Web Beans glue in .xml (no ejb-jar.xml w/ interceptor binding needed, no jboss-* to enable classloader isolation, no WebBeansListener in web.xml). Much neater, yay! I've left the JSF stuff for now, as this should really be done JBoss AS wide, not just for Web Beans IMO. On 20 Dec 2008, at 17:55, Pete Muir wrote: > The idea here is that a Web Beans RI app requires certain configuration > applied by default (see below), and we should try to provide this > configuration by default when in JBoss 5. The user can still override this > configuration using the relevant XML. We've talked about this before, but > never done anything with it :-) > > Here are the rules > > 1) ejb-jar.xml > > If web-beans.xml is present in the ejb module's META-INF, automatically > add the Web Beans RI SessionBeanInterceptor (see attached ejb-jar.xml for > how we currently configure it). The user can't disable this interceptor. > > > 2) jboss-app.xml > > If web-beans.xml is present in the ejb-module's META-INF, automatically > enable classloader isolation. Any settings in jboss-app.xml override. Is it > possible to explicitly disable classloader isolation? Is this change from > the jboss default too confusing? Another option is to disable if a > jboss-app.xml is present. > > 3) jboss-web.xml > > If web-beans.xml is present in the war's WEB-INF or META-INF, > automatically enable classloader isolation. Any settings in jboss-web.xml > override. Is it possible to explicitly disable classloader isolation? Is > this change from the jboss default too confusing? Another option is to > disable if a jboss-app.xml is present. > > 4) web.xml > If web-beans.xml is present in the war's WEB-INF or META-INF or the ejb > module's META-INF automatically add the WebBeansListener servlet listener > > And one for the JSF2 deployer > > 5) if faces-config.xml is present, automatically add the FacesServlet, > it's mapping to the .jsf extension. > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev