JSF 2.0检验总结之:同一个JBOSS 5.1.0 jsf 2.0(for primefaces) +JSF 1.2 同时运行的总结
公司原来有个产品是基于jboss 5.1.0 +jsf 1.2+EJB来开发的,由于jboss 5.1.0默认的提供了对jsf 1.2的支持,所以很容易的进行开发和部署,最近由于产品升级,要求前台需要用primefaces来实现,primefaces是基于jsf 2.0的,同时也要求旧的产品也可以在同一个runtime下运行
由于相同产品的两个不同实现要在同一个jboss 的ear下运行(jsf 1.2 A.war jsf 2.0 B.war),考虑到两个war依赖的jar会不同,所以决定分成两个独立的war包,其中A.war中不包含jsf 1.2 相关的jar,而B.war中则包含了jsf 2.0 以及primefaces.jar. 可是在部署的时候总是会报ClassCastException的异常,通过对异常的分析得出的结论是由于B.war 中包含了jsf 2.0的jar,与jboss 5.1.0 中自带的jsf jar 冲突导致.
关于解决jsf 升级导致的classcast exception最常见的解决方案就是替换掉jboss 5.1.0中与jsf 相关的jar 为jsf 2.0 的jar,然后在部署B.war时,确保B.war 中不包含JSF 2.0 相关的jar,可是考虑到本次产品升级还要求旧的产品也要在一起运行,所以只能采用war 包class loader隔离的方法来实现(指定war的采用自己的class loader,这样就不会有class cast exception).
方案一:替换掉jboss 5.1.0 中jsf 1.2 相关的jar
1. This is what I have in jboss-5.0.1.GA\server\yourprofile\deploy\jbossweb.sar\jsf-libs
By default JBoss (prior to version 3.2) uses a flat class loading model that avoids the need to redundantly include classes in different layers. WAR files would only have the web contents and servlets, EJBs their interfaces, implementations and types, etc. Canonical packaging works correctly with this model.
However, if you have applications that cannot share classes because of version conflicts, then you need to isolate the classes from other deployments. Without isolation, common errors seen areClassCastException, IllegalAccessErrors, VerifyErrors and in general, strange behavior that changes as new deployments are added and removed.
There are two levels of scoping, isolation from other deployments, and isolation that overrides the loading of JBoss server classes. With nested modules, only the top level file may specify class loader scoping. If you have a.ear file containing other modules, only scoping specified in the.ear's META-INF/jboss-app.xml is used. This also applies for any other deployment which contains sub-deployments. For example, if a.sar contains a .war deployment, only the .sar META-INF/jboss-service.xml scoping has effect.
For .ear files, in yourjboss-app.xml, add the following descriptor fragment construct to enable scoped class loading:
For .war files, in yourjboss-web.xml, the following template applies:
Note for AS 4.2.x and versions till 5.x: As of at least JBoss 4.2.1, the
Interestingly enough, 4.0.5 seems to support both configurations.*
For .sar files, in yourjboss-service.xml, the following template applies:
Check the corresponding DTD found in the docs/dtd directory of the distribution for the complete content model.
Note for 5.x and later versions: The above mentioned configuration might still work with the 4.0.x till 5.x version due to their xsd/dtd, but for versions 5.x and above the old configuration still applies for jboss-web.xml:
The com.example:archive=unique-archive-name strings are JMXObjectName
strings. These have no particular significance other than that they must be unique.
It might be useful to use the same name as used for the .ear, .war, or .sar file.
For example, for a petstore.ear file, use:com.example:loader=petstore.ear as the repository name.
The loader-repository ObjectName will appear in the JMX-Console (http://localhost:8080/jmx-console/).
This MBean is great for debugging any class-loading issues which might arise.
The hierarchical loaders created from the repository wll appear together under theloader-repository domain name,
com.example in the example.
Isolation with Overriding Server Classes
Use the following constructs to enabled scoped class loading with the deployment classes overriding the server classes.
Note: See comment above regarding web class loader isolation.
The isolated EAR or WAR repository will load its libraries in this order:
The libraries in server/default/lib get mixed together with jbossweb-tomcat50.sar in no specific order (for details look into the loader-repository in the JMX-console).
The Web Container
In jboss-3.2.3, the jbossweb-tomcat41.sar is configured to use a unified class loader as the web application class loader. This is controlled by theUseJBossWebLoader attribute in the jbossweb-tomcat41.sar/META-INF/jboss-service.xml descriptor. The use of a unified class loader means that the classes available in the war inside of the WEB-INF/classes and WEB-INF/lib are incorporated into the default shared class loader repository. This may not be what you want as its contrary to the default servlet 2.3 class loading model and can result in sharing of classes/resources between web applications. You can disable this by setting this attribute to false.
The Web Container from 4.0.2
From 4.0.2 JBoss has changed to the Servlet spec classloading model, i.e. it uses the Tomcat classloader. See the relatedJIRA Task
Simplified Configuration from 3.2.4
From JBoss-3.2.4 the EAR deployer provides a simplified version of the isolation. You can configure all your ears to be in isolated classloader spaces using call by value for remote interfaces.
The EARDeployer is configured in conf/jboss-service.xml for versions 3.x and in deploy/ear-deployer.xml for versions 4.x+
Accessing EJBs in isolated ears
If you want to make JNDI lookups across EARs that are isolated, you need to force
marshalling of the lookup, e.g. if you have the following ejb-ref in your ejb-jar.xml
that references an EJB in an isolated EAR
In jboss.xml use the full scheme to define the lookup:
You can also use the full scheme in lookups from non-EJB clients such as standalone applications or JSP pages. In this case you would be encoding deployment knowledge into the code - the applications will always use call-by-value even if your needs change. If you are retro-fitting classloader isolation you may also have a lot of lookup code to change, although you should probably have used a constant or lookup service to hold the actual name.
An alternative is to force all JNDI lookups to be call-by-value, which you can do in/deploy/naming-service.xml (This used to reference
/conf/jboss-service.xml, which is WRONG for 4.0.3) in the section headed JNDI. Change the jboss:service=Naming bean
definition so that the CallByValue attribute reads:
This is indiscriminate - JBoss will be unable to optimise any JNDI calls any more, but may be appropriate in some circumstances.
Performance note - Call By Value
The use of call by value and marshalling is very inefficient. It typically means
method invocations take 10 times the cpu. Why? Compare Call By Value with Call By Reference
Call By Reference
Call By Value
The marshalling and unmarshalling uses a lot of cpu.
Searching for “JBoss 5 with JSF 2” results in a bunch of messages explaining that “it can’t be done,” or “it shouldn’t be done,” or some other nonsense like “just remove JSF from JBoss” which obviously will break any already existing web application and is not an option in a production environment. The following is the solution and allows a web app in JBoss 5.0.1GA to use JSF 2 while leaving the built in JSF 1.2 on JBoss alone. So I think this is what people are actually looking for when they search for “JSF 2 with JBoss 5.” Note: I haven’t tried getting this to work with “MyEclipse,” only plain old Eclipse.
If you read the stuff you were copying and pasting then you’ll notice that .xhtml is used instead of the default .jsp. The additional information above should be everything necessary to get a basic example to work – the one athttp://www.coreservlets.com/JSF-Tutorial/jsf2/#Getting-Started is the one I used.
Common Error Messages
You may run into these when trying to use JSF 2 on JBoss 5 without doing what’s listed above.
The WAR_BUNDLES_JSF_IMPL option is from Shivaji Byrapaneni at http://community.jboss.org/message/54085.