Content unparsed through Glassfish 3 though deployment descriptors appear correct - jsf

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">

Related

Failed to define class jakarta.faces.webapp.FacesServlet

I've got following error when I want to start Wildfly server:
09:26:10,548 WARN [org.jboss.modules.define] (MSC service thread 1-1)
Failed to define class jakarta.faces.webapp.FacesServlet in Module
"deployment.demo-0.0.1-SNAPSHOT.war" from Service Module Loader:
java.lang.NoClassDefFoundError: Failed to link...
But after I change (in web.xml file):
<servlet-class>jakarta.faces.webapp.FacesServlet</servlet-class>
to
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
the error is gone.
I've tried it with both version 4.0.0 and 3.0.0 of jakarta.faces-api dependency:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>demo</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<dependencies>
<!-- https://mvnrepository.com/artifact/jakarta.faces/jakarta.faces-api -->
<dependency>
<groupId>jakarta.faces</groupId>
<artifactId>jakarta.faces-api</artifactId>
<version>4.0.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.3.2</version>
</plugin>
</plugins>
</build>
</project>
And here is my web.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
version="5.0">
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>jakarta.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>
Based on jakarta.ee/specifications/faces/3.0 and jakarta.ee/specifications/faces/4.0 I can use jakarta.faces.webapp.FacesServlet class, So why I got the error?
I'm using latest Eclipse (Version: 2022-03 (4.23.0)) and wildfly-26.1.0.Final.
According to the WildFly download page, wildfly-26.1.0.Final is not a Jakarta EE 9 server, let alone a Jakarta EE 10 server. It's a Jakarta EE 8 server.
Jakarta EE 8 in turn ships with JSF 2.3 (and Servlet 4.0).
This means that you should be using javax.faces.* package and the faces-config.xml should be conform JSF 2.3 and web.xml should be conform Servlet 4.0.
You most probably intended to pick the wildfly-preview-26.1.0.Final download link, provided by the section above of it, specifically labeled as Preview. This one is a Jakarta EE 9 server which is the first one with Jakartified package names (i.e. jakarta.* instead of javax.*) and ships with JSF 3.0 (and Servlet 5.0). The Jakarta EE 10 implementation will be provided by the upcoming WildFly 27.x, currently still in Alpha stage. It's going to provide Faces 4.0 (and Servlet 6.0).
That said, your pom.xml is incorrect for a full fledged Jakarta EE server. You should never manually ship loose Jakarta EE artifacts such as JSF along with the webapp. You should declare the entire Jakarta EE dependency as provided instead of the individual JSF dependency as a physical JAR file enclosed in the WAR. Below one is for Jakarta EE 8:
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>8.0.0</version>
<scope>provided</scope>
</dependency>
That's really all you need in pom.xml.
See also:
How to properly install and configure JSF libraries via Maven?
JSF 2.3 tutorial with WildFly and Eclipse
What are the namespaces for "h", "f", ... in a JSF page for Jakarta EE 9?

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

java.lang.StackOverflowError at javax.faces.context.FacesContext.getAttributes(FacesContext.java:64)

when I hit the application URL (http://localhost:9082/pages/upload.jsf), i am shown nothing but "Error:500 StackOverflowError" on the browser.
From my groundwork on this issue, I could see this could propably be due to some recursion issue.
And the server on which my application is deployed is WAS 8
Somebody please help me on how to proceed with this. I know this is vague, please let me know if I need to share anything. (Eg. error messages on the console and stuff)
at javax.faces.context.FacesContext.getAttributes(FacesContext.java:64)
at javax.faces.context.FacesContext.getAttributes(FacesContext.java:64)
[the same line repeated many times]
at javax.faces.context.FacesContext.getAttributes(FacesContext.java:64)
at javax.faces.context.FacesContext.getAttributes(FacesContext.java:64)
at org.apache.myfaces.application.ResourceHandlerImpl.isResourceRequest(ResourceHandlerImpl.java:416)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:180)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1188)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:763)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:454)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:125)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:92)
at com.lmig.putt.customComponents.UploadFilter.doFilter(UploadFilter.java:61)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:192)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:89)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:919)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1016)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3703)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:962)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:195)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:452)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:511)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:305)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture$1.run(AsyncChannelFuture.java:205)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659)
` this is the error message that I find on console once I hit the URL. Please help me as I find it totally new and a hard nut to crack
Web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>PUTT</display-name>
<context-param>
<param-name>log4ConfigLocation</param-name>
<param-value>/WEB-INF/classes/log4j.properties</param-value>
</context-param>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/application-context.xml</param-value>
</context-param>
<!-- Log4jConfigListener also tries to
set the webAppRootKey. solve this by adding the following statements in web.xml -->
<context-param>
<param-name>log4jExposeWebAppRoot</param-name>
<param-value>false</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>
<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
<jsp-config>
<taglib>
<taglib-uri>http://www.lmig.com/PUTT/upload</taglib-uri>
<taglib-location>/WEB-INF/upload.tld</taglib-location>
</taglib>
</jsp-config>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<filter>
<filter-name>Upload Filter</filter-name>
<filter-class>com.lmig.putt.customComponents.UploadFilter</filter-class>
<init-param>
<param-name>com.lmig.putt.customComponents.UploadFilter.sizeThreshold</param-name>
<param-value>1024</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Upload Filter</filter-name>
<url-pattern>/pages/upload.jsf</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>Upload Filter</filter-name>
<url-pattern>/pages/upload.jsp</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>
javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<resource-ref>
<description>DataSource</description>
<res-ref-name>jdbc/db2DS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
</web-app>
faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- <faces-config version="1.2" 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_1_2.xsd"> -->
<faces-config 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-facesconfig_2_0.xsd"
version="2.0">
.
.
.
.
</faces-config>
Based on MyFaces 2.0.5 source code, where the line numbers from your stack trace matches, the FacesContext#getAttributes() look like this:
55 public Map<Object, Object> getAttributes()
56 {
57 FacesContext ctx = _firstInstance.get();
58
59 if (ctx == null)
60 {
61 throw new UnsupportedOperationException();
62 }
63
64 return ctx.getAttributes();
65 }
In other words, the _firstInstance.get() is in your specific case incorrectly returning the current instance. This suggests that at some point in the code elsewhere the following action has taken place in JSF internal code:
FacesContext.setCurrentInstance(FacesContext.getCurrentInstance());
This is not right. The FacesContext's current instance should not be referring to itself. It would only result in an infinite loop of accessing itself everytime, as evident by the stack trace.
Also, the fact that you apparently got your web application to successfully deploy with a Mojarra-specific listener in your web.xml
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
suggests that you've MyFaces' competitor Mojarra in webapp's runtime classpath. In other words, you're mixing two completely distinct JSF implementations! This is definitely not right. It's like mixing gasoline and diesel in one car engine. IBM WebSphere ships with MyFaces bundled. You should remove any Mojarra-related JAR files (jsf-api.jar, jsf-impl.jar and/or javax.faces.jar), configuration entries (com.sun.faces.*) and other artifacts from your webapp. They're conflicting with MyFaces.
See also:
JSF Deploy Error "at javax.faces.context.FacesContext.isProcessingEvents(FacesContext.java:300)"
JSF implementations and component libraries
Difference between Mojarra and MyFaces
This error could be due to class loading issue. Most Likely you are deploying your app in WAS 7.0 or later version.
To fix this,
go to WAS console and open
Applications ==> Enterprise Applications==> Manager Modules==>your war module
select "Classes loaded with local class loader first (parent last)." for Class loader order
Click "Apply" and "Save"

Can't get CXF JAX-RS and JSF to work together

I'm trying to setup a small example application FooTest that uses CXF JAX-RS and JSF. I started with the CXF part, implemented a simple service (works) and a small html page called home.html (I can access it in my browser). The relevant code is as follows:
web.xml
<servlet>
<servlet-name>RestServlet</servlet-name>
<servlet-class>org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet</servlet-class>
<init-param>
<param-name>jaxrs.serviceClasses</param-name>
<param-value>com.test.FooService</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>RestServlet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
FooService.java
#Path("/rest")
public class FooService {
#Path("/foo")
#GET
#Produces("application/json; charset=UTF-8")
public String getFoo() {
// returns json
}
}
Now I can call http://localhost:8080/FooTest/rest/foo and http://localhost:8080/FooTest/home.html. However when I start defining and mapping the FacesServlet to *.html and try to access home.html I get a NullPointerException.
New web.xml
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
... CXF stuff ...
Leads to
Apr 25, 2013 6:08:17 AM org.apache.catalina.core.ApplicationDispatcher invoke
SEVERE: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at org.apache.myfaces.shared.context.flash.FlashImpl.isKeepMessages(FlashImpl.java:388)
at org.apache.myfaces.shared.context.flash.FlashImpl._saveMessages(FlashImpl.java:665)
at org.apache.myfaces.shared.context.flash.FlashImpl.doPostPhaseActions(FlashImpl.java:269)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:254)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:369)
at org.apache.myfaces.view.jsp.JspViewDeclarationLanguage.buildView(JspViewDeclarationLanguage.java:99)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:78)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
... infinite loop from FacesServlet:199 on ...
How can I fix this?
Update - More config info
The application runs on the JAX-RS version of TomEE 1.5.2.
src/main/webapp/WEB-INF/faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<faces-config 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-facesconfig_2_1.xsd"
version="2.1">
</faces-config>
Update - Solution
(Thanks to David Blevins for clarification and pointing me to a useful example)
Remove the CXF configuration part, it is not required. Rename home.html to home.xhtml, since .xhtml is the javax.faces.DEFAULT_SUFFIX for JSF pages. Keep the FacesServlet mapping if you want to access your JSF pages using the .html extension. This is sufficient:
<?xml version="1.0" encoding="UTF-8"?>
<web-app ... >
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
</web-app>
Not sure whether this should be a comment or an answer, but you shouldn't setup CXFNonSpringJaxrsServlet and FacesServlet in your web.xml, all that stuff is there and ready to go. The goal with TomEE is you can skip the server-building and proceed directly to app-building.
CXF is fully integrated into Tomcat in TomEE to the point where even WS-Security works on Tomcat Realms. You just start using it by adding #ApplicationPath annotated components or EJBs annotated with #Path and they will be picked up and deployed automatically.
MyFaces is good to go and fully integrated with CDI so even things like #ConversationScoped work out of the box. You just need your faces-config.xml or some #ManagedBean classes.

Resources