In the new AS5/MC classloader methodology, wouldn't the proper fix be to exclude the builtin JSF classes from deployments that specify this parameter? Like, using classloading metadata somehow... maybe bunding the JSF RI as a "module" and implicitly adding a "depends" thing into any web deployment that does NOT specify the WAR_BUNDLES_JSF_JAR context param.

I guess it might be tricky since it's implemented as a context-param rather than, say, a top-level metadata thinger in jboss-web.xml. But I bet it's still doable this way... where does the WAR deployer live these days? Has it been POJO-ized?

We have a few tests for overriding things like logging, the xml parser impl that rely on this and are working. The general problem with overriding is whether or not the api was designed for it. For example, you cannot override the javax.xml.* classes, only the implementation of the interfaces.

Do the jsf classes in question have a similar factory type of pattern where the implementation is loaded in the context of the war class loader, or are these classes that are bound to some tomcat container class that would require the container to be recreated in the war class loader?

If I run the org.jboss.test.web.test.JSFIntegrationUnitTestCase it looks to be passing, so am I missing some recent change that altered this?

"david.lloyd@jboss.com" wrote:In the new AS5/MC classloader methodology, wouldn't the proper fix be to exclude the builtin JSF classes from deployments that specify this parameter? Like, using classloading metadata somehow... maybe bunding the JSF RI as a "module" and implicitly adding a "depends" thing into any web deployment that does NOT specify the WAR_BUNDLES_JSF_JAR context param.

I guess it might be tricky since it's implemented as a context-param rather than, say, a top-level metadata thinger in jboss-web.xml. But I bet it's still doable this way... where does the WAR deployer live these days? Has it been POJO-ized?

Yes, the "real fix" would be to do like seam-int does and include the JSF classes in the war's classpath if it wants jsf.

There's no problem with reading the WebMetaData in a DESCRIBE deployer for this purpose (including modifying it to include the jsf integration).

This would also avoid having the jsf implementation inside JBossWeb and visible to everything (it would also fix which classloader gets used when it wants to do xml parsing).

You could even choose which version of the jsf classes you want to use.

"scott.stark@jboss.org" wrote:We have a few tests for overriding things like logging, the xml parser impl that rely on this and are working. The general problem with overriding is whether or not the api was designed for it. For example, you cannot override the javax.xml.* classes, only the implementation of the interfaces.

The correct place to exclude javax.* classes should be on WarClassLoaderDeployer or in your own WEB-INF/jboss-classloading.xml

Looks like there is really no need since Adrian already knows the answer. :-)

But for everyone's edification, the problem here is that JSF does indeed use a factory to dispense a javax.faces.context.FacesContext instance. If you use an old JSF 1.1 version of the MyFaces factory with the JSF 1.2 version of the javax.faces classes then the MyFaces implementation will extend javax.faces.faces.FacesContext but it won't override all the needed methods.

Really, I'd like to get rid of this "feature" soon. It was only intended to help ease the transition from 4.0 to 4.2. I think it has outlived its usefulness.

As for creating a JSF deployer, that sounds like a very good idea to me. Then anyone can do whatever whatever they want.

And really, I've been thinking about how we can make this easier for all third-party packages that you add to a WAR. JSF certainly doesn't belong in your WAR and neither does Seam. But neither does RichFaces or Facelets or any of that stuff.

So it seems that what we really need is to say, if you are developing a library that needs to run in a WAR you should create a deployer for it instead. But right now, the doco isn't sufficient for the community to get started. And the creation of such a deployer could be greatly simplified.

I've applied the fix, but I'm seeing this warning while undeploying the test war

12:53:11,412 ERROR [[/bundled-myfaces-hellojsf]] Exception sending context destroyed event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
java.lang.NullPointerException
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:235)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3949)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4615)
at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1175)
at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4705)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performUndeployInternal(TomcatDeployment.java:674)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performUndeploy(TomcatDeployment.java:647)
at org.jboss.web.deployers.AbstractWarDeployment.stop(AbstractWarDeployment.java:480)
at org.jboss.web.deployers.WebModule.stopModule(WebModule.java:134)
at org.jboss.web.deployers.WebModule.stop(WebModule.java:101)