I tried to deploy a Vaadin hello world application in JBOSS. The application is as simple as it can be.
My development environment is eclipse for java EE + tomcat
java.lang.RuntimeException: Error configuring property: includeWebInfInClasspath for WarClassLoaderDeployer
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112)
at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85)
(...)
Caused by: java.lang.IllegalArgumentException: No such property includeWebInfInClasspath for bean org.jboss.web.tomcat.service.deployers.WarClassLoaderDeployer available [java2ClassLoadingCompliance, parentFirst, requiredInputs, filteredPackages, allInputs, deploymentRegistry, class, stage, wantComponents, componentsOnly, input, inputs, relativeOrder, output, useUnitName, outputs, topLevelOnly]
I have tried to google this error with no success.
Does anyone have any clues?
Is it a web server configuration or my *.war is missing something?
EDIT:
This error occur when I start the server after placing my *.war in the folder.
My JBOSS version is 5
I guess, you're using an old JBoss 5.
The WarClassLoaderDeployer is configured in the file server/default/deployers/jbossweb.deployer/META-INF/war-deployers-jboss-beans.xml. (The 'default' directory should be changed to whatever you passed as -c parameter) Open the file, find the WarClassLoaderDeployer bean and drop the line defining the property with name includeWebInfInClasspath.
Related
I finally reached the point where my Elastic Beanstalk Instance / Environment got launched. (Java Corretto 11 Platform) Now it fails starting up the provided .jar file.
In the eb-engine.log file, I am not able to find any more error than this:
2021/05/27 11:36:25.889735 [INFO] Executing instruction: StageJavaApplication
2021/05/27 11:36:25.889871 [ERROR] An error occurred during execution of command [app-deploy] - [StageJavaApplication]. Stop running the command. Error: staging java app failed due to invalid zip file
The jar file is a Spring Boot application built with mvn -B package.
Locally the whole thing starts, but crashes afterwards because of not given environment variables (Expected behaviour).
But it seems AWS is not even starting the application..
Any suggestions on this?
Spring Boot apps run nicely on Elastic Beanstalk. However, you do need to set some variables. For example, have you set server-port variable to 5000?
And as you stated, to successfully use a Service Client, you can set environment variables for your creds. Here is an end to end walkthrough that shows how to successfully put a Spring BOOT app that invokes several AWS Services on Elastic Beanstalk.
Creating your first AWS Java web application
PS - your log file mentions a ZIP file. Be sure to create the JAR properly as discussed in the above example.
Just in case someone arrive here looking for an answer about this guy:
Error: staging java app failed due to invalid zip file
I was renaming my service jar in Gradle, using:
tasks.withType<org.springframework.boot.gradle.tasks.bundling.BootJar> {
archiveFileName.set("service.jar")
launchScript()
}
And ElasticBeanstalk was not happy about the renaming.
When I let it have the default name, then no zip issues and all worked like a charm.
I'm currently wasting my time trying to figure out why WAS won't load my EAR and why said EAR have problem.
Context:
One of my colleague updated a version of a jar and then my m2e seem to have not picked up and was giving thousand of error (was working fine before)
I tried to check if it was Nexus (work fine). My encrypted password in the setting.xml (work fine).
I decided to try maven from the command line, everything worked fine there to.
When I tried again in RAD (IBM eclipse) everything was now ok, no more error.
I then proceeded to put the generated EAR in my websphere server via add and remove project and I get multiple error when I try to start the server with that ear. (see below)
I though that because it was compiled via maven cmd prompt, I might have compiled with the wrong jvm or something so I deleted my maven repo (.m2 in the user) and try to get the jar via m2e in RAD only.
It's worked until I started the server with the new EAR and got the same set of error.
Any idea on what to do to get rid of these error and have a healthy server.
Here some of the error:
[11/10/17 12:08:51:994 EST] 00000075 annotation W
com.ibm.ws.webcontainer.annotation.WASAnnotationHelper collectClasses
SRVE8000W: Skipped class that failed to initialize for annotation
scanning.
java.lang.ClassNotFoundException: org.springframework.web.servlet.tags.form.SelectTag at
java.lang.Class.forNameImpl(Native Method) at
java.lang.Class.forName(Class.java:219) ...
[11/10/17 12:09:00:282 EST] 00000075 wtp W
org.eclipse.jst.j2ee.commonarchivecore.internal.strategy.TempZipFile
clearTempFile Failed to delete temporary file [
C:\IBM\WebSphere\AppServer-x86\profiles\chris_pro\wstemp\appdepl15fa68a2a21\AuthRenfClientWeb-2.0.26.war2406380505527260260.tmp
] [11/10/17 12:09:00:433 EST] 00000075 SinglePathCla E WSVR0120E: An
error occurred processing com.mycom.bla.testalive.TestAliveServlet
java.io.FileNotFoundException:
C:\IBM\WebSphere\AppServer-x86\profiles\chris_pro\wstemp\appdepl15fa68a2a21\Client-1.61.5-SNAPSHOT.jar6655053587500024283.tmp
(The system cannot find the file specified.) ...
SRVE0266E: Error occured while initializing servlets: {0}
javax.servlet.UnavailableException: SRVE0203E: Servlet [SecurityManager]:
com.mycom.bla.pres.request.http.HttpSecurityManagerServlet was found,
but is missing another required class. SRVE0206E: This error typically
implies that the servlet was originally compiled with classes which
cannot be located by the server. SRVE0187E: Check your class path to
ensure that all classes required by the servlet are present.SRVE0210I:
This problem can be debugged by recompiling the servlet using only the
classes in the application's runtime class path SRVE0234I: Application
class
We have a Java application that we deploy using .war files on tomcat server. The war is copied on the webapp directory (tomcat stopped) and then we start the server. We have several scripts that automate the process and we have deploying on development-backup and production servers without problems until two days ago... Then we were able to deploy on development machines, but in backup and production (ovh machines) we received an exception starting tomcat:
### Error building SqlSession.
### Cause: org.apache.ibatis.builder.BuilderException: Error creating document instance. Cause: java.io.IOException: Stream closed
org.apache.ibatis.exceptions.PersistenceException:
### Error building SqlSession.
### Cause: org.apache.ibatis.builder.BuilderException: Error creating document instance. Cause: java.io.IOException: Stream closed
at org.apache.ibatis.exceptions.ExceptionFactory.wrapException(ExceptionFactory.java:23)
at org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:51)
at org.apache.ibatis.session.SqlSessionFactoryBuilder.build(SqlSessionFactoryBuilder.java:39)
Redeploying old .war works fine, but new .war produces all the time this exception. We have spend lot of hours trying to figure out what is wrong, but the same .war that does not work on production work on a development machine and (this is incredible) if we deploy using another name for the war (just renaming the .war file) the application works.. But we need the application to work using this specific context name.
Please... help!
Finaly solved...
The main reason was the checking url from haproxy that in this version uses database, so, while the context are deploying haproxy try to load this url and causes several initializations on mybatis...
Changing the url haproxy query solves the problem, but I'm not sure the good way to avoid the initialization problem under load.
Attempting to set up jenkins and its container deploy plugin.
However, I am receiving the following stacktrace :
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException: Failed to deploy [/myHome/jenkins/jobs/myAPP/workspace/target/ROOT.war]
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:111)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:187)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:60)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:86)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:73)
at hudson.FilePath.act(FilePath.java:784)
at hudson.FilePath.act(FilePath.java:766)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:73)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:45)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675)
at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:998)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622)
at hudson.model.Run.run(Run.java:1429)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: org.codehaus.cargo.container.tomcat.internal.TomcatManagerException: FAIL - Failed to deploy application at context path /ROOT
Which isn't really that helpful, I can deploy manually using tomcat manager, and also copying the war file across using command line options works. But i can not get the automated deploy to work.
I am using a tomcat url of http://localhost:8080/ and the deploy fails when their is no app currently deployed.
Any help gratefully received, thanks.
Just a wild guess but the ROOT context is not: /ROOT but rather / maybe there is something wrong in your config
Its a ContainerExc not fileNotFound; therefore the war file has been located.
URL should be http://localhost:8080
Is userName and Password provided?
Is this userName assigned a role of manager-script?
is the tomcat webapp cleared down once for work and temp folder?
If YES to above all, now run the tomcat without any war fiel present in the webapps folder and open a web broswer to see http://localhost:8080 is accessible.
Now whilst this tomcat running, build the jenkins job and deployment should be fine.
I'm trying to deploy a WAR in GF V3 that has CXF as a dependency and I get the following exception:
[#|2011-02-08T07:34:15.736-0800|WARNING|oracle-glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=32;_ThreadName=http-thread-pool-8080-(2);|StandardWrapperValve[MyServlet]: PWC1406: Servlet.service() for servlet MyServlet threw exception
com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TransportPipeFactory: Provider com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory is specified in bundle://254.0:0/META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory but not found
at com.sun.xml.ws.util.ServiceFinder.fail(ServiceFinder.java:241)
at com.sun.xml.ws.util.ServiceFinder.access$100(ServiceFinder.java:141)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:376)
at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:129)
at com.sun.xml.ws.transport.DeferredTransportPipe.<init>(DeferredTransportPipe.java:82)
at com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.createTransportTube(ClientTubeAssemblerContext.java:311)
at com.sun.xml.ws.assembler.jaxws.TransportTubeFactory.createTube(TransportTubeFactory.java:62)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:77)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:121)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:224)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:201)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:174)
at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:81)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:602)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:344)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:326)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:308)
at javax.xml.ws.Service.getPort(Service.java:99)
at com.mycompany.myapp.webserviceclient.SomeWebserviceService.getSomeWebservicePort(SomeWebserviceService.java:58)
This sorta indicates to me that there is a bundle in my WAR\lib directory that is causing problems, but when I expand the WAR and do a search on META-INF\services I do not find anything that is close what is outlined in the exception.
I originally had CXF and it's transitive dependencies in the war\lib dir, but I've since removed that and still encounter the same error.
Nothing useful comes up when searching google and I'm at a loss here.
Does anyone know what might be going on here?
EDIT #1
Another symptom of this is that the tester pages for deployed web services will not work properly.
I had a similar problem with my glassfish3.1. Below is a stack trace
Caused by: com.sun.xml.ws.util.ServiceConfigurationError: com.sun.xml.ws.api.pipe.TransportPipeFactory: Provider com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory is specified in bundle://96.0:0/META-INF/services/com.sun.xml.ws.api.pipe.TransportPipeFactory but not found
at com.sun.xml.ws.util.ServiceFinder.fail(ServiceFinder.java:245)
at com.sun.xml.ws.util.ServiceFinder.access$100(ServiceFinder.java:145)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.next(ServiceFinder.java:380)
at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:133)
at com.sun.xml.ws.transport.DeferredTransportPipe.<init>(DeferredTransportPipe.java:86)
at com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.createTransportTube(ClientTubeAssemblerContext.java:315)
at com.sun.xml.ws.assembler.jaxws.TransportTubeFactory.createTube(TransportTubeFactory.java:67)
at com.sun.xml.ws.assembler.TubeCreator.createTube(TubeCreator.java:84)
at com.sun.xml.ws.assembler.TubelineAssemblerFactoryImpl$MetroTubelineAssembler.createClient(TubelineAssemblerFactoryImpl.java:130)
at com.sun.xml.ws.client.Stub.createPipeline(Stub.java:228)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:205)
at com.sun.xml.ws.client.Stub.<init>(Stub.java:178)
at com.sun.xml.ws.client.sei.SEIStub.<init>(SEIStub.java:85)
at com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:608)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:348)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:330)
at com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:312)
at javax.xml.ws.Service.getPort(Service.java:134)
at org.glassfish.webservices.monitoring.WebServiceTesterServlet.initializePort(WebServiceTesterServlet.java:563)
at org.glassfish.webservices.monitoring.WebServiceTesterServlet.doGet(WebServiceTesterServlet.java:169)
at org.glassfish.webservices.monitoring.WebServiceTesterServlet.invoke(WebServiceTesterServlet.java:104)
at org.glassfish.webservices.EjbWebServiceServlet.service(EjbWebServiceServlet.java:114)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at com.sun.grizzly.http.servlet.ServletAdapter$FilterChainImpl.doFilter(ServletAdapter.java:1002)
... 20 more
The problem was traced to the conflicting mappings for "com.sun.xml.ws.api.pipe.TransportPipeFactory" inside two different modules.
prompt> grep -rl com.sun.xml.ws.api.pipe.TransportPipeFactory /usr/local/glassfish-3.1/glassfish/domains/modules*
modules/webservices-osgi.jar
modules/sun-javaee-engine.jar
prompt> grep -rl com.sun.enterprise.jbi.serviceengine.bridge.transport.JBITransportPipeFactory /usr/local/glassfish-3.1/glassfish/domains/modules/*
modules/sun-javaee-engine.jar
Clearly, the required file was sitting in the wrong jar "sun-javaee-engine.jar".
Above, "sun-javaee-engine.jar" is loaded by the "Java EE Service Engine Module". Once I removed the module (using glassfish update tool) everything started working fine.
EDIT #1:
Here is how to remove the module using the update tool on the Unix command line:
sudo ./pkg uninstall sun-javaee-engine