Develop Reference

I'm using JakartaEE and making a "hello world" kind of restfulAPI, can't get a return string by visiting URL

Providing every step I took with this short video:
https://youtu.be/hbSr8sRYuOk
Project code here: https://github.com/LJonn/restapiHelloWorld
Running everything on a local server on tomcat.
I'm having this issue for quite some time and ran out of ideas where the problem might be...
I tried URL's such as these: "http://localhost:8080/api/hello" and "http://localhost:8080/helloworld/api/hello" and expected one of these to work.
Running http://localhost:8080/manager/text/list shows that helloworld.war is deployed fine and working:
OK - Listed applications for virtual host [localhost]
/:running:0:ROOT
/helloworld:running:0:helloworld
/examples:running:0:examples
/host-manager:running:0:host-manager
/manager:running:0:manager
/docs:running:0:docs
So why I still get a HTTP Status 404 page? What could I try to do to find the issue?
These are my project's Maven dependencies:
<dependencies>
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-web-api</artifactId>
<version>9.1.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
Thanks to Nikos Paraskevopoulos comment it looks like changing from Tomcat to TomEE might fix the issue, but now I'm running into a problem where the .war file can't be deployed/started, probably some sort of versions compatibility issue, tomcat manager GUI gives this error when trying to start the .war file:
FAIL - Application at context path [/helloworld] could not be started
FAIL - Encountered exception [org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/helloworld]]]
Looking to manager logs It looks like it has something to do with annotations and Java 16 maybe?:
...
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 60
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:195)
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:176)
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:162)
at org.apache.xbean.asm7.ClassReader.<init>(ClassReader.java:283)
at org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1176)
... 52 more
01-Sep-2021 15:25:02.185 INFO [http-nio-8080-exec-3] org.apache.catalina.core.ApplicationContext.log HTMLManager: list: Listing contexts for virtual host 'localhost'
I've tried to check JRE version on Eclipse and it's 16.0.2 and it looks to me that the same version is running on tomcat.

Tomcat 10.0 and 10.1 are not full Jakarta EE 9.1 application servers: you shouldn't use the jakarta.jakartaee-web-api artifact, which would imply that the runtime supports all Jakarta EE 9.1 Web Profile technologies.
Tomcat does not implement all the specs required in Web Profile. At least four other products do. See this list for Jakarta Web Profile 9.1:
Apache TomEE
Eclipse Glassfish
IBM Open Liberty
Red Hat WildFly
You can find the list of supported technologies on Tomcat's web site and for Tomcat 10 they translate to this list shown as a Maven POM snippet.
<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
<version>5.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.servlet.jsp</groupId>
<artifactId>jakarta.servlet.jsp-api</artifactId>
<version>3.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.el</groupId>
<artifactId>jakarta.el-api</artifactId>
<version>4.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.websocket</groupId>
<artifactId>jakarta.websocket-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jakarta.security.auth.message</groupId>
<artifactId>jakarta.security.auth.message-api</artifactId>
<version>2.0.0-RC1</version>
<scope>provided</scope>
</dependency>
Since Servlet 3.0, additional Jakarta EE specifications can be added using the servlet pluggability mechanism. To use JAX-RS you need to add:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>3.0.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<version>3.0.2</version>
</dependency>
or an equivalent configuration using other JAX-RS implementations.

Connect SMB endpoint with Camel v3 and the camel-jcifs from camel-extra

I have the following maven versions in my pom.xml (among others):
<dependency>
<groupId>org.apache.camel.springboot</groupId>
<artifactId>camel-spring-boot-starter</artifactId>
<version>3.7.0</version>
</dependency>
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
<version>3.7.0</version>
</dependency>
<dependency>
<groupId>org.apache-extras.camel-extra</groupId>
<artifactId>camel-jcifs</artifactId>
<version>2.25.2</version>
<exclusions>
<exclusion>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
</exclusion>
</exclusions>
</dependency>
Camel spring-boot version = 3.7.0 and I want to connect to a SMB endpoint like this:
smb://sharedriveuser#server-instance.sub.domain.net/folder?initialDelay=0&delay=9000&autoCreate=false&noop=true&idempotent=true&password=ThePassWorD&filter=#csvFileFilter
I read the Camel 3 Migration Guide and found nothing regarding this camel-extras.
When trying to connect, I get an error like the password option is not supported anymore:
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: smb://sharedriveuser#server-instance.sub.domain.net/folder?initialDelay=0&delay=9000&autoCreate=false&noop=true&idempotent=true&password=xxxxxx&filter=#csvFileFilter due to: There are 1 parameters that couldn't be set on the endpoint. Check the uri if the parameters are spelt correctly and that they are properties of the endpoint. Unknown parameters=[{password=ThePassWorD}]
The actual documentation link google found many times, seems dead.
From Maven central, there is no version 3.x of the lib camel-jcifs and I am wondering if the lib is still compatible with Camel 3.x.x, otherwise is there another alternative with Camel 3?
I also tried to downgrade the camel-jcifs to 2.24.3 with the same error.

Camel-extras is a separated project from the Apache Camel. There is some work in place in the camel-extra repository to support camel 3[1], but it is still to be completed and there is no release in sight.
[1] https://github.com/camel-extra/camel-extra/commit/f028dfdfaa467958c58abea0d604f8fe2f17be04

There is now a pull request to add camel-jcifs to the 3.x version:
https://github.com/camel-extra/camel-extra/pull/39
You might also get my fork and build it yourself:
https://github.com/bebbo/camel-extra *
It got merged and is in the official repository:
https://github.com/camel-extra/camel-extra
To use it with quarkus, you have to convert some List types to arrays.

SOAP over Websocket with Appache CXF and Embedded Jetty

I have been trying to set a a SOAP endpoint with Websocket as transport protocol via CXF and implement invoke it via CXF. With Embeded jetty. I have tried a couple of approaches non of the aproaches worked unfortunatly. Here is what I did:
Aproach 1. According to CXF documentation websocket is supported as transport protocol and its support is given via
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-websocket</artifactId>
<version>3.3.2</version>
</dependency>
I have setup the following dependencies:
<dependency>
<groupId>org.asynchttpclient</groupId>
<artifactId>async-http-client</artifactId>
<version>2.0.39</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>3.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>3.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-jetty</artifactId>
<version>3.3.2</version>
</dependency>
The code I executo is the following:
Endpoint endpoint = Endpoint.create(new MyHelloWorldServicePortType() {
#Override
public String sayHello(HelloMessage message) throws FaultMessage {
return message.sayHello();
}
};
((org.apache.cxf.jaxws.EndpointImpl)endpoint).getFeatures().add(new
WSAddressingFeature());
endpoint.publish("ws://localhost:8088/MyHelloWorldService" );
URL wsdlDocumentLocation = new URL("file:/path to wsdl file");
String servicePart = "MyHelloWorldService";
String namespaceURI = "mynamespaceuri";
QName serviceQN = new QName(namespaceURI, servicePart);
Service service = Service.create(wsdlDocumentLocation, serviceQN);
MyHelloWorldServicePortType port = service.getPort( MyHelloWorldServicePortType.class);
portType.sayHello(new HelloMessage("Say Hello"));
The result of this code is:
SEVERE: [ws] onError java.util.concurrent.TimeoutException: Request
timeout to not-connected after 60000 ms at
org.asynchttpclient.netty.timeout.TimeoutTimerTask.expire(TimeoutTimerTask.java:43)
at
org.asynchttpclient.netty.timeout.RequestTimeoutTimerTask.run(RequestTimeoutTimerTask.java:48)
at
io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:682)
at
io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:757)
at
io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:485)
at java.base/java.lang.Thread.run(Thread.java:834)
jun. 12, 2019 1:13:33 P.M.
org.apache.cxf.transport.websocket.ahc.AhcWebSocketConduit$AhcWebSocketWrappedOutputStream
connect SEVERE: unable to connect
java.util.concurrent.ExecutionException:
java.util.concurrent.TimeoutException: Request timeout to
not-connected after 60000 ms at
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at
org.asynchttpclient.netty.NettyResponseFuture.get(NettyResponseFuture.java:172)
at
org.apache.cxf.transport.websocket.ahc.AhcWebSocketConduit$AhcWebSocketWrappedOutputStream.connect(AhcWebSocketConduit.java:309)
at
org.apache.cxf.transport.websocket.ahc.AhcWebSocketConduit$AhcWebSocketWrappedOutputStream.setupWrappedStream(AhcWebSocketConduit.java:167)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1343)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1304)
at
org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
at
org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
at
org.apache.cxf.transport.websocket.ahc.AhcWebSocketConduit$AhcWebSocketWrappedOutputStream.close(AhcWebSocketConduit.java:139)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
I have absolutly no idea why. When I try to connect via websocket chrome client on the URL. It says success. At the same time when connecting via the client it says Timeout.
Aproach 2.
I decided to cheat CXF and provide a handmade Websocket endpoint that will be used as a front to the CXF webservice. The idea is that the Client will send a message via websocket the message will be unwrapped and then sent over CXF. This aproach is very similar to the aproach here but here it uses JMS as transport
https://github.com/pbielicki/soap-websocket-cxf
In oprder to do this I created the following Websocket enpoint:
#ServerEndpoint("/jaxWSFront")
public class JaxWSFrontEnd {
#OnOpen
public void onOpen(final Session session) {
System.out.println("Hellooo");
}
#OnMessage
public void onMessage(String mySoapMessage,final Session session) throws Exception{
// The goal here is to get the soap message and redirect it via SOAP web //service. The JaxWSFacade acts as a point that understands websocket and then //gets the soap content and sends it to enpoint that understands SOAP.
session.getBasicRemote().sendText("Helllo . Now you see me.");
System.out.println("Hellooo again");
}
#OnClose
public void onClose(Session session, CloseReason closeReason) {
System.out.println("Hellooo");
}
#OnError
public void onError(Throwable t, Session session) {
System.out.println("Hellooo");
}
}
Now I pointed my Client proxy to the jaxWsFrontEnd instead of the webservice endpoint. My expectation is that I will recieve the SOAP message in the onMessage method and then I will be able to forwards to SOAP to the CXF web service.
Now my code looks like this:
server = new Server(8088);
ServletContextHandler context = new ServletContextHandler();
context.setContextPath( "/" );
server.setHandler(context);
ServerContainer container = WebSocketServerContainerInitializer.configureContext(context);
container.addEndpoint(JaxWSFrontEnd.class);
server.setHandler( context );
server.start();
Endpoint endpoint = Endpoint.create(new MyHelloWorldServicePortType() {
#Override
public String sayHello(HelloMessage message) throws FaultMessage {
return message.sayHello();
}
};
((org.apache.cxf.jaxws.EndpointImpl)endpoint).getFeatures().add(new
WSAddressingFeature());
URL wsdlDocumentLocation = new URL("file:/path to wsdl file");
String servicePart = "MyHelloWorldService";
String namespaceURI = "mynamespaceuri";
QName serviceQN = new QName(namespaceURI, servicePart);
Service service = Service.create(wsdlDocumentLocation, serviceQN);
MyHelloWorldServicePortType port = service.getPort( MyHelloWorldServicePortType.class);
portType.sayHello(new HelloMessage("Say Hello"));
For the second aproach I had in addition to the aproach 1 the following dependencies:
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>websocket-common</artifactId>
</dependency>
<dependency>
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>javax-websocket-server-impl</artifactId>
</dependency>
Result from aproach 2 is absolutly the same as Aproach 1 the exceptions I recieve are the same, with one minor difference. When I use the the Chrome websocket client and point it directly the the jaxWsFrontend I am able to successfuly send a message. Why I am not able to connect to websocket wia the CXF websocket transport mechanisms ???? What am I doing wrong ?
UPDATE: enabling the loging from NETTY. It apears that netty has thrown java.lang.NoSuchMethodError: io.netty.channel.DefaultChannelId.newInstance()Lio/netty/channel/DefaultChannelId;
Maybe I have a version compatability issue with netty. The version I can see is imported in the project is 4.1.33. It is a transitive dependency I don|t have it declared.

Ok I actualy managed to crack it alone. I will post the answer for completion. Apparantly CXF guys should update their documentation IMO. On their website it is stated that in order to enable Websocket as transport protocol we need
cxf-rt-transports-websocket dependency.
What they do not say is that you in addition need async-http-client not any version but 2.0.39 a prettey old one. The problem is that it automaticaly includes transitive dependencies to netty 4.1 and the error specified above begins to manifest. What you actualy need is nett 4.0.56
Here is the fragment that made the things work for me:
<dependency>
<groupId>org.asynchttpclient</groupId>
<artifactId>async-http-client</artifactId>
<version>2.0.39</version>
<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-buffer</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-handler</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-epoll</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-transport</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-common</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-codec</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.0.56.Final</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-websocket</artifactId>
<version>3.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>3.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>3.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http-jetty</artifactId>
<version>3.3.2</version>
</dependency>
Aproach 1 is working
Aproach 2 I managed to trigger the onConnect event, the onMessage timedout, but in my opinion it should work I am missing something small. Anyway I don|t have more time to spent and I am happy with Aproach 1.

Keycloak admin client - javax.ws.rs.ProcessingException: RESTEASY003215

Im using the Keycloak admin client (version 4.5.0.Final) and am trying to do some simple queries such as looking up a user. The client code is running in a plugin module in another java server, not standalone. The code looks like this:
...
try {
Keycloak kc = Keycloak.getInstance(URL, REALM, USER, PWD, CLIENT_ID);
UserRepresentation kcuser = kc.realm(REALM).users().get(USER).toRepresentation();
trace(String.format("Got user: %s", kcuser.toString()));
} catch (Exception e) {
trace("Error authenticating: " + e);
}
...
It creates the kc instance successfully, but barfs when trying to look up the user.
This is the error:
javax.ws.rs.ProcessingException: RESTEASY003215: could not find writer for content-type application/x-www-form-urlencoded type: javax.ws.rs.core.Form$1
at org.jboss.resteasy.core.interception.ClientWriterInterceptorContext.throwWriterNotFoundException(ClientWriterInterceptorContext.java:40)
at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.getWriter(AbstractWriterInterceptorContext.java:146)
at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:121)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.writeRequestBody(ClientInvocation.java:394)
at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.writeRequestBodyToOutputStream(ApacheHttpClient4Engine.java:666)
at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.buildEntity(ApacheHttpClient4Engine.java:631)
at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.loadHttpMethod(ApacheHttpClient4Engine.java:509)
at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:310)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:439)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invokeSync(ClientInvoker.java:148)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:112)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
at com.sun.proxy.$Proxy362.grantToken(Unknown Source)
at org.keycloak.admin.client.token.TokenManager.grantToken(TokenManager.java:89)
at org.keycloak.admin.client.token.TokenManager.getAccessToken(TokenManager.java:69)
at org.keycloak.admin.client.token.TokenManager.getAccessTokenString(TokenManager.java:64)
at org.keycloak.admin.client.resource.BearerAuthFilter.filter(BearerAuthFilter.java:52)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:587)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:436)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invokeSync(ClientInvoker.java:148)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:112)
at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
at com.sun.proxy.$Proxy372.toRepresentation(Unknown Source)
...
My pom has the latest dependencies and classpath seems ok, any ideas why this is not working?
<properties>
<keycloak.version>4.5.0.Final</keycloak.version>
<resteasy.version>3.6.1.Final</resteasy.version>
</properties>
<dependencies>
<dependency>
<groupId>org.keycloak</groupId>
<artifactId>keycloak-admin-client</artifactId>
<version>${keycloak.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-multipart-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson2-provider</artifactId>
<version>${resteasy.version}</version>
</dependency>
</dependencies>

I noticed that during the instantiation of a new Keycloak instance, resteasy is checking here for the available providers with the help of the current thread. In version 3.9.1.Final which is currently used by the last keycloak-admin-client so far (version 11.0.0).
In my specific case we are using keycloak-admin-client in combination with graphql-java and CompletableFuture.supplyAsync for our data loaders. Which implies that in some cases, without further configuration, the current thread is not an instance of Thread but actually ForkJoinWorkerThread. Which apparently breaks the retrieval of the providers.
I am still a beginner to java so I would be glad if someone could explain why the registerProviders method does not work with a ForkJoinWorkerThread.
I learned on DZone is that JVM sizes the commonPool to two threads when you have more than 2 CPUs available. So I tried and noticed that my app works with 2 CPUs, but I have the same error (RESTEASY003215) with 3 CPUs.
My current "workaround" is to to use CompletableFuture.completedStage when loading data using the keycloak-admin-client.

"Unknow type constant pool at position X" in tomcat logs since java 8

I have a Java JSF2 web based application deployed on a Tomcat server, and since we moved to Java 8 / Tomcat 8 this error appears a lot in the tomcat output:
déc. 05, 2016 10:51:07 AM com.sun.faces.config.JavaClassScanningAnnotationScanner$ConstantPoolInfo containsAnnotation
GRAVE: Unknow type constant pool 0 at position 178
I tried different stuff to fix this warning but it always comes back.
Is this log a symptom of any issue ? Is it just a normal output? Is there a way to fix this?

I was presenting the same problem
Today I updated my pom.xml file to jsf version: 2.2.15 and that ERROR log was gone.
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>${jsf.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>${jsf.version}</version>
<scope>provided</scope>
</dependency>

From my research it appears that this was a bug in JSF implementation and was fixed in JSF version 2.3.0-m02
Reported Bugs:
http://github.com/javaserverfaces/mojarra/issues/3736
https://github.com/javaserverfaces/mojarra/issues/3780
Where to obtain fixed versions of the JSF implementation
http://repo1.maven.org/maven2/javax/faces/javax.faces-api/2.2/
http://repo1.maven.org/maven2/org/glassfish/javax.faces/2.3.0-m02/
Or update maven POM dependency with (2.3.0-m02 or higher):
<groupId>org.glassfish</groupId>
<artifactId>javax.faces</artifactId>
<version>2.3.0-m02</version>

I had the same same problem. I solved after updating my pom.xml file to 2.2.11.
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.2.11</version>
<artifactId>jsf-impl</artifactId>
<version>2.2.11</version>
The postConstruct wasn't been execute in some ManagedBean, without any error.