search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.15k stars 592 forks source link

JSF required libraries not included when feature selected. #5639

Closed vandepol closed 5 years ago

vandepol commented 6 years ago

Release Bug (not sure how to tag a release bug)

releasebug

I've migrated the plantsByWebSphere application from tWAS to Liberty and used the included server.xml. This worked in liberty 17.0.0.4, but when I tried it again against the new version of Liberty I got the following exception: 

Stack Dump = java.lang.NoClassDefFoundError: org.apache.commons.collections.FastHashMap
    at org.apache.commons.beanutils.PropertyUtilsBean.getPropertyDescriptor(PropertyUtilsBean.java:926)
    at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:935)
    at org.apache.commons.beanutils.BeanUtilsBean.populate(BeanUtilsBean.java:830)
    at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:433)
    at org.apache.commons.digester.SetPropertiesRule.begin(SetPropertiesRule.java:252)
    at org.apache.commons.digester.Rule.begin(Rule.java:175)
    at org.apache.commons.digester.Digester.startElement(Digester.java:1453)
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    at org.apache.commons.digester.Digester.parse(Digester.java:1745)
    at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:501)
    at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:38)
    at org.apache.myfaces.config.DefaultFacesConfigurationProvider.getStandardFacesConfig(DefaultFacesConfigurationProvider.java:183)
    at org.apache.myfaces.config.DefaultFacesConfigurationMerger.getFacesConfigData(DefaultFacesConfigurationMerger.java:69)
    at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:603)
    at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:421)
    at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
    at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
    at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:119)
    at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:2376)
    at com.ibm.ws.webcontainer31.osgi.webapp.WebApp31.notifyServletContextCreated(WebApp31.java:514)
    at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:1004)
    at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:6566)
    at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApp(DynamicVirtualHost.java:467)
    at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApplication(DynamicVirtualHost.java:462)
    at com.ibm.ws.webcontainer.osgi.WebContainer.startWebApplication(WebContainer.java:1132)
    at com.ibm.ws.webcontainer.osgi.WebContainer.access$000(WebContainer.java:108)
    at com.ibm.ws.webcontainer.osgi.WebContainer$3.run(WebContainer.java:944)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:522)
    at java.util.concurrent.FutureTask.run(FutureTask.java:277)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.lang.Thread.run(Thread.java:812)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.FastHashMap cannot be found by com.ibm.ws.org.apache.commons.beanutils.1.8.3_1.0.22.cl180320180905-2337
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:484)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
    at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:853)

I did find the org.apache.commons.collections jar in the wlp/lib directory so it should be picked up. I think it gets picked up when I select the entire javaee-7.0 feature, however I need JPA 2.0 so I need to use the following feature selection

    <featureManager>
        <feature>jsp-2.3</feature>
        <feature>ejbLite-3.2</feature>
        <feature>servlet-3.1</feature>
        <feature>jsf-2.2</feature>
        <feature>jndi-1.0</feature>
        <feature>cdi-1.2</feature>
        <feature>jdbc-4.1</feature>
        <feature>jpa-2.0</feature>
        <feature>javaMail-1.5</feature>
        <feature>el-3.0</feature>
        <feature>localConnector-1.0</feature>
    </featureManager>

I've included my docker image so you can view the environment including the application and server.xml

vandepol commented 6 years ago

Docker located here if you want to try for yourself: docker run --rm vandepol/liberty-pbw:jsfbug

vandepol commented 6 years ago

I was tracking this down and all the sudden I couldn't reproduce this. Trying to figure out what was different I finally tracked it down what was different with my docker containers. This one is weird, but should help identify why the Jar isn't being loaded.

If starting from the base liberty image, and I install the following features on top: RUN /opt/ibm/wlp/bin/installUtility install --acceptLicense jpa-2.0 javamail-1.5 jsf-2.0 then the libraries get loaded correctly RUN /opt/ibm/wlp/bin/installUtility install --acceptLicense jpa-2.0 javamail-1.5 Then I get the error.

However in my server.xml I'm using jsf-2.2, but I think by downloading jsf-2.0 I get the required libraries.

Dockerfile used:

#IMAGE: Get the base image for Liberty
FROM websphere-liberty:javaee7

#BINARIES: Add in all necessary application binaries
COPY ./server.xml /config
COPY ./server.env /config
COPY ./binary/application/pbwear8.ear /config/app/pbwear8.ear
RUN mkdir /config/lib
COPY ./binary/lib/* /config/lib/

RUN /opt/ibm/wlp/bin/installUtility install  --acceptLicense   jpa-2.0 jsf-2.0 javamail-1.5 
#RUN /opt/ibm/wlp/bin/installUtility install  --acceptLicense jpa-2.0 javamail-1.5
ebreijo commented 6 years ago

I've been trying to reproduce this issue locally by using a javaee 7 Websphere Liberty image, then installing jpa-2.0 and javamail-1.5 features, and finally deploying the app with the server.xml used by the docker image, but at this point I haven't been able to reproduce the issue.

I have checked the com.ibm.websphere.appserver.jsf-2.2.feature file and we are using the commons.collections bundle: -bundles=com.ibm.ws.org.apache.commons.beanutils.1.8.3, \ com.ibm.ws.org.apache.commons.collections, \ com.ibm.ws.jsf.2.2, \ com.ibm.ws.jsf.shared, \ com.ibm.ws.org.apache.commons.discovery.0.2, \ com.ibm.ws.org.apache.commons.codec.1.3, \ com.ibm.ws.org.apache.commons.logging.1.0.3, \ com.ibm.ws.cdi.interfaces, \ com.ibm.ws.org.apache.commons.digester.1.8

The com.ibm.websphere.appserver.jsf-2.2.mf file in the wlp/lib/feature directory also has the reference to the commons.collections: Subsystem-Content: com.ibm.websphere.appserver.javax.cdi-1.2; type="osgi.subsystem.feature", com.ibm.websphere.appserver.servlet-3.1; type="osgi.subsystem.feature", com.ibm.websphere.appserver.javax.validation-1.1; type="osgi.subsystem.feature", com.ibm.websphere.appserver.javax.jsf-2.2; type="osgi.subsystem.feature", com.ibm.websphere.appserver.jsp-2.3; type="osgi.subsystem.feature", com.ibm.websphere.appserver.jsfProvider-2.2.0.MyFaces; type="osgi.subsystem.feature", com.ibm.websphere.appserver.javaeeCompatible-7.0; type="osgi.subsystem.feature", com.ibm.ws.org.apache.commons.beanutils.1.8.3; version="[1.0.0,1.0.200)", com.ibm.ws.org.apache.commons.collections; version="[1.0.0,1.0.200)",

I finally used the OSGI console in the docker image and I can confirm that the com.ibm.ws.org.apache.commons.collections is ACTIVE.

So, I'm not sure what's happening here, but it could be some kind of classloader issue with docker containers or maybe it's something odd with how the docker container is built.

@vandepol can you please collect the classloader traces: http://www-01.ibm.com/support/docview.wss?uid=swg21972177

We will need someone from classloader team to take a look to this issue.

@andymc12 Can you please give us some help here?

ebreijo commented 6 years ago

Andy believes that this issue can be fixed this by making the the commons-collections imports from beanutils non-optional. There is a comment in the bnd.overrides file that says it is "optional to avoid breaking existing features", but there is only one other feature that references beanutils, com.ibm.websphere.appserver.beanValidationCore-1.0 - so he thinks the fix should be to make the import non-optional and to add commons-collection to the beanValidationCore-1.0 feature.

He is currently working on the fix.

ebreijo commented 5 years ago

@vandepol is trying to download a docker image with the latest open liberty that includes Andy's fix. Once he is able to test against the fix, if everything works fine, I'll close this issue.

vandepol commented 5 years ago

The fix theoretically should work, I'm unable to test this since there are no test docker builds and this is only evident with docker builds tagged with WebProfile7. We can test this once released, low risk to include I believe