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.
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 built the WAR file of my application https://github.com/JonkiPro/REST-Web-Services. I put it on the Tomcat server and clicked START. Then he threw the error https://zapodaj.net/44f410f8abc74.png.html
FAIL - Application at context path [/WebApplication] could not be started
FAIL - Encountered exception [org.apache.catalina.LifecycleException: start: ]
java.lang.RuntimeException: Failed to get driver instance for jdbcUrl=jdbc:h2:mem:database
and wrote in the logs https://pastebin.com/7rWhPFLt.
I will mention that the application after compilation in IntelliJ works without a problem.
My application works on port 8443. I do not know if it matters. It seems to me that Tomcat has a database problem?
I tried to install confluence on my own ubuntu server, but always failed. The error is:
com.atlassian.util.concurrent.LazyReference$InitializationException: java.lang.IllegalStateException: Spring Application context has not been set
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:149)
caused by: java.lang.IllegalStateException: Spring Application context has not been set
at com.atlassian.spring.container.SpringContainerContext.getComponent(SpringContainerContext.java:48)
I saw some solutions in the jira confluence forum saying try to fix the permission of installed directory and home directory. I tried but failed again. How can I fix the problem.
In my case the issue was corrupted confluence.cfg.xml file (contains DB connection stings and other settings). The file size was 0 bytes.
I would suggest to use a VM to create a new installation and borrow confluence.cfg.xml from that installation.
It's embarrassing that this behavior has been allowed to exist for nearly 7 years in a commercial product. This is a basic stuff...
I wish that was on instructions somewhere:
Make single backup copy of confluence.cfg.xml immediately before any writes to it by the application. Application should be able to restore from backed up copy if it gets corrupted.
Atlassian documentation lists the following causes of this problem:
The user running Confluence does not have write permissions to the home folder defined in <install>/confluence/WEB-INF/classes/confluence-init.properties or the install directory.
You are running Confluence as the root user or if you have an application firewall enabled (SeLinux or AppArmor).
The database driver is not located in the <install>/confluence/WEB-INF/lib folder or you are using a database version that is incompatible with the bundled driver.
The hostname of the server can not be resolved.
In my case I was running it as root user inside docker container.
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.
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.