Metadata addons

[alesj]

Moving discussion to the forum. Pete's initial post.

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.

[alesj]

Stan's reply.

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?

[alesj]

• https://jira.jboss.org/jira/browse/WBRI-86


• http://anonsvn.jboss.org/repos/jbossas/projects/webbeans-ri-int/trunk/microcontainer/src/main/java/org/jboss/webbeans/integration/microcontainer/deployer/metadata/

[gavin.king]

Ales, this kind of discussion really belongs on the webbeans-dev mailing list.

[alesj]

Gavin King wrote on Dec 29, 2008 16:24:


Ales, this kind of discussion really belongs on the webbeans-dev mailing list.

It's already there.

I just posted it here, so I can read it in one piece, instead of jumping from email to email. :-)

But you're right, this is user forum,

which only suggests we need a dev forum as well. ;-)