How to get rid in opencms of the CmsVfsResourceNotFoundException when listing WebDAV '__properties' folders? - opencms

With the standard OpenCms WebDAV config, you can get a CmsVfsResourceNotFoundException error when accessing resources via WebDAV.
This is very annoying, because whenever you list the content of any __properties folder, OpenCms dumps 36 stacktrace loglines per file in that folder! If you scan your WebDAV dirs often during debugging (see note 1), these logs makes your life harder. (Of course, you could change the log level to something higher than INFO, but for me that's not acceptable.)
The issue is easily reproducible: point the browser to the opencms-exported webdav path, and click on any __properties dir.
I have found two workarounds, but I'm not really happy with any of them. Perhaps there is a better solution?
Notes
1 I'm debugging some OpenCms modules with NetBeans. I export their sources via OpenCms' WebDAV, and mount them in linux as davfs. If I add them to a NetBeans project, it automatically scans this mounted file hierarchy, resulting in OpenCms getting 'berserk' and beginning to overflow my poor console with useless traces. It gets worse, as NetBeans periodically re-scans these directories.
2 Setting the content-encoding property of every possible file and dir to UTF-8 does not help (the stacktrace claims it is missing).
My relevant environment and settings:
INFO OpenCms version : 8.0.3
INFO System file.encoding : UTF-8
INFO i18n configuration : the JVM default locale is "en"
INFO Initializing WebDAV servlet
INFO Initialized param "listings" with value "true"
INFO Initialized param "readonly" with value "false"
INFO Using repository with name "standard"
web.xml relevant config:
<servlet>
<description>
Creates an access to OpenCms through WebDAV.
</description>
<servlet-name>OpenCmsWebDavServlet</servlet-name>
<servlet-class>org.opencms.webdav.CmsWebdavServlet</servlet-class>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>repository</param-name>
<param-value>standard</param-value>
</init-param>
</servlet>
My opencms-importexport.xml relevant config:
<repositories>
<repository name="standard" class="org.opencms.repository.CmsRepository">
<params>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceExtensionWrapperJsp</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceExtensionWrapperXmlContent</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceExtensionWrapperXmlPage</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceWrapperSystemFolder</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceWrapperPropertyFile</param>
</params>
<filter type="include">
<regex>/</regex>
<regex>/__properties/.*</regex>
<regex>/sites/.*</regex>
<regex>/system/</regex>
<regex>/system/__properties/.*</regex>
<regex>/system/galleries/.*</regex>
<regex>/system/modules/.*</regex>
<regex>/system/workplace/.*</regex>
</filter>
</repository>
My opencms-system.xml relevant config:
<opencms>
<system>
<internationalization>
<localehandler class="org.opencms.i18n.CmsDefaultLocaleHandler"/>
<localesconfigured>
<locale>en</locale>
<locale>de</locale>
</localesconfigured>
<localesdefault>
<locale>en</locale>
<locale>de</locale>
</localesdefault>
<timezone>GMT+01:00</timezone>
</internationalization>
The stacktrace:
01 Aug 2012 18:09:05,607 INFO [.opencms.i18n.CmsLocaleManager: 311] Could not read encoding property for resource "/sites/default/.content/config/__properties/c_0001.html.properties".
org.opencms.file.CmsVfsResourceNotFoundException: Error reading the property value for property "content-encoding" of resource "/.content/config/__properties/c_0001.html.properties".
at org.opencms.file.CmsVfsResourceNotFoundException.createException(CmsVfsResourceNotFoundException.java:71)
at org.opencms.db.CmsDbContext.throwException(CmsDbContext.java:334)
at org.opencms.db.CmsDbContext.report(CmsDbContext.java:286)
at org.opencms.db.CmsSecurityManager.readPropertyObject(CmsSecurityManager.java:4405)
at org.opencms.file.CmsObject.readPropertyObject(CmsObject.java:2681)
at org.opencms.i18n.CmsLocaleManager.getResourceEncoding(CmsLocaleManager.java:305)
at org.opencms.file.wrapper.CmsObjectWrapper.needUtf8Marker(CmsObjectWrapper.java:871)
at org.opencms.file.wrapper.CmsObjectWrapper.getResourcesInFolder(CmsObjectWrapper.java:382)
at org.opencms.repository.CmsRepositorySession.list(CmsRepositorySession.java:268)
at org.opencms.webdav.CmsWebdavServlet.renderHtml(CmsWebdavServlet.java:2480)
at org.opencms.webdav.CmsWebdavServlet.serveResource(CmsWebdavServlet.java:2727)
at org.opencms.webdav.CmsWebdavServlet.doGet(CmsWebdavServlet.java:1208)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at org.opencms.webdav.CmsWebdavServlet.service(CmsWebdavServlet.java:2893)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.opencms.file.CmsVfsResourceNotFoundException: Unable to read resource "/.content/config/__properties".
at org.opencms.db.generic.CmsVfsDriver.readResource(CmsVfsDriver.java:2162)
at org.opencms.db.CmsDriverManager.readResource(CmsDriverManager.java:7293)
at org.opencms.db.CmsDriverManager.readPropertyObjects(CmsDriverManager.java:7110)
at org.opencms.db.CmsDriverManager.readPropertyObject(CmsDriverManager.java:7043)
at org.opencms.db.CmsSecurityManager.readPropertyObject(CmsSecurityManager.java:4403)
... 23 more

I have found two work arounds:
Edit the filter regex to exclude the '__properties' dirs.
In opencms-importexport.xml:
<repository name="webdavrep" class="org.opencms.repository.CmsRepository">
<params><!-- don't change it --></params>
<filter type="include">
<regex>/</regex>
<regex>/__properties/.*</regex>
<regex>/sites/((?!__properties).)*</regex>
<!-- instead of ...
<regex>/sites/.*</regex>
-->
<!-- etc -->
</filter>
</repository>
(Don't forget to update your web.xml to change the webdav repository name.)
Remove the 'CmsResourceWrapperPropertyFile' from the repository.
In opencms-importexport.xml:
<repository name="webdavrep" class="org.opencms.repository.CmsRepository">
<params>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceExtensionWrapperJsp</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceExtensionWrapperXmlContent</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceExtensionWrapperXmlPage</param>
<param name="wrapper">org.opencms.file.wrapper.CmsResourceWrapperSystemFolder</param>
<!-- Do not publish properties ...
<param name="wrapper">org.opencms.file.wrapper.CmsResourceWrapperPropertyFile</param>
-->
</params>
<filter type="include"><!-- don't change it --></filter>
(Again, don't forget to update your web.xml to change the webdav repository name.)

Related

how can I reproduce same WAS ND classloader setup in Liberty Profile

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
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.
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).

JSF web app as OSGi bundle - getting error FacesContextFactory was not configured properly

I'm trying to convert my JSF app into a OSGi Bundle (WAB), but I kept getting the error below when I deploy the war file to glassfish/autodeploy/bundles, which I'm not really sure what it means.
[#|2016-09-06T11:35:05.402+0200|SEVERE|glassfish3.1.2|org.apache.catalina.core.ContainerBase|_ThreadID=61;_ThreadName=pool-5-thread-1;|ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.FacesContextFactory' was not configured properly.
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5389)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2018)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.FacesContextFactory' was not configured properly.
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:292)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4750)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:550)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5366)
... 24 more
Caused by: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.FacesContextFactory' was not configured properly.
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:305)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:219)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:360)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:225)
... 27 more
Caused by: javax.faces.FacesException: com.sun.faces.context.InjectionFacesContextFactory
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:630)
at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:509)
at javax.faces.FactoryFinder.access$400(FactoryFinder.java:139)
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:993)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:343)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:303)
... 30 more
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:623)
... 35 more
|#]
The structure of my war file is as follows:
testWab.war
|
- img/
- META-INF/
|
- MANIFEST.MF
- WEB-INF/
|
- classes/
|
- lib/
|
- primefaces-5.3.jar
|
- javax.servlet.jsp-api-2.2.1.jar
|
- and other jar files
|
- web.xml
|
- faces-config.xml
|
- web.xml
|
- glassfish-web.xml
- views/
|
- all *.xhtml
My web.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Production</param-value>
</context-param>
<context-param>
<param-name>primefaces.FONT_AWESOME</param-name>
<param-value>true</param-value>
</context-param>
<welcome-file-list>
<welcome-file>faces/index.xhtml</welcome-file>
</welcome-file-list>
<!-- Servlet Config -->
<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>*.xhtml</url-pattern>
</servlet-mapping>
</web-app>
And my glassfish-web.xml looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app error-url="">
<context-root>/testWAB</context-root>
<class-loader delegate="false"/>
<property name="useBundledJsf" value="true"/>
</glassfish-web-app>
My MANIFEST.MF is like this:
Manifest-Verion: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: TestWAB
Bundle-Version: 0.1.0.SNAPSHOT
Bundle-Name: Simulation Vis
Import-Package: javax.servlet,
javax.servlet.http,
javax.ws.rs,
javax.ws.rs.core,
org.osgi.framework;version="1.3.0"
Bundle-ClassPath: WEB-INF/classes,
WEB-INF/lib/commons-fileupload-1.3.jar,
WEB-INF/lib/commons-io-2.2.jar,
WEB-INF/lib/el-api-2.2.jar,
WEB-INF/lib/el-impl-2.2.jar,
WEB-INF/lib/javax.faces-api-2.2.jar,
WEB-INF/lib/javax.servlet.jsp-api-2.2.1.jar,
WEB-INF/lib/javax.servlet-api-3.1.0.jar,
WEB-INF/lib/primefaces-5.3.jar
Web-ContextPath: /testWAB
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-Activator: test.Activator
Require-Bundle: myBundle0;bundle-version="0.1.0";visibility:=reexport,
myBundle1;bundle-version="0.1.0";visibility:=reexport,
myBundle2;bundle-version="0.1.0"
Bundle-Vendor: FooBar
OK. So after a lot of hair pulling and keyboard banging, I finally got these frameworks to work together.
Here's for your reference.
Framework version:
Glassfish 3.1.2
Primefaces 5.3.0
OSGi 1.3.0
The Primefaces jar should NOT be in your WAR's WEB-INF/lib folder. It should be deployed as an OSGi Bundle. This is as simple as dropping the jar into glassfish/autodeploy/bundles directory.
Copy the following resource files and directory from the Primefaces jar's META-INF into your web bundle: primefaces-p.taglib.xml, faces-config.xml and resources.
My bundle already has its own faces-config.xml, so I renamed the one from Primefaces primefaces-config.xml, and put it under my bundle's WEB-INF. Then I added the following to my web.xml to use both files:
<context-param>
<param-name>javax.faces.CONFIG_FILES</param-name>
<param-value>
/WEB-INF/faces-config.xml,
/WEB-INF/primefaces-config.xml
</param-value>
</context-param>
In the end, my WAB has the following structure:
testWab.war
img/
resources/ (from Primefaces jar)
META-INF/
MANIFEST.MF
primefaces-p.taglib.xml (from Primefaces jar)
WEB-INF/
classes/
lib/
some jar files EXCLUDE primefaces jar
web.xml
faces-config.xml
primefaces-config.xml
web.xml
glassfish-web.xml
views/
all *.xhtml
The glitches?
Your Primefaces version may not like the jsf version that comes with Glassfish. I suggest you resist the urge to include your own jsf jar and tell Glassfish to useBundledJsf. I tried. Wasted countless hours, and nothing worked.
Ideally, you can upgrade your frameworks to whatever version so that they work well together, but in my case, was not allowed to so here's what I did.
I have Glassfish 3.1.2 which comes with JSF 2.1, which doesn't work with Primefaces 5.3.
I replaced the original glassfish\modules\javax.faces.jar with my javax.faces-2.2.jar.
My glassfish-web.xml looks like this:
<glassfish-web-app error-url="">
<context-root>/testWAB</context-root>
<class-loader delegate="true" />
</glassfish-web-app>
Your WAB suddenly couldn't find any of the Java faces classes.
Make sure bundle classpath is correct and javax.faces.* are listed under Import-Package.
My MANIFEST.MF looks like this:
Manifest-Verion: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: testWAB
Bundle-Version: 0.1.0.SNAPSHOT
Bundle-Name: Simulation Vis
Import-Package: javax.faces;version="2.2.0",
javax.faces.application;version="2.2.0",
javax.faces.bean,
javax.faces.component;version="2.2.0",
javax.faces.context;version="2.2.0",
javax.faces.event;version="2.2.0",
javax.servlet,
javax.servlet.http,
javax.ws.rs,
javax.ws.rs.core,
org.osgi.framework;version="1.3.0"
Bundle-ClassPath: WEB-INF/classes,
WEB-INF/lib/jar1.jar,
WEB-INF/lib/jar2.jar
Web-ContextPath: /testWAB
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Bundle-Activator: test.Activator
Require-Bundle: myBundle1;bundle-version="0.1.0";visibility:=reexport,
myBundle1;bundle-version="0.1.0";visibility:=reexport,
org.primefaces;bundle-version="5.3.0"
Bundle-Vendor: Me

com.sun.faces.spi.InjectionProvider not found by javax.faces-api when deploying JSF WAB to Jetty

I'm trying to deploy simple JSF application packaged ino WAB to Jetty instance running inside Apache Felix OSGI container. But, I keep getting the following exception:
g! May 30, 2014 6:57:31 AM com.sun.faces.spi.InjectionProviderFactory createInstance
WARNING: JSF1033: Resource injection is DISABLED.
May 30, 2014 6:57:31 AM com.sun.faces.config.ConfigureListener contextInitialized
SEVERE: Critical error during deployment:
java.lang.NoClassDefFoundError: com/sun/faces/spi/InjectionProvider
at javax.faces.FactoryFinder$FactoryManager.copyInjectionProviderFromFacesContext(FactoryFinder.java:1051)
at javax.faces.FactoryFinder$FactoryManager.<init>(FactoryFinder.java:1035)
at javax.faces.FactoryFinder$FactoryManagerCache.getApplicationFactoryManager(FactoryFinder.java:856)
at javax.faces.FactoryFinder$FactoryManagerCache.getApplicationFactoryManager(FactoryFinder.java:793)
at javax.faces.FactoryFinder$FactoryManagerCache.access$100(FactoryFinder.java:768)
at javax.faces.FactoryFinder.setFactory(FactoryFinder.java:409)
at com.sun.faces.config.processor.FactoryConfigProcessor.setFactory(FactoryConfigProcessor.java:317)
at com.sun.faces.config.processor.FactoryConfigProcessor.processFactories(FactoryConfigProcessor.java:259)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:216)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:435)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:446)
at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:792)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:296)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1359)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1352)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:744)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:497)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:41)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:498)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:146)
at org.eclipse.jetty.osgi.boot.BundleWebAppProvider.bundleAdded(BundleWebAppProvider.java:154)
at org.eclipse.jetty.osgi.boot.internal.webapp.BundleWatcher.register(BundleWatcher.java:279)
at org.eclipse.jetty.osgi.boot.internal.webapp.BundleWatcher.addingBundle(BundleWatcher.java:189)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:869)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:790)
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:515)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4409)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2098)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: com.sun.faces.spi.InjectionProvider not found by javax.faces-api [21]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1550)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:77)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1988)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 40 more
This is the list of bundles deployed in OSGI container (the last one is my app):
START LEVEL 1
ID|State |Level|Name
0|Active | 0|System Bundle (4.4.0)
1|Active | 1|CDI APIs (1.2.0)
2|Active | 1|Expression Language 3.0 (3.0.0)
3|Active | 1|Injection API (JSR 330) version 1 repackaged as OSGi bundle (2.2.0)
4|Active | 1|javax.interceptor API (1.2.0)
5|Active | 1|Java Servlet API (3.1.0)
6|Active | 1|JavaServer Pages(TM) API (2.3.1)
7|Active | 1|Java Server Pages Standard Tag Library API Bundle (1.2.0.v201105211821)
8|Active | 1|Jetty :: Deployers (9.2.0.M1)
9|Active | 1|Jetty :: Http Utility (9.2.0.M1)
10|Active | 1|Jetty :: IO Utility (9.2.0.M1)
11|Resolved | 1|Jetty JSP Fragment (2.3.3)
12|Active | 1|Jetty :: OSGi :: Boot (9.2.0.M1)
13|Resolved | 1|Jetty-OSGi-Jasper Integration (9.2.0.M1)
14|Active | 1|Jetty Servlet Schemas (3.1.0.M0)
15|Active | 1|Jetty :: Security (9.2.0.M1)
16|Active | 1|Jetty :: Server Core (9.2.0.M1)
17|Active | 1|Jetty :: Servlet Handling (9.2.0.M1)
18|Active | 1|Jetty :: Utilities (9.2.0.M1)
19|Active | 1|Jetty :: Webapp Application Support (9.2.0.M1)
20|Active | 1|Jetty :: XML utilities (9.2.0.M1)
21|Active | 1|JavaServer Faces API 2.2.6 (20140304-1538) (2.2.0)
22|Active | 1|Mojarra JSF Implementation 2.2.6 (20140304-1538) (2.2.6)
23|Active | 1|Apache Felix File Install (3.4.0)
24|Active | 1|Apache Felix Gogo Command (0.12.0)
25|Active | 1|Apache Felix Gogo Runtime (0.12.0)
26|Active | 1|Apache Felix Gogo Shell (0.10.0)
27|Active | 1|Java Server Pages Standard Tag Library Implementation Bundle provided by Glassfish (1.2.0.v201112081803)
28|Active | 1|Eclipse Compiler for Java(TM) (3.8.2.v20130121-145325)
29|Active | 1|osgi.cmpn (5.0.0.201305092017)
30|Active | 1|jsf-maven-osgi (0.9.0)
Application manifest:
Manifest-Version: 1.0
Bundle-SymbolicName: jsf-maven-osgi
Archiver-Version: Plexus Archiver
Built-By: vlada
Bnd-LastModified: 1401425833034
Bundle-ManifestVersion: 2
Import-Package: javax.faces.context;version="[2.2,3)",com.sun.faces.sp
i;version="[2.2,3)",com.sun.faces.config;version="[2.2,3)",com.sun.fa
ces.vendor;version="[2.2,3)",javax.faces.webapp;version="[2.2,3)"
Tool: Bnd-2.1.0.20130426-122213
Export-Package: com.vektorsoft.demux.web.jsf;version="0.9.0"
Bundle-Name: jsf-maven-osgi
Bundle-Version: 0.9.0
Web-ContextPath: /hello
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.8.0_05
And web.xml:
<web-app version="3.1" 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-app_3_1.xsd">
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
<!-- <context-param>
<param-name>com.sun.faces.injectionProvider</param-name>
<param-value> com.sun.faces.vendor.WebContainerInjectionProvider</param-value>
</context-param>-->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</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>*.xhtml</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.xhtml</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
</web-app>
I suppose this is some kind of OSGI classpath issue, since it works fine when deployed in non-OSGI Jetty, but I can't figure out what the problem is. It seems I imported all required packages into WAB, but still nothing.
Hope someone can give me an idea what to look for.
There is an issue with Mojarra 2.x. A class in jsf-api.jar uses a class from jsf-impl.jar and many classes from jsf-impl.jar uses classes from jsf-api.jar. I do not know how they even be able to compile them.
After this issue you would have the problem that the JSF API would not find many factory classes. To solve that, I simply made the jsf-impl bundle to be the fragment of jsf-api. To do that, add the following MANIFEST header into jsf-impl:
Fragment-Host: javax.faces-api
With that, jsf-api and jsf-impl will have the same classloader so the jsf-api will be able to initialize all Factory classes. We patched the jsf-impl jar like this and used JSF within OSGi for several years.
Well, recently we decided not to use JSF anymore as it had many bugs (in conception and implementation).
The Mojarra implementation looks for the web.xml in the wab and parses that by itself during startup. That means that it will not be able to work if the JSF servlet was simply registered with whiteboard pattern or via HTTPService.
Update:
I just remembered that I wrote a Mojarra 2.2 adapter before. See the README for the tricks that made JSF work within an OSGi container: https://github.com/everit-org/osgi-mojarrajsf22adapter
For Eclipse and tomcat
Stop tomcat server
Clean and build project
Clean tomcat
Clean tomcat working directory

how to use PrettyFaces in JSF projet with glassfish as server?

i tryed to use PrettyFaces with my jsf project but i had a error while deploying my projet.
thats what i have done :
i added this to my web.xml :
<filter>
<filter-name>Pretty Filter</filter-name>
<filter-class>com.ocpsoft.pretty.PrettyFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Pretty Filter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
and i created in web inf pretty-config.wml :
<pretty-config xmlns="http://ocpsoft.com/prettyfaces/3.3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ocpsoft.com/prettyfaces/3.3.0
http://ocpsoft.com/xml/ns/prettyfaces/ocpsoft-pretty-faces-3.3.0.xsd">
<url-mapping>
<pattern value="/" />
<view-id value="/faces/*" />
</url-mapping>
</pretty-config>
i added the jar of Prettyfaces to libs
prettyfaces-jsf2-3.3.0-sources
.
but when i deploy my projet i get this errors :
deploy?DEFAULT=C:\Users\hp\Documents\NetBeansProjects\PlanificationDrapage\dist\gfdeploy\PlanificationDrapage&name=PlanificationDrapage&force=true failed on GlassFish Server 3+
Error occurred during deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: java.lang.ClassNotFoundException: com.ocpsoft.pretty.faces.config.PrettyConfigListener. Please see server.log for more details.
C:\Users\hp\Documents\NetBeansProjects\PlanificationDrapage\nbproject\build-impl.xml:294: The module has not been deployed.
i am using netbeans with glassfish.
Update :
i resolved the first problem it was caused by using bad jar .
no i have Prettyfaces integrated and working when the Pretty-config.xhtml is empty but wheni add this code when i run my projet i have no errors but i white page.
thats what i add :
<url-mapping id="accueil">
<pattern value="/" />
<view-id value="/admin/adminHome.xhtml" />
</url-mapping>
how can i solve this problem ??
you are including prettyfaces-jsf2-3.3.0-sources (the sources of Prettyfaces) you have to include the binary jar. From here for example:
http://mvnrepository.com/artifact/com.ocpsoft
Or from here
http://grepcode.com/snapshot/repo1.maven.org/maven2/com.ocpsoft/prettyfaces-jsf2/3.3.0/

Content unparsed through Glassfish 3 though deployment descriptors appear correct

I have dropped a war into the autodeploy of a GlassFish 3 domain and it has exploded fine, showing a subdirectory tree domain1>applications>myApp under which is a WEB-INF>classes>myApp folder tree which stores the classes for myApp.
The app originally used JSF1.2 and Facelets (1.1.15) and was deployed to tomcat 6, but I'm now trying a build using Java EE 6 and GlassFish v3.
I know that Java EE 6 has JSF 2 onboard and Facelets so I've stripped out all the unnecessary jars from my app library leaving RichFaces, and Log4J jars and some Apache commons jars needed to support the app.
The app deploys, but I've got this problem:
The index.xhtml JSF file loads once the app deploys. The page content appears unparsed as the richfaces and jsf tags are ignored although the whole file is sent to the browser. The whole page is encapsulated in a ui:composition facelets tag. I've read elsewhere that this is because the page isn't going through the FacesServlet. Can anyone suggest what I need to do to my deployment descriptors to make this work if they are indeed the problem?
My faces-config.xml has managed-bean setups only; my web.xml contains:
<!-- Faces Servlet -->
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Faces Servlet Mapping -->
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<!-- Added for facelets -->
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.xhtml</param-value>
</context-param>
among a load of other tags. My sun-web.xml contains:
<sun-web-app error-url="">
<context-root>/MyApp</context-root>
<class-loader delegate="false"/>
<jsp-config>
<property name="keepgenerated" value="true">
<description>Keep a copy of the generated servlet class java code.</description>
</property>
</jsp-config>
</sun-web-app>
EDIT
I pointed the browser at http://localhost:9090/myApp/index.jsf and the problem is unchanged, although in the server log I get this
[#|2010-10-15T12:27:17.603+0100|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;||STDOUT| 2010-10-15 12:27:17,603 | INFO | [http-thread-pool-9090-(12)]: Selected [org.ajax4jsf.cache.LRUMapCacheFactory] cache factory
|#]
[#|2010-10-15T12:27:17.603+0100|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;||STDOUT| 2010-10-15 12:27:17,603 | INFO | [http-thread-pool-9090-(12)]: Creating LRUMap cache instance using parameters: {javax.faces.DEFAULT_SUFFIX=.xhtml, com.sun.faces.validateXml=true, com.sun.faces.forceLoadConfiguration=true, facelets.RECREATE_VALUE_EXPRESSION_ON_BUILD_BEFORE_RESTORE=true, org.richfaces.LoadStyleStrategy=ALL, javax.faces.STATE_SAVING_METHOD=server, org.richfaces.CONTROL_SKINNING=enable, org.richfaces.SKIN=glassX, org.richfaces.CONTROL_SKINNING_CLASSES=enable}
|#]
[#|2010-10-15T12:27:17.603+0100|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;||STDOUT| 2010-10-15 12:27:17,603 | INFO | [http-thread-pool-9090-(12)]: Creating LRUMap cache instance of default capacity
|#]
[#|2010-10-15T12:27:17.635+0100|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;||STDOUT| 2010-10-15 12:27:17,635 | INFO | [http-thread-pool-9090-(12)]: Selected [org.ajax4jsf.cache.LRUMapCacheFactory] cache factory
|#]
[#|2010-10-15T12:27:17.635+0100|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;||STDOUT| 2010-10-15 12:27:17,635 | INFO | [http-thread-pool-9090-(12)]: Creating LRUMap cache instance using parameters: {javax.faces.DEFAULT_SUFFIX=.xhtml, com.sun.faces.validateXml=true, com.sun.faces.forceLoadConfiguration=true, facelets.RECREATE_VALUE_EXPRESSION_ON_BUILD_BEFORE_RESTORE=true, org.richfaces.LoadStyleStrategy=ALL, javax.faces.STATE_SAVING_METHOD=server, org.richfaces.CONTROL_SKINNING=enable, org.richfaces.SKIN=glassX, org.richfaces.CONTROL_SKINNING_CLASSES=enable}
|#]
[#|2010-10-15T12:27:17.635+0100|INFO|glassfish3.0.1|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=29;_ThreadName=Thread-1;||STDOUT| 2010-10-15 12:27:17,635 | INFO | [http-thread-pool-9090-(12)]: Creating LRUMap cache instance of default capacity
so it looks like it likes the faces-config.xml contents but it's still not rendering. To confirm, I've specified <url-pattern>*.jsf</url-pattern> in my web.xml deployment descriptor, my javax.faces.DEFAULT_SUFFIX has a param-value of .xhtml and my welcome page and all other web content pages end .xhtml.
Is there any significance in the server returning the same info twice?
Thanks for your help.
EDIT 2
The richfaces-[api|impl-jsf2|ui]-3.3.3.Final jars are in the lib, along with jsf-facelets.jar which is 1.1.15 as recommended here. My web-app descriptor is version="2.5". Because of the fact that I needed to include 1.1.15 of Facelets, and I'm using GlassFish 3 ie. Java EE 6, I've tried setting <class-loader delegate="true"/> to false to try and get my Facelets 1.1.15 jar picked up and used as a preference by the class loader, but it hasn't made any difference.
The faces-config.xml is set to version="2.0":
<faces-config version="2.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd">

Resources