Resteasy deploy fails randomly on glassfish 4.1 - java

I have a problem with my REST-Application using Resteasy.
When I deploy the application with this dependencies
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>3.0.11.Final</version>
</dependency>
as described here in Chapter 3.5 sometimes the server deploys the application correctly and everything works fine.
But sometimes I get
Error invoking ServletContainerInitializer
org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer
java.lang.NullPointerException
at org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer.register(ResteasyServletInitializer.java:109)
at org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer.onStartup(ResteasyServletInitializer.java:80)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6031)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5929)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:243)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:329)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:377)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
]]
In the sources of ResteasyServletInitializer line 109 is this (with context)
ServletRegistration.Dynamic reg = servletContext.addServlet(applicationClass.getName(), HttpServlet30Dispatcher.class);
reg.setLoadOnStartup(1); //Line 109
reg.setAsyncSupported(true);
reg.setInitParameter("javax.ws.rs.Application", applicationClass.getName());
So I assume this is a Glassfish bug and Glassfish fails to properly return the correct object.
I have not found that this happens with redeployments, after clearing osgi-cache, etc. It seems to be pretty random.
This seems to be related and I tried adding
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
But it still fails sometimes although I would say it fails a little bit less often.
The accepted answer from the post is deprecated as by the resteasy reference 3.9. RESTEasy as a ServletContextListener so I do not want to try this.
This seems like avoiding the problem, not solving it.
My Glassfish version is GlassFish Server Open Source Edition 4.1 (build 13).
Please help me with this one.
Cheers

I ended up avoiding this issue by ensuring the application WAR did not include RESTEasy.
So I build two wars now: one with RESTEasy (as required for deploying on Tomcat and Wildfly), another without (for deploying on Glassfish). That seems better than requiring changing the Glassfish install, but accomplishes the same: avoids having two JAX-RS implementations installed.

Related

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.

Jboss 6.4 Infinispan 8.2 and JGroups - ClassNotFoundException

I need some features from Infinispan 8+. Therefore I have updated my company app pom.xml with the newest Infinispan pom.
It was quite straightforward, but the app uses jgroups (or its default config in default-configs/default-jgroups-udp.xml - this location is different from previous versions of infinispan). The default versions have some parameters (and the XSD from Jgroups version 3.6) - so I also bumped jgroups to 3.6.8.Final as it looks like it is the intended version (and the version that does not complain about unknown parameters in default config in infinispan 8.2)
so the pom is the following:
<dependency>
<groupId>org.jgroups</groupId>
<artifactId>jgroups</artifactId>
<version>3.6.8.Final</version>
</dependency>
<dependency>
<groupId>org.infinispan</groupId>
<artifactId>infinispan-core</artifactId>
<version>8.2.0.Final</version>
</dependency>
Anyway - this application starts with no problems using spring-boot with Jetty. I am pretty sure it would start on any application server.
But then I have no choice but to run it on JBoss 6.4.
There I got an exception involving some jboss.as classes (this is kind of unexpected) during the deployment:
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:859)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:628)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:617)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:234)
... 141 more
Caused by: java.lang.ExceptionInInitializerError
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:35)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:62)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:419)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:320)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:366)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
... 146 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:31)
... 158 more
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.jgroups.LogFactory from [Module "deployment.mymodule-5.0.0.0-SNAPSHOT.ear.appName.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jgroups.logging.LogFactory.<clinit>(LogFactory.java:28)
... 158 more
My guess is that org.jgroups.logging.LogFactory somehow discovers that is is running on a Jboss and tries to use org.jboss.as.clustering.jgroups.LogFactory but this version of Jboss does not have one. (the server directory EAP-6.4.0\modules\system\layers\base\org\jgroups\main contains jgroups version 3.2.X).
Is there any walkaround to use this jgroups version (and so Infinispan 8.2) in Jboss 6.4?
This is (the application) an ear file so I can manipulate jboss-deployment-structure.xml file, but so far I only came with excluding Jboss original jgroups, and this did not help.
<exclusions>
<module name="org.jgroups"/>
</exclusions>
This is currently bug with Infinispan 8 + EAP 6.4 combination. The reason is exactly as #Flavius says in comments. Currently there is discussion where to fix it, but it'll mostly likely be fixed in EAP 6.4. I'm sure it will be done soon.
I can only offer you a working workarounds.
Use WildFly - the issue is not present there anymore
Little nasty workaround, but it works:
Call System.clearProperty("jgroups.logging.log_factory_class"); in the deployment
Include JBoss Logging of version specified in infinispan-bom in your deployment (e.g. add jboss-logging Maven dependency in your pom.xml)
Provide jboss-deployment-structure.xml to your deployment, which excludes the server's JBoss logging, see below:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.logging" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Another possibility if none of the above workarounds work (for instance the app uses other log mechanisms) is to implement an own
http://www.jgroups.org/javadoc/org/jgroups/logging/CustomLogFactory.html
The log factory must return a log instance, implementing it for any other logger is straightforward with methods trace/error/debug etc.
Then this logger class can be set with System.setProperty("jgroups.logging.log_factory_class","my.company.logging.MyJgroupsLog");

Maven compilation and run time error java.lang.AbstractMethodError: oracle.jdbc.driver.T4CConnection.isValid(I)Z on Tomcat 8 Server

I've been converting a large Java Web App to a maven project, but I've run into an error in a handful of classes originating from the tomcat-dbcp jar. I get the following error messages from any class that needs to use BasicDataSource objects:
javax.servlet.ServletException: java.lang.AbstractMethodError: oracle.jdbc.driver.T4CConnection.isValid(I)Z
java.lang.AbstractMethodError: oracle.jdbc.driver.T4CConnection.isValid(I)Z
Now I know this jar is present on the server (as it is default in our Tomcat8 installation). So in maven I declared this dependency as such:
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-dbcp</artifactId>
<version>8.0.26</version>
<scope>provided</scope>
</dependency>
But I'm still seeing this error. What can I do to eliminate this error?
This error did go away, though I have no idea why. The pom entry is still the same and still running on Tomcat 8. We did find a hacky temporary fix:
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc7</artifactId>
<version>12.1.0.1</version>
<scope>system</scope>
<systemPath>${basedir}/lib/ojdbc7-12.1.0.1.jar</systemPath>
</dependency>
But we reverted back at some point and it is working fine.

NoSuchMethodError on startup in Java Jersey app

I've been getting a very strange error when trying to start a Jersey app on Tomcat. The same code works on other computers. I tried reinstalling tomcat, all my maven dependencies, even Eclipse and Java itself, no luck. It seems like a bad Jersey version is being loaded, I think?
Any pointers in the right direction will be appreciated.
Here's the effective pom: http://pastebin.com/NacsWTjz
And the actual pom: http://pastebin.com/H6sHe4ce
2015-02-13 13:43:40,870 [localhost-startStop-1] ERROR org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/middleware-server] - StandardWrapper.Throwable
java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties()Ljava/util/Map;
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:304)
at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:285)
at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:311)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:170)
at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:358)
at javax.servlet.GenericServlet.init(GenericServlet.java:158)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1231)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1031)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4901)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5188)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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)
Note: Please see above comments for further discussion and tips.
This error usual means that you have a both a JAX-RS 1 and JAX-RS 2 jar on the classpath. Jersey 2 uses JAX-RS 2 (javax.ws.rs-api-2.0.1.jar), but if you have the jsr311-api.jar also, which is JAX-RS 1, there is a javax.ws.rs.core.Application in each jar. But the jsr311-api Application doesn't have the method getProperties() (hence NoSuchMethodError).
I've come to the conclusion that all you need to do is add the above exclusion to the swagger dependency. The Jackson 2.0 provider (which depends on JAX-RS 1) seems to be overridden by a 2.4.1 provider (which uses the new version). So we don't need to add it ourselves. When it's overridden, it seems to leave behind the jsr311-api.jar. So if we exclude it, no one can attempt to use it, which looks to be the current problem
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-core_2.10</artifactId>
<version>1.3.11</version>
<exclusions>
<exclusion>
<groupId>javax.ws.rs</groupId>
<artifactId>jsr311-api</artifactId>
</exclusion>
</exclusions>
</dependency>
We are using jersey-json 1.9 which has a dependency on jersey-core which also happen to have a javax.ws.rs.core.Application class.
So our fix is to exclude the jersey-core from jersey-json:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.9</version>
<exclusions>
<exclusion>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
</exclusion>
</exclusions>
</dependency>
the problem is related about "com.sun.jersey:jersey-core:jar:1.18.3" (or any 1.* version) because old versions of Jersey didn't have that "public Map getProperties()" method.
And one of your dependencies use Jersey version 1 (you can check that in running mvn dependency:tree and search all jersey-core version used)
Me I have resolved the problem deleting all com.sun.jersey dependancies (old api) and using the new one org.glassfish.jersey API
https://mvnrepository.com/artifact/org.glassfish.jersey.core

AbstractCreatorProcessor class not found error

While setting up adopt openjdk 8 with Tomcat 9 with my existing application, I am getting the following error
Caused by: java.lang.NoClassDefFoundError: com/sun/xml/stream/buffer/AbstractCreatorProcessor
at com.sun.xml.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:363)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:321)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:230)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:211)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:207)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:114)
at javax.xml.ws.Service.<init>(Service.java:77)
at javax.xml.ws.Service.create(Service.java:707)
at org.springframework.remoting.jaxws.LocalJaxWsServiceFactory.createJaxWsService(LocalJaxWsServiceFactory.java:162)
at org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.prepare(JaxWsPortClientInterceptor.java:357)
at org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.afterPropertiesSet(JaxWsPortClientInterceptor.java:339)
It was working fine with Oracle JDK, is there anything I am missing for openjdk?
For openjdk you need the JAX-WS dependency library streambuffer.jar.
You can download it from here or, if you use Maven:
<!-- https://mvnrepository.com/artifact/com.sun.xml.stream.buffer/streambuffer -->
<dependency>
<groupId>com.sun.xml.stream.buffer</groupId>
<artifactId>streambuffer</artifactId>
<version>1.5.6</version>
</dependency>

Categories

Resources