Whenever I deploy jetty application I hit this issue. Looks like some jar or class is broken.
Colleagues compiling exactly same code, doesn't hit the issue. Even if the deploy to the same computer. (we use git and maven)
Deleting local maven repository ~/.m2 and rebuilding doesn't help.
Can run same jetty app locally without any issues.
My initial suspect was that some jar is broken. Tried jar tvf $every_jar and haven't found anything.
Any ideas how can I debug this? Looks really mysterious and I suspect is that some file get corrupted.
Stack trace:
2014-10-21 13:29:25.123:WARN:oejw.WebAppContext:Failed startup of context o.e.j.w.WebAppContext{/,file:/XYZ/},/XYZ/webapps/root
javax.servlet.ServletException: jersey-serlvet
at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:553)
at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:344)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:791)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:615)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1274)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jetty.start.Main.invokeMain(Main.java:473)
at org.eclipse.jetty.start.Main.start(Main.java:615)
at org.eclipse.jetty.start.Main.main(Main.java:96)
followed by
Caused by:
java.lang.ArrayIndexOutOfBoundsException: 6241
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:133)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner$1.f(FileSchemeScanner.java:86)
at com.sun.jersey.core.util.Closing.f(Closing.java:71)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:83)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:80)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:80)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scan(FileSchemeScanner.java:71)
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:223)
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:139)
at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
at com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:104)
at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:78)
at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:89)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:700)
For your 2 errors ..
javax.servlet.ServletException: jersey-serlvet
This means you have a typo in your WEB-INF/web.xml
As for this one ..
java.lang.ArrayIndexOutOfBoundsException: 6241
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
I've seen similar ones when using an old version of asm.jar with newer compiled Java bytecode.
For Java 15 bytecode, use asm 7.3.1+
For Java 14 bytecode, use asm 7.2+
For Java 13 bytecode, use asm 7.1+
For Java 12 bytecode, use asm 7.1+
For Java 11 bytecode, use asm 7.0+
For Java 10 bytecode, use asm 6.1+
For Java 9 bytecode, use asm 6.0+
For Java 8 bytecode, use asm 5.0.1+
For Java 6 or Java 7 bytecode, (Use asm 3.1 if you must, but know that asm 5.x is also going to work here too)
Ensure that your asm.jar (or org.objectweb.asm.jar) is current.
There is a slightly less common issue where the class itself is bad. Sometimes seen with classes that are compiled in one JDK (such as IBM) and then run on another Java (like Sun/Oracle).
A real world example of this would be the icu4j-2.6.1.jar and its com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class jar entry.
Use newer version of jetty-maven-plugin.
More information --> Bug 419801 - Upgrade to asm5 for jdk8
So, edit your pom.xml like this：
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>9.3.0.M2</version>
</plugin>
Note the groupId is "org.eclipse.jetty".
In my case, I am using ASM library version and that not support java 8 lambda expression, so either you change ASM library to support java 8 or change your code.
In my case I am using java 8 lambda expression for iterating and I replaced it with for loop
I came across similar issue when maintaining legacy code.
Servlet.init() for servlet JerseyServlet threw exception
type Exception report
message Servlet.init() for servlet JerseyServlet threw exception
description The server encountered an internal error that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: Servlet.init() for servlet JerseyServlet threw exception
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:956)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423)
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:745)
root cause
java.lang.ArrayIndexOutOfBoundsException
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.65 logs.
I fixed it with reducing the package scanning scope in web.xml. E.g., removing the package_with_too_many_classes below in param-value tag fixed the issue.
<servlet>
<servlet-name>JerseyServlet</servlet-name>
<servlet-class>com.sun.jersey.spi.spring.container.servlet.SpringServlet</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>package_with_too_many_classes;package_with_approciate_number_of_classes;org.codehaus.jackson.jaxrs</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
Related
I have 2 versions of a project (GIT), the oldest (work perfectly) and the new one commited (don't work - issue below).
Here the error I have in Eclipse :
août 18, 2020 4:22:24 PM org.apache.catalina.core.StandardContext filterStart
GRAVE: Exception au démarrage du filtre struts2
java.lang.NoClassDefFoundError: HttpServletRequest
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.privateGetPublicMethods(Unknown Source)
at java.lang.Class.getMethods(Unknown Source)
at org.apache.struts2.convention.PackageBasedActionConfigBuilder.getActionAnnotations(PackageBasedActionConfigBuilder.java:877)
at org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildConfiguration(PackageBasedActionConfigBuilder.java:689)
at org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:355)
at org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:274)
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at org.apache.struts2.dispatcher.Dispatcher.getContainer(Dispatcher.java:967)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:435)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:479)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:57)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:105)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4583)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5207)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1408)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1398)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: HttpServletRequest
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1333)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167)
... 27 more
The GRAVE: Exception au démarrage du filtre struts2 can be translated in SEVERE: Exception in start of struts2 filter
I saw this answer java.lang.ClassNotFoundException: HttpServletRequest but I have already not servlet-api in the WEB-INF/lib folder but in the Tomcat/lib. And I have exactly the same .jar between the current modified project and the old one.
What can I do about this ?
The error comes from the convention plugin. This plugin is used to create additional configuration objects by convention. If you havily use annotations to define Java based configuration for struts actions then it invokes a reflection mechanism to process creating runtime configuration elements.
The NoClassDefFoundError says that you missing some classes on the classpath of the current classloader. Usually it fixed by adding missing jar to the classpath.
It could be ignored if your application used different classloader than a servlet container is used. Tomcat is a servlet container which is using multiple classloaders in the multithreaded pool. It could also have bugs the one had discovered in the 8.x version.
In many ways missing classes in the broken servlet environment leads to change/update the servlet container itself and download correct dependencies from the Maven central repository.
I finally found a solution but I hesitated to post because I don't know how I did that.
I was trying this :
Duplicate the existing Eclipse server into another folder.
Create a new server in the Servers view in Eclipse with the new folder.
Click-right on the new server -> Clean and Clean Tomcat Work Directory...
Go to Run -> Run configurations
Totally random action :
Double click on one of the server
The server instance start. Stop it. Restart your project. The problem has disappeared.
I think a clean publish is what I needed but we will never know..
Packaging a hello world application generated by the wildfly swarm generator and built with Java9 crashes when deploying the application.
It seems that the reason is the swarm/undertow dependency to the org.ow2.asm:asm-all:5.0.4 which is not Java9 ready.
Is there a known workaround, or a known date when swarm will be ready for Java9?
The stacktrace is:
Caused by: java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.wildfly.swarm.jaxrs.internal.JAXRSArchiveImpl.isJAXRS(JAXRSArchiveImpl.java:117)
at org.wildfly.swarm.jaxrs.internal.JAXRSArchiveImpl.isJAXRS(JAXRSArchiveImpl.java:96)
at org.wildfly.swarm.jaxrs.JAXRSArchive.isJAXRS(JAXRSArchive.java:55)
at org.wildfly.swarm.jaxrs.internal.DefaultJAXRSWarDeploymentFactory.create(DefaultJAXRSWarDeploymentFactory.java:46)
at org.wildfly.swarm.jaxrs.internal.DefaultJAXRSWarDeploymentFactory$Proxy$_$$_WeldClientProxy.create(Unknown Source)
org.wildfly.swarm.container.runtime.deployments.DefaultDeploymentCreator.createDefaultDeployment(DefaultDeploymentCreator.java:69)
The class files in JDK 9 are v53.0 so you need ASM 6. ASM has always thrown IAE when encountering class files that are newer that it supports.
The IllegalArgumentException can be possibly caused by different class version when scanning the bytecode which in your case which is done by org.ow2.asm:asm-all:5.0.4.
We faced similar issue faced in jetty.project#1758 which I'd to try and solve by building the jetty.project by myself but to eventually realize that org.ow2.asm would chain me back still.
The latest available version of asm on maven is :
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-all</artifactId>
<version>6.0_BETA</version>
</dependency>
In case of jetty (and probably swarm as well) they were not able to integrate this as 6.0_BETA is not a valid OSGI version number:
Caused by: java.lang.IllegalArgumentException: invalid range
"[6.0_BETA,6.0_BETA]": invalid version "6.0_BETA": non-numeric
"0_BETA"
Related to the above a read to how jetty tried solving it.
There is already a tracker to the ow2.asm invalid version bug which you can follow.
Currently my application is running on grails 1.1.1 with java 1.6 on web sphere server. My application is working in old server with java 1.6.Recently server team upgrade the websphere server 8.5.5 and they asked us to deploy an ear with java 1.7. I have deployed the ear with java 1.7. now I am getting below error:
Error Page Exception
SRVE0260E: The server cannot use the error page specified for your application to handle the Original Exception printed below.
Original Exception:
Error Message: javax.servlet.ServletException: Filter [charEncodingFilter]: could not be initialized
Error Code: 500
Target Servlet: com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor
Error Stack:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'pluginManager' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.RuntimeException: Unable to locate constructor with Class parameter for class org.codehaus.groovy.grails.commons.DefaultGrailsControllerClass
at java.security.AccessController.doPrivileged(AccessController.java:426)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1704)
at com.ibm.ws.webcontainer.webapp.WebAppImpl.initialize(WebAppImpl.java:411)
at com.ibm.ws.webcontainer.webapp.WebGroupImpl.addWebApplication(WebGroupImpl.java:88)
at com.ibm.ws.webcontainer.VirtualHostImpl.addWebApplication(VirtualHostImpl.java:169)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApp(WSWebContainer.java:749)
at com.ibm.ws.webcontainer.WSWebContainer.addWebApplication(WSWebContainer.java:634)
at com.ibm.ws.webcontainer.component.WebContainerImpl.install(WebContainerImpl.java:426)
at com.ibm.ws.webcontainer.component.WebContainerImpl.start(WebContainerImpl.java:718)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:1177)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectStart(DeployedApplicationImpl.java:1370)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:639)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:968)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:776)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplicationDynamically(ApplicationMgrImpl.java:1379)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2189)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:435)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:378)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$500(CompositionUnitMgrImpl.java:126)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$1.run(CompositionUnitMgrImpl.java:653)
at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5477)
at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5603)
at com.ibm.ws.security.core.SecurityContext.runAsSystem(SecurityContext.java:255)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:667)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.startCompositionUnit(CompositionUnitMgrImpl.java:611)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:1269)
at javax.management.modelmbean.RequiredModelMBean$4.run(RequiredModelMBean.java:1261)
at java.security.AccessController.doPrivileged(AccessController.java:426)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:92)
at javax.management.modelmbean.RequiredModelMBean.invokeMethod(RequiredModelMBean.java:1255)
at javax.management.modelmbean.RequiredModelMBean.invoke(RequiredModelMBean.java:1093)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:832)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:814)
at com.ibm.ws.management.AdminServiceImpl$1.run(AdminServiceImpl.java:1335)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:118)
at com.ibm.ws.management.AdminServiceImpl.invoke(AdminServiceImpl.java:1228)
at com.ibm.ws.management.connector.AdminServiceDelegator.invoke(AdminServiceDelegator.java:181)
at com.ibm.ws.management.connector.ipc.CallRouter.route(CallRouter.java:247)
at com.ibm.ws.management.connector.ipc.IPCConnectorInboundLink.doWork(IPCConnectorInboundLink.java:360)
at com.ibm.ws.management.connector.ipc.IPCConnectorInboundLink$IPCConnectorReadCallback.complete(IPCConnectorInboundLink.java:602)
at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$QueuedWork.run(SSLReadServiceContext.java:1981)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
Caused by: java.lang.RuntimeException: Unable to locate constructor with Class parameter for class org.codehaus.groovy.grails.commons.DefaultGrailsControllerClass
... 43 more
Caused by: java.lang.reflect.InvocationTargetException
... 43 more
Caused by: org.codehaus.groovy.grails.exceptions.NewInstanceCreationException: Could not create a new instance of class [customer.CustomerController]!
... 43 more
Caused by: java.lang.TypeNotPresentException: Type CustomerSegment not present
at java.beans.FeatureDescriptor.getParameterTypes(FeatureDescriptor.java:399)
at java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:126)
at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:84)
at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:68)
at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1164)
at java.beans.Introspector.getBeanInfo(Introspector.java:428)
at java.beans.Introspector.getBeanInfo(Introspector.java:175)
at java.security.AccessController.doPrivileged(AccessController.java:456)
at customer.CustomerController.$getStaticMetaClass(CustomerController.groovy)
at base.BdwBaseController.<init>(BdwBaseController.groovy)
at customer.CustomerController.<init>(CustomerController.groovy)
... 43 more
Caused by: java.lang.ClassNotFoundException: CustomerSegment
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:302)
... 54 more
I have a few questions:
Grails 1.1.1 will support java 1.7?
if not do I need to upgrade grails?
What are all the steps to upgrade grails?
web sphere 8.5.5 will not support java 1.6?
to resolve this error what I need to check?
Do I need to update jars?
please find below jars which I am using in my application:
jar files
Going to try to answer as much as I can, but it's a best-effort since you're asking way too many questions in one post!
1 - Probably not. Grails 1.1.1 came out in 2009, and Java 1.7 came out in 2011, and was a major change over 1.6. You might be able to force them to work together, but you're going to struggle to find good information six (plus) years later.
2 - Yes.
3 - You can start here: http://docs.grails.org/1.2.0/ and go from there.
4 - See comment below. (Originally I said, but was wrong: IBM recommends Java 8 with WebSphere 8.)
5 - Probably not important, if you're upgrading everything anyway.
6 - Yes.
I'm getting this exception on my JSP application after adding some Java packages which does not give to me compilation errors. Those packages are not being used, but they are added.
This exception does not have any portion of my code, is just jersey or Java libraries code, not mine, so I don't know how to solve it.
In Google or SO there is nothing about this rare error not related with my code in the exception log:
org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter jersey
java.lang.ArrayIndexOutOfBoundsException: 26415
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:136)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner$1.f(FileSchemeScanner.java:86)
at com.sun.jersey.core.util.Closing.f(Closing.java:71)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:83)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:80)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scanDirectory(FileSchemeScanner.java:80)
at com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner.scan(FileSchemeScanner.java:71)
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:225)
at com.sun.jersey.core.spi.scanning.PackageNamesScanner.scan(PackageNamesScanner.java:141)
at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
at com.sun.jersey.api.core.PackagesResourceConfig.init(PackagesResourceConfig.java:104)
at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:78)
at com.sun.jersey.api.core.PackagesResourceConfig.<init>(PackagesResourceConfig.java:89)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:696)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:674)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:203)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:374)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:727)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:279)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:260)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:105)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4958)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5652)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1571)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1561)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
If you are using Jersey 1.x, try upgrading to the latest version (1.19).
I was seeing the same stack trace with a web application that was working fine with Java 7, but got that error when I moved to Java 8. This application was using Jersey 1.15.
See more about this change in the release notes of Jersey 1.18. In this post there is a link to the pull request with some comments.
This post has a few months, but I answer in case someone else runs into this issue. It took me a couple of hours to figure out what was going wrong.
I just had the same problem. My IDE silently switched to using a JDK 11. To anybody having the same problem: make sure to use JDK 8.
hey, I am having somewhat related issue only. Recently the external SOAP interface which were generating client for changed to https one. and I had an old code base at hand which was generating the java files through cxf and unsecured, http:// based wsdl. I chnaged the uri and on maven side everything works fine even the test pass. but when i use this jar in the main project of mine I get this:
Caused by: java.lang.NoSuchMethodError: javax.net.ssl.HttpsURLConnection.getSSLSocketFactory()Ljavax/net/ssl/SSLSocketFactory;
at sun.net.www.protocol.https.DelegateHttpsURLConnection.getSSLSocketFactory(DelegateHttpsURLConnection.java:50)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:801)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1049)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
at java.net.URL.openStream(URL.java:1010)
at org.apache.cxf.resource.URIResolver.tryFileSystem(URIResolver.java:169)
at org.apache.cxf.resource.URIResolver.resolve(URIResolver.java:119)
at org.apache.cxf.resource.ExtendedURIResolver.resolve(ExtendedURIResolver.java:41)
at org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:134)
at org.apache.cxf.catalog.CatalogWSDLLocator.getBaseInputSource(CatalogWSDLLocator.java:72)
at org.apache.cxf.wsdl11.AbstractWrapperWSDLLocator.getBaseInputSource(AbstractWrapperWSDLLocator.java:57)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:214)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:179)
at org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:91)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:207)
at org.apache.cxf.jaxws.ServiceImpl.(ServiceImpl.java:150)
at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
at javax.xml.ws.Service.(Service.java:56)
at generated.webservices.com.gbm.sso.ssoclient.AuthenticationServiceInternal.(AuthenticationServiceInternal.java:49)
at com.gbm.caprice.sso.client.CachingSSOClient.init(CachingSSOClient.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1536)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1477)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1409)
... 45 more
Can you please help?
Since you're getting a NoSuchMethodError (which is caught/thrown by the compiler), My suggestion is that you are using a version of Java class (in this case, javax.net.ssl.HttpsURLConnection) which doesn't have the following method signature:
javax.net.ssl.HttpsURLConnection.getSSLSocketFactory()
This class can be found in the JRE/lib jsse.jar (as from time of writing, JDK 1.6.0_21). Make sure that your java libraries and your Apache CXF libaries are declared in the java CLASSPATH.
That's what I can help you based on your caused exception.