2个具有相同名称的类在WebSphere Portal的Portlet中的不同jar中

Question

I am working on a portlet project and came across a problem with 2 classes with same name (including packages) in different .jar files. I have com.ibm.ws.webcontainer.jar as a default WebSphere library and jsf-impl.jar which is necessary for some JSF features.
The problem comes out when PortletFacesContextFactoryImpl class (another JSF class) tries to get access to com.sun.faces.util.Util.parameterNonNull(Object arg) method and I get NoSuchMethodError .
I tried setting classloader policy to PARENT_LAST, this doesn't help. I can't remove com.ibm.ws.webcontainer.jar from the server, but when I try to use Util class in my code, the only option is the class from it, not from jsf-impl.jar . jsf-impl.jar is included into Java Build Path.

How can this problem be solved since I cannot alter PortletFacesContextFactoryImpl source and move .jar with wrong class?

Answer 1

Parent Last should be your solution. WebSphere Portal deploys portlet application with Parent Last as default, but it does not hurt to double check it at the WebSphere Application Server Integrated Solutions Console (Admin Console) >

However, it also depends on your portlet application setup. I assume it is com.sun.faces.util.Util which is troubling you. On my system, this class is located in jsf-impl.jar and the Application Server Web Container . In order to get it to work, jsf-impl.jar needs to be placed in the WEB-INF/lib directory of your portlet application. To verify that, use the Class Loader View of WAS: Admin Console > Troubleshooting > Class loader viewer > WebSphere_Portal > Applications and then the your portlet application. It must start with PA. Switch to the table view and search for the class.

You also mentioned the Java Build Path . This is another topic and depends on your IDE - assumingly Eclipse. Check the Order and Export tab, jsf-impl.jar should be placed at the top, so that it overrules the server runtime classpath entries.

Answer 2

PARENT_LAST classpath setting will help you. However, for this setting to be done, your portlet muste be packaged as a EAR. If your portlet is packaged as a war and you configure the classpath settings manually, they get erased everytime you deploy the portlet.