i'm using Netbeans 8.0, Windows 8, Java EE 7, Maven web application project and glassfish 4.
When I try to run unit tests with embeddable EJB Container the creation of the container fails with following exception:
SEVERE: Error while expanding archive file
java.io.FileNotFoundException: C:\Users\...\AppData\Local\Temp\gfembed1338945565251414358tmp\applications\classes\license\LICENSE (The system cannot find the file specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
at com.sun.enterprise.deploy.shared.FileArchive.putNextEntry(FileArchive.java:716)
at org.glassfish.internal.deployment.GenericHandler.expand(GenericHandler.java:99)
at com.sun.enterprise.v3.server.ApplicationLifecycle.getContext(ApplicationLifecycle.java:1807)
at com.sun.enterprise.v3.server.ApplicationLifecycle.access$200(ApplicationLifecycle.java:115)
at com.sun.enterprise.v3.server.ApplicationLifecycle$DeploymentContextBuidlerImpl.build(ApplicationLifecycle.java:1670)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:424) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:138)
at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:134)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
When I try to run simple unit test with a netbeans web app project (no maven project), everything works fine (same temp folder is used). Both unit tests do no more than creating the embedded EJB container.
Related
I upgraded a JSP application to Spring Boot 3 and now it won't start when running as a standalone application.
If I start the application using gradle bootRun it runs fine.
When runing it using java -jar oldnewjspapp.war I get the following stacktrace:
ERROR 7082 --- [ main] o.s.boot.SpringApplication : Application run failed
org.springframework.context.ApplicationContextException: Unable to start web server
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.onRefresh(ServletWebServerApplicationContext.java:164) ~[spring-boot-3.0.1.jar!/:3.0.1]
...
Caused by: org.springframework.boot.web.server.WebServerException: Unable to start embedded Tomcat
at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:142) ~[spring-boot-3.0.1.jar!/:3.0.1]
...
Caused by: java.lang.IllegalStateException: zip file closed
at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:831) ~[na:na]
at java.base/java.util.zip.ZipFile.getManifestName(ZipFile.java:1057) ~[na:na]
at java.base/java.util.zip.ZipFile$1.getManifestName(ZipFile.java:1100) ~[na:na]
at java.base/java.util.jar.JarFile.getManEntry(JarFile.java:937) ~[na:na]
at java.base/java.util.jar.JarFile.checkForSpecialAttributes(JarFile.java:1000) ~[na:na]
at java.base/java.util.jar.JarFile.isMultiRelease(JarFile.java:389) ~[na:na]
at org.apache.tomcat.util.scan.JarFileUrlJar.<init>(JarFileUrlJar.java:68) ~[tomcat-embed-core-10.1.4.jar!/:na]
Does anyone have a solution?
Spring Boot 3 JSP support is broken:
Spring boot app's .jar not working (issue with tomcat-embed-jasper)
https://github.com/spring-projects/spring-boot/issues/33633
https://github.com/spring-projects/spring-boot/issues/32106
The alternatives are:
downgrade your Spring Boot version
extract the war contents and run it that way
generate a regular war (gradle war) and publish it in your favourite web server
turn off the support for Multi-Release JAR Files (this feature is present in Java since release 9): java -Djdk.util.jar.enableMultiRelease=false -jar oldnewjspapp.war
I am using maven Maven Tomcat 8 plugin to start up my tomcat server locally and deploy a war file with the intellij IDE.
For some reason when I try to start it with maven tomcat 8 plugin, it shows following stack trace and not getting up.
n.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.xml.ws.api.server.AbstractInstanceResolver$1.run(AbstractInstanceResolver.java:84)
at com.sun.xml.ws.api.server.AbstractInstanceResolver$1.run(AbstractInstanceResolver.java:78)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.ws.api.server.AbstractInstanceResolver.invokeMethod(AbstractInstanceResolver.java:78)
at com.sun.xml.ws.server.SingletonResolver.start(SingletonResolver.java:72)
at com.sun.xml.ws.api.server.InstanceResolver$1.start(InstanceResolver.java:238)
at com.sun.xml.ws.server.InvokerTube.setEndpoint(InvokerTube.java:83)
at com.sun.xml.ws.server.WSEndpointImpl.<init>(WSEndpointImpl.java:205)
at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:320)
at com.sun.xml.ws.server.EndpointFactory.create(EndpointFactory.java:315)
at com.sun.xml.ws.server.EndpointFactory.createEndpoint(EndpointFactory.java:158)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:577)
at com.sun.xml.ws.api.server.WSEndpoint.create(WSEndpoint.java:560)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parseAdapters(DeploymentDescriptorParser.java:303)
at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:179)
at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.parseAdaptersAndCreateDelegate(WSServletContextListener.java:131)
at com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer.onStartup(WSServletContainerInitializer.java:65)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5210)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:724)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:919)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1703)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
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)
But when I try to do it with a separate tomcat container (without using maven tomcat 8 plugin or support of IDE), it starts all ok.
I investigated that this happens because of a library (spring-jersey3.jar) that bundles inside my war file. When I remove that from war and try with maven tomcat plugin, it is all ok too. As I found this error happens because it tries to init a spring application context at the start up. But it only happens when I try to do with maven tomcat plugin.
Anyhow I need that lib for my work. I can't exclude it from war.
Does any one know any work around to get rid of this? It may be
configure disabling init the spring application context at start up.
configure maven tomcat 8 plugin to ignore that lib or init process.
Or any other way to do without excluding the lib.
I am trying to set up drools on zos environment. I created my run time environment by adding the following jars (droolsjbpm-integration-distribution-6.5.0.Final) in OSGi framework bundles. I placed my drl files in unix directory outside the OSGi Application jar, when I run the OSGi app, I get the following error.
java.lang.RuntimeException: Cannot find KieModule:
org.default:artifact:1.0.0-SNAPSHOT at
org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:186)
at
org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:180)
at com.cft.hogan.fwk.adapter.pem.DroolsTest.test4(DroolsTest.java:95)
at com.cft.hogan.fwk.adapter.pem.DroolsTest.main(DroolsTest.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620) at
com.ibm.cics.server.Wrapper.call_main(Wrapper.java:810) at
com.ibm.cics.server.Wrapper.callOSGiClass(Wrapper.java:2580) at
com.ibm.cics.server.Wrapper.invokeJvmServerOSGiClass(Wrapper.java:2455)
at com.ibm.cics.server.Wrapper.jvmServerOSGiEntry(Wrapper.java:2413)
at com.ibm.cics.osgi.impl.Controller.runService(Controller.java:935)
at
com.ibm.cics.osgi.impl.Controller.acceptRequest(Controller.java:230)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
While I am deploying and runing my web application on Apache Tomcat in Eclipse IDE
I've included the JSTL1.2.jar, jstl-impl.jar.
I'm really wondering how to get this fixed. The same deployment works perfectly fine on Weblogic server(on PROD environment)
Exception stack trace:
INFO: Starting Servlet Engine: Apache Tomcat/7.0.12
Feb 10, 2014 6:40:29 PM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/ConditionalTagSupport
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2818)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1148)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1643)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
at org.apache.jasper.compiler.Parser.parseCustomTag(Parser.java:1223)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1450)
at org.apache.jasper.compiler.Parser.parse(Parser.java:138)
I would check a number of things:
1) That the jar files are sitting in the lib folder under WEB-INF and not just referenced in the build path.
2) That the tomcat 7 runtime library is included in your build path
3) I'd check the web.xml file and ensure that I'm complying to a spec higher than or equal to 2.5.
If you provide more details with your project setup it might be easier to answer.
I have a Jetty 6.1.9 environment which I am trying to bootstrap an 'exploded' WAR style context, however, I am getting NoClassDefFoundError errors.
The Jetty env is bootstrapped like so:
public class MyServer {
public static void main(String[] argv) {
jetty_default = jetty_default + "/web-content/jetty-6.1.9";
String jetty_home = System.getProperty("jetty.home", jetty_default);
Server server = new Server();
Connector connector = new SelectChannelConnector();
connector.setPort(7895);
server.setConnectors(new Connector[]{connector});
WebAppContext myAppCxt= new WebAppContext();
myAppCxt.setContextPath("/foo");
myAppCxt.setWar(jetty_home + "/wardirs/myApp");
myAppCxt.setDefaultsDescriptor(jetty_home + "/etc/webdefault.xml");
myAppCxt.setInitParams(initParamsMaps);
myAppCxt.setTempDirectory(aTmpDir);
server.setHandler(processingNodeAppCxt);
server.start();
}
The layout of wardirs/myApp looks like so
wardirs
myApp
WEB-INF
lib\
jdom.jar
web.xml
The class I am getting the error for is in foo.jar.
It also feels like Jetty is finding the JAR in the WEB-INF/lib dir because after starting the server foo.jar becomes locked (I tried deleting it) and when I kill the server it becomes unlocked.
If I manually put the JARs on the classpath of the java cmd line which runs MyServer's main method then all works fine, however, I want these JARs to live in the WEB-INF\lib dir and be automatically picked up as they should be.
The actual exception is:
Mar 06, 2013 9:07:25 PM sun.reflect.NativeMethodAccessorImpl invoke0
SEVERE: /foo/api/process
java.lang.NoClassDefFoundError: org/jdom/Content
at com.foo.MyManager$Status.createICProcessor(MyManager.java:231)
at com.foo.myApp.Api.process(API.java:xxx)
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:601)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:149)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:67)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:259)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:83)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
Caused by: java.lang.ClassNotFoundException: org.jdom.Content
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 35 more
The only other thing I can think to mention since this feels like a classloader context issue is that the MyManager referenced in the top line of the stack trace is running in its own thread which was started by the webapp's ServletContextListener like so:
myMgrThread = new Thread(myManager);
long myMgrThreadId = myMgrThread.getId();
myMgrThread .setName("MyApp_MyMgr-" + myMgrThreadId);
myMgrThread .setPriority(Thread.NORM_PRIORITY);
myMgrThread .setDaemon(true);
myMgrThread .start();
According to your project layout, and that stacktrace, it found com.foo.myApp.Api and com.foo.MyManager in your WEB-INF/lib/foo.jar just fine, but it failed to find org.jdom.Content
Is org.jdom.Content present in your wEB-INF/lib/foo.jar? or in a similar file you haven't mentioned like WEB-INF/lib/jdom.jar? Or are you expecting to find org.jdom.Content from the parent classloader (in other words, whatever classloader the MyServer class was started from)?
I think I answered my own question. The IDE project this is running in does not move the 'webapp' .class files into "$jetty_home/wardirs/myApp/WEB-INF/classes" as one would expect per the servlet spec. Instead it includes them in the class path which invokes MyServer.main.
When I copied the application classes into "$jetty_home/wardirs/myApp/WEB-INF/classes" the NOCLASSDEFERRORs went away. So now the classes are WEB-INF/classes and on the classpath calling main.
As you might be able to tell here this project has no separation of concerns between the webapp and the container. All the classes and JARS for the application and jetty have been dumped together and it 'works'. I've been trying to teases things apart so that the webapp classes and dependent JARs are clearly separated, eg. introducing a ServletContextListener to move webapp code into which was previously being bootstrapped from 'main', moving JARs into WEB-INF/lib and the like. It's like trying to get chewing gum out of your hair.