2

I have certain web aplication based on JSF and CDI which works perfectly in Websphere ND 8.5. Nevertheless, it doesn't work in Liberty Profile 16 (WebSphere Application Server 16.0.0.3/wlp-1.0.14). If I tried to start the Liberty Profile with war already deployed to it, it caused

com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001301: Annotation @javax.inject.Named(value=oam_FLOW_BUILDER_FACTORY_BEAN_NAME) is not a qualifier

The error is the same when I tried to start with either

<webApplication id="myWebApp" location="myWebApp.war" name="myWebApp">
 <classloader delegation="parentFirst"/>
</webApplication>

or

<webApplication id="myWebApp" location="myWebApp.war" name="myWebApp">
 <classloader delegation="parentLast"/>
</webApplication>

I am using these features:

<featureManager>
     <feature>webProfile-7.0</feature>
     <feature>localConnector-1.0</feature>
     <feature>cdi-1.2</feature>
     <feature>servlet-3.1</feature>
 </featureManager>

If I start Liberty Profile without myWebApp and then I try to add the web application via Eclipse, I get

com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: Exception 0 : javax.enterprise.event.ObserverException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40) at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:96) at org.jboss.weld.injection.MethodInvocationStrategy$SpecialParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:309) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:287) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:302) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:291) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:160) at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53) at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44) at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:62) at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:422) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83) at com.ibm.ws.cdi.impl.CDIContainerImpl.applicationStarting(CDIContainerImpl.java:149) at com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:353) at com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:29) at com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:51) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:788) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:815) at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:66) at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1192) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.performAction(ApplicationStateMachineImpl.java:1038) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:813) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.util.ServiceConfigurationError: com.sun.faces.util.cdi11.CDIUtil: Provider com.sun.faces.util.cdi11.CDIUtilImpl not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:239) at java.util.ServiceLoader.access$300(ServiceLoader.java:185) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at com.sun.faces.flow.FlowCDIExtension.afterBeanDiscovery(FlowCDIExtension.java:107) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)

I heard someone saying that it is caused because reflection (certain feature that CDI depends on) doesn't work in Liberty Profile but it does work in WAS ND. Honestly, I don't think this is a final explanation. I tend to believe that it is some trick related to classloader which I am missing.

The entire libraries list is:

"wsdl4j.jar" "all-themes-1.0.10.jar" "axis.jar" "check-sessionid.jar" "commons-discovery-0.2.jar" "commons-logging.jar" "javax.faces-2.2.8.jar" "javax.servlet_3.0.0.jar" "javax-inject.jar" "jaxrpc.jar" "joda-time-2.9.4.jar" "jsf-api-2.2.8.jar" "jsf-impl-2.2.8.jar" "log4j-1.2.17.jar" "log4j-boot.jar" "lombok.jar" "ojdbc6.jar" "primefaces-5.1.RC1.jar" "primefaces-5.1.RC1-sources.jar" "saaj.jar"

In WebSphere ND 8.5 I successfuly start the same web aplication using these setup:

1 - Server-specific Application Settings: Classloader policy

2 - Class loader order: Classes loaded with parent class loader first

3 - WAR class loader policy: Class loader for each WAR file in application

4 - Shared Libraries:

cells:hohmlweb01-aixCell01:nodes:hohmlweb01-aixNode01:servers:Sistemas_MyCompany_HML

Cell=hohmlweb01-aixCell01, Profile=Dmgr01>Shared Libraries > icefaces4.0.0 Classpath: /home/sisorb/icefaces-ace-4.0.0.jar /home/sisorb/icepush-4.0.0.jar /home/sisorb/icefaces-4.0.0.jar /home/sisorb/jfreechart-1.0.19.jar
Shared Libraries > jsf_versao_228 Classpath: /home/sisorb/jsf-api-2.2.8.jar /home/sisorb/jsf-impl-2.2.8.jar /home/sisorb/javax.faces-2.2.8.jar

If someone can at least tell me how to reproduce such WAS ND configuration in Liberty Profile it will be highly appreciatted. Probably I can fix the issue by replicating same class loading configuration.

P.S.: this question was originally created in other forum but since I get no answer at all I am sharing my doubt here as well (https://developer.ibm.com/answers/questions/323283/how-can-i-reproduce-same-was-nd-classloader-setup.html)

* New Lines I commented ConfigureListener as suggested *

    <display-name>CallCenter</display-name>
<!--<listener>
        <listener-class>com.sun.faces.config.ConfigureListener</listener-class>
    </listener> -->
    <listener>
        <listener-class>
            com.mycomp.Inicialize
        </listener-class>
    </listener>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>
    <context-param>   
        <param-name>primefaces.THEME</param-name>
        <param-value>glass-x</param-value> 
        <!-- <param-value>bluesky</param-value>  --> 
    </context-param>
    <context-param>
        <description>State saving method: 'client' or 'server' (=default). See JSF Specification 2.5.2</description>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>
  • 2016/Nov/30 at 12:30am Brazilian TIme I removed "javax.faces-2.2.8.jar" "jsf-api-2.2.8.jar" "jsf-impl-2.2.8.jar" I left "all-themes-1.0.10.jar" "axis.jar" "check-sessionid.jar" "commons-discovery-0.2.jar" "commons-logging.jar" "javax.servlet_3.0.0.jar" "javax-inject.jar" "jaxrpc.jar" "joda-time-2.9.4.jar" "log4j-1.2.17.jar" "log4j-boot.jar" "lombok.jar" "ojdbc6.jar" "primefaces-5.1.RC1.jar" "primefaces-5.1.RC1-sources.jar" "saaj.jar" "wsdl4j.jar"

Then I got a new error:

Application Error
SRVE0777E: Exceção lançada pela classe de aplicativo 'javax.faces.webapp.FacesServlet.service:230'
javax.servlet.ServletException: javax.el.PropertyNotFoundException: Não alcançável no destino, identificador 'dashBean' resolvido como nulo
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:230)
at [internal classes]
Caused by: org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException: javax.el.PropertyNotFoundException: Não alcançável no destino, identificador 'dashBean' resolvido como nulo
at org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.setValue(ContextAwareTagValueExpression.java:157)
... 1 more
Caused by: javax.el.PropertyNotFoundException: Não alcançável no destino, identificador 'dashBean' resolvido como nulo
at org.apache.el.parser.AstValue.getTarget(AstValue.java:72)
... 1 more

*Added 2016/Nov/30 at 2h30pm Brazilian Time

faces-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<faces-config
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
    version="2.2">

    <application>
    <action-listener>org.primefaces.application.DialogActionListener</action-listener>
    <navigation-handler>org.primefaces.application.DialogNavigationHandler</navigation-handler>
    <view-handler>org.primefaces.application.DialogViewHandler</view-handler>
</application>

</faces-config>

Websphere Liberty Profile - server.xml

<featureManager>
    <feature>localConnector-1.0</feature>
    <feature>cdi-1.2</feature>
    <feature>jsf-2.2</feature>
</featureManager>

*Added 2016/11/30 at 4:40pm Brazilian Time after deleted two more jars (javax.servlet_3.0.0 and javax-inject)

FFDC* created "com.ibm.wsspi.injectionengine.InjectionException: java.lang.NoClassDefFoundError: ServletContextEvent com.ibm.ws.webcontainer.webapp.WebApp.loadListener 672"

*FFDC is the deeper log statement we can see

WebSphere Liberty Profile log FFDC

Exception = com.ibm.wsspi.injectionengine.InjectionException
Source = com.ibm.ws.webcontainer.webapp.WebApp.loadListener
probeid = 672
Stack Dump = com.ibm.wsspi.injectionengine.InjectionException: java.lang.NoClassDefFoundError: ServletContextEvent
    at com.ibm.ws.webcontainer.osgi.webapp.WebApp.inject(WebApp.java:1282)
    at com.ibm.ws.webcontainer.osgi.webapp.WebApp.injectAndPostConstruct(WebApp.java:1424)
    at com.ibm.ws.webcontainer.osgi.webapp.WebApp.injectAndPostConstruct(WebApp.java:1412)
    at com.ibm.ws.webcontainer.osgi.webapp.WebApp.loadListener(WebApp.java:818)
    at com.ibm.ws.webcontainer.webapp.WebApp.loadLifecycleListeners(WebApp.java:2251)
    at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:1039)
    at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:6545)
    at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApp(DynamicVirtualHost.java:466)
    at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.createRunnableHandler(DynamicVirtualHost.java:264)
    at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.createRunnableHandler(DynamicVirtualHost.java:329)
    at com.ibm.ws.http.internal.VirtualHostImpl.discriminate(VirtualHostImpl.java:251)
    at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:301)
    at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:471)
    at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:405)
    at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:285)
    at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:256)
    at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:174)
    at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:83)
    at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
    at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
    at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:929)
    at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1018)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoClassDefFoundError: ServletContextEvent
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
    at java.lang.Class.getDeclaredMethods(Class.java:1975)
    at org.jboss.weld.annotated.slim.backed.SecurityActions.getDeclaredMethods(SecurityActions.java:41)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:194)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.computeValue(BackedAnnotatedType.java:188)
    at org.jboss.weld.util.LazyValueHolder.get(LazyValueHolder.java:35)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$EagerlyInitializedLazyValueHolder.<init>(BackedAnnotatedType.java:156)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:188)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType$BackedAnnotatedMethods.<init>(BackedAnnotatedType.java:188)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.<init>(BackedAnnotatedType.java:63)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotatedType.of(BackedAnnotatedType.java:44)
    at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:83)
    at org.jboss.weld.resources.ClassTransformer$TransformClassToBackedAnnotatedType.load(ClassTransformer.java:80)
    at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
    at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
    at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
    at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
    at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
    at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
    at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
    at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
    at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
    at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:175)
    at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:194)
    at org.jboss.weld.manager.BeanManagerImpl.createAnnotatedType(BeanManagerImpl.java:1215)
    at com.ibm.ws.cdi.impl.managedobject.AbstractManagedObjectFactory.getInjectionTarget(AbstractManagedObjectFactory.java:177)
    at com.ibm.ws.cdi.impl.managedobject.AbstractManagedObjectFactory.createManagedObject(AbstractManagedObjectFactory.java:204)
    at com.ibm.ws.cdi.impl.managedobject.CDIManagedObjectFactoryImpl.createManagedObject(CDIManagedObjectFactoryImpl.java:60)
    at com.ibm.ws.webcontainer.osgi.webapp.WebApp.inject(WebApp.java:1258)
    ... 24 more
Caused by: java.lang.ClassNotFoundException: ServletContextEvent
    at com.ibm.ws.classloading.internal.AppClassLoader.findClassCommonLibraryClassLoaders(AppClassLoader.java:488)
    at com.ibm.ws.classloading.internal.AppClassLoader.findClass(AppClassLoader.java:271)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at com.ibm.ws.classloading.internal.AppClassLoader.findOrDelegateLoadClass(AppClassLoader.java:466)
    at com.ibm.ws.classloading.internal.AppClassLoader.loadClass(AppClassLoader.java:438)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 54 more
DemeCarvO
  • 367
  • 2
  • 10
  • 25
  • For the EL exception, take a close look at BalusC's answer here, specifically 1a http://stackoverflow.com/a/30128396/3864977 – wtlucy Nov 30 '16 at 15:22

2 Answers2

1

From your second stack trace, it looks like one of the jars in your application is registering a CDI extension. When this extension is called, it tries to load the CDI11Util service but doesn't get an object of the expected type.

I suspect that it may be the jsf-impl.jar doing this. As you're using the webProfile-7.0 feature (which includes JSF), you shouldn't be providing your own JSF implementation in your application. Could you try removing this jar?

As a side note, you shouldn't need the servlet, faces, inject or jsf API jars either as the server will provide these classes for your application.

As a second side note, the default classloader setup in Liberty is as you describe in your question (classloader is parent first, each WAR has its own classloader).

Azquelt
  • 1,086
  • 11
  • 14
  • Azquelt, I tried your suggestion (just delete jsf-impl.jar but I am getting the same error I just commented to Wtlucy few minutes ago – DemeCarvO Nov 29 '16 at 18:43
1

As mentioned, the webProfile-7.0 feature includes the jsf-2.2 feature, which provides the same EE feature (JSF 2.2) as the jsf-* jars you're bundling in your application. You can likely resolve this issue by choosing one JSF implementation to use. There are two options:

1) Bundle a JSF implementation with your application: remove the webProfile-7.0 feature from your server definition and only enable the (non-JSF) features you need.

2) Remove the jsf-api and jsf-impl jars from your application. This is the recommended route: WebSphere Liberty provides the MyFaces JSF 2.2 implementation. Here is some additional information for configuring the jsf-2.2 feature.

wtlucy
  • 670
  • 3
  • 10
  • Wtlucy, I tried your second suggestion and I got certain error message basically saying that A JSF implementaio was selected however there is certain Sun RI ConfigureListenr registered as well. P.S. I translated the message since the original language is in portuguese: The full message in portuguese is"[ADVERTÊNCIA] JSFG0853W: A Implementação de JSF do MyFaces está selecionada para MyWebapp, mas há também um Sun RI ConfigureListener registrado." – DemeCarvO Nov 29 '16 at 18:07
  • That warning suggest that there is a Mojarra ConfigureListener registered in your application's web.xml. Since you want to use Liberty's MyFaces implementation, you can remove that listener. – wtlucy Nov 29 '16 at 18:25
  • Wtlucy, I got same error message. I am adding my web.xml (only relevant parts) – DemeCarvO Nov 29 '16 at 18:39
  • If the ConfigureListener isn't defined in your web.xml and you're getting the same warning, then you must still have a Mojarra (sunRI) JAR on your classpath somewhere. Make sure that you've removed every JSF library from your application. BalusC provides more information about the listener here: http://stackoverflow.com/a/20264804/3864977 – wtlucy Nov 29 '16 at 19:47
  • I deleted everything I found after searched by *jsf*. I am still getting same error message. Could the primefaces libs I am using be the root cause? – DemeCarvO Nov 29 '16 at 21:27
  • Is the "javax.faces-2.2.8.jar" still in your application? That's a Mojarra JSF library, too. Please list your remaining libraries if the error persists. – wtlucy Nov 30 '16 at 13:38
  • I updated my question informing the libraries. Now I got a new error basicalying saying org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException: javax.el.PropertyNotFoundException: Destination not reachable, identifier 'dashBean' resolved as null. P.S. translated from portuguese statement " Não alcançável no destino, identificador 'dashBean' resolvido como nulo" – DemeCarvO Nov 30 '16 at 14:55
  • I updated my question with faces-config and server.xml. Do you think could exist some conflict because Liberty Profile enabled cdi1.2 and version in faces-config is 1.0? Although it may appear a naive question we are running this application successfully in WAS ND 8.5 and in GlassFish 4.0 with no changes at all. – DemeCarvO Nov 30 '16 at 16:27
  • It's likely that there's still some configuration issue. I'd remove two more libraries from your application - javax.servlet_3.0.0.jar and javax-inject.jar. Your faces-config looks fine. I don't know what you mean with "enabled cdi1.2 and version in faces-config is 1.0". – wtlucy Nov 30 '16 at 17:10
  • I got same error. I updated my question with FFDC (deep log statements from WebSphere). PS1. with "enabled cdi1.2" I mean that, in WebSphere Liberty Profile configuration, known as servers/defaultServer/server.xml, I have cdi1.2 enabled and in my faces-config.xml I see xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd" version="2.2". The link you shared with me there is certain discussion about such file faces-config.xml not been necessary in CDI1.1 but required in CDI1.0. Since my server has CDI1.2 enabled I made question – DemeCarvO Nov 30 '16 at 18:49
  • I've tried reproducing your latest FFDC, with no luck. I've got three requests: 1) The ClassNotFoundException suggests that ServletContextEvent is still somewhere on your classpath. If you're absolutely sure it's not, try restarting the server with the "--clean" switch. 2) In the Knowledge Center I link I provided earlier, it talks about adding a beans.xml to the application. Have you done that? 3) If you still have this FFDC, please update with a list of your current libraries, your classloader policy, and any information you can give about the injectable classes in your app. – wtlucy Dec 05 '16 at 16:35