Using Tomcat 7, Jeresy 1.12.
Time for launch Tomcat without Jersey is 4 seconds.
When I add the jars of Jersey to tomcat/lib directory, the time for launch goes for 50 seconds. It doesn't matter which servlets I use - even if web.xml is empty (no servlets) it takes that time.
The jar that cause the problem is jersey-servlet-1.12. When I remove it from lib directory, launch time goes normal again. I suspect that the services defined in that jar (\META-INF\services\*) cause the trouble but couldn't find the exact cause...
BTW: metadata-complete="true" didn't solve the problem.
Edit: Problem was confirmed by Jersey team (issue JERSEY-1317). A workaround to this problem is to remove META-INF/services/javax.servlet.ServletContainerInitializer file from jersey-servlet.jar. This will disable some of Servlet3 functionality.
You can also add the jar to tomcat.util.scan.DefaultJarScanner.jarsToSkip list at catalina.properties
This way you can take a newer version of the jar and you don't need to keep in mind that you should edit it.
See http://tomcat.10.x6.nabble.com/tomcat-7-0-29-startup-time-td4984446.html
Related
In our Linux environment applications are restarted periodically (the reasons aren't important here). It would be convenient for us to deploy new versions of an application by copying the application Spring Boot jar on top of the existing (old) jar thereby overwriting it and then simply wait for the application to restart (that is, the JVM running the application to restart).
However, this seems to not work. We get different kinds of errors - sometimes the app just hangs, sometimes we get a ClassNotFoundException. It's as if Spring Boot (or something inside Spring Boot) reopens the jar and expects it to be the same one it was when the application was originally started.
We had a look through Spring's common application properties, but didn't see anything appropriate. Is there a way to make this work? When we were using WAR files we configured the servlet container to unpack the WAR file and run from the unpacked version. Can we do something similar with Spring Boot?
First of all the errors you are experiencing can come from multiple sources. Usually replacing the file from a process is not a big problem as the whole file is loaded into memory before execution. Java is a little bit different, because the actual process that is running is the JVM and it only loads the jar file from disk. The JVM loads classes only on demand, this means if there was any class that was not loaded before it will try to load it and most likely fail, if the jar file is different. In the case of spring boot there are also other resources (such as HTML files) inside the jar file that are dynamically loaded.
You mentioned you are using a linux environment. If you can just replace your startup with a script you can just copy the jar and start it from the copied location:
#!/bin/bash
JAR_NAME="spring-boot.jar"
NEW_JAR_NAME=".$JAR_NAME" # Use an appropriate name here
cp $JAR_NAME $NEW_JAR_NAME
java -jar $NEW_JAR_NAME
rm $NEW_JAR_NAME
Now every time you start the application a copy is being made and started from there. You can replace the original jar and on the next restart the new application will load.
You coud also use rsync instead of cp to avoid copying the same jar twice, if the application is restarted multiple times without changing the jar.
It would be convenient for us to deploy new versions of an application
by copying the Spring Boot jar on top of the existing (old) jar and
then simply wait for the application to restart
Why would you do such a thing to yourself? You are trying solve a usecase that's against best practices, sound like asking for trouble just to avoid an app restart. When you are doing a deployment, you need to make sure the deployment went through, otherwise how will you troubleshoot if something goes wrong in your application, you will have one more variable in hand when you troubleshoot, i,e the uncertainty of current version of the code.
If you are having downtime while deploying (I am assuming thats why you want to limit the restarts), why don't you bring up another instance with the newer version of code and once its healthy shutdown the old one
I have a basic question about deployment but I can't seem to find an answer on google...
I am working on a jakarta project and it's the first time I do the deployment.
Since I am using Spring-boot maven, I know there is an embedded tomcat that will launch with the jar.
My issue is, I don't know what url to use to check my project is working...
Before, I used the address http://localhost:9091/contextPath/endpoint, but now, I only get a whiteScreen...
So my question is, what url should I use ? Also, is there something else to do after packaging ?
Thank you for your answers.
EDIT:
Alright, so I tried actuator but that didn't help me...
With /actuator/mappings, I could see that my endpoints are correctly configured but when I use the executable jar, http://localhost:9091/contextPath/endpoint odes not work while it does if I compile with my IDE...
I don't know what url to connect to just to see the index... I'm using a very basic spring framework (boot and mvc) and my IDE is intellij community if this helps anyone
EDIT 2:
I tried to deploy the app on a local Tomcat9 to see if something would change but the connexion is reinitialized everytime I try to deploy a war using the manager, and there was no trace of error in the logs.
I tried using ./mvnw and it did work, endpoint and all, but it implies working with IDE environment
I tried using java (openjdk 13) and it compiled, but i couldn"t acces my own endpoint. I could still access the actuator endpoints so i don't know what to make of it.
Should the url be different depending on whether we are using IDE environment or just the jar?
EDIT 3:
Ok, I think have a lead but I have no idea how to resolve this:
when I began the web part of the application, I created a WEB-INF folder where I put all my jsp. My js and css files were in the resources/static folder. I tried once to put the jsp in the resources folder but it didn't work so I didn't push too hard.
Now, when I unzip the jar, i find my css and js files, but not my jsp.
When I unzip my war file, I have everything, but when I try to deploy it on a separate tomcat server, the connexion resets and I don't know why because nothing is written in the logs.
The issue then becomes:
Right now, I have
└──src
└──main
├──java
├──resources
| ├──static
| | ├──css
| | └──js
| └──template
└──webapp
└──WEB-INF
└──classes
└──jsp
What is the standard tree in intellij with jsp ?
By default Spring Boot apps are on port 8080.
Can you try http://localhost:8080?
Port can be changed in application.properties (or application.yml, application-profile.properties etc.) via server.port property (e.g. server.port=8888).
Ok, I managed to make it work.
I'm going to describe here everything of note that I encountered.
First, when I called my app to the usual url, there was no response (whiteLabel).
I added test logs and i found that I indeed called m controller.
I unzipped the jar and war i produced and came to the conclusion that the issue was architectural. I couldn't use jar, I had to use the war file.
I tried to deploy on a local tomcat server using the manager, but it always resetted the connection, so I took the manual approach - copy pasting the war file in the webapp directory.
Finally, the web pages were accessible in the browser.
Thank you for all the tips given during my research!
`http://endpoint:{PORT}/actuator/health` or `http://endpoint:{PORT}/actuator/status`
it should help but it must require spring-boot-actuator as a dependency in your pom/gradle file.
Could be a silly question, but...
I have a Spring-based WAR application that runs 80% of the installations on Tomcat and the rest 20% on WebSphere.
I need to simply get the path of the folder where Spring's MultipartFilter (using Commons multipart resolver) stores files being uploaded. I have never set it manually, and it actually belongs to the Catalina work directory as I found out in my Tomcat installations.
For the moment, I just need to get that path. I have control of my application so no one is going to change it without notice.
I would like to know if there is a server-agnostic way to know where my Spring-based application is going to store Multipart files.
E.g. from this question I can see I can use catalina.base, but in Tomcat... not in JBoss or WebSphere. It could cost me a couple of if/else statements...
Spring tries to do it already when no default value is set
WebUtils.getTempDir(servletContext)
Which simply does:
return ((File)servletContext.getAttribute("javax.servlet.context.tempdir"));
So simply if no one overrides that location in the filter properties (and that is my case) I can rely on the default.
More in general, one may have to inspect the instance of DiskItemFileFactory to get the path to the repository
I am trying to run my spring boot application (via Run As -> Spring Boot Application) in a tomcat8 container on STS and I am receiving these errors:
Caused by: java.lang.IllegalStateException: Expected method not found: java.lang.NoSuchMethodException: org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedContext.addApplicationListener(org.apache.catalina.deploy.ApplicationListener)
at org.springframework.util.ClassUtils.getMethod(ClassUtils.java:627)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.addListener(TomcatWebSocketContainerCustomizer.java:85)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.access$100(TomcatWebSocketContainerCustomizer.java:36)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer$1.customize(TomcatWebSocketContainerCustomizer.java:50)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.configureContext(TomcatEmbeddedServletContainerFactory.java:355)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.prepareContext(TomcatEmbeddedServletContainerFactory.java:184)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.getEmbeddedServletContainer(TomcatEmbeddedServletContainerFactory.java:154)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.createEmbeddedServletContainer(EmbeddedWebApplicationContext.java:157)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.onRefresh(EmbeddedWebApplicationContext.java:130)
... 7 more
I have searched around for this quite a bit and have found little to guide me in figuring out what the problem is. After going through the spring boot code in the debugger I see that the object named "instance" referenced in the TomcatWebSocketContainerCustomizer.addListener() uses reflection to retrieve a handle to it. This object is associated with the tomcat 7.0.53 jar ($HOME/.m2/repository/org/apache/tomcat/tomcat-catalina/7.0.53/tomcat-catalina-7.0.53.jar). I do not see this in any of my maven dependencies and have tried several techniques to force it to tomcat 8.0.20, nothing seems to work.
After banging my head for a while I started looking at the run configuration for the project in STS (via Run As -> Run Configurations). I found that the Source tab shows tomcat 7.0.53 above version 8.0.20 along with several dependencies that aren't referenced in maven. I am at a loss on where these values come from and not sure how to edit it. For some reason when I try to manually delete these legacy jar files STS doesn't allow me to delete any of them.
Does anyone have an idea of where these dependencies may be coming from and how I can remove them?
They do reference my $HOME/.m2/path/to/tomcat-catalina/<version> dir, so I could simply remove them from my .m2 and theoretically it may work but I'd rather not do this if I don't have to.
I am using spring boot 1.2.x and all of them have this problem.
thanks.
I've got two ideas that you might try.
1) It is possible, that this may be manifestation of this bug in STS 3.6.4: https://issuetracker.springsource.com/browse/STS-4085
The depencies you aren't expecting to see may be coming from the maven 'test' scope. (The bug explicitly mentions 'srt/test' but the same happens with jar dependencies). You can verify whether this bug is the cause by using the regular "Run As Java Application" on your main class.
If that works, then it is almost certainly this bug. If it also fails with a similar error then its something else... then try:
2) You must be getting the unwanted tomcat version from somewhere, probably indirectly as dependency of something else.
Try using the m2e 'dependency hierarchy' to find where it came from like so:
open pom.xml
Click the 'Dependency Hierarchy' tab.
Type 'tomcat' in the 'Filter' box.
I finally figured it out.
In my $WORKSPACE/.metadata/.plugins/org.eclipse.m2e.core/workspacestate.properties it lists all poms, jars and wars from my workspace build with the maven plugin. I noticed that a pom in the file points to the exact version tomcat that is being loaded in my spring boot project. Once I deleted these projects from my STS I can successfully launch the spring boot app :-)
When I re-import the maven projects back to STS the error occurs again, then disappears when I remove them.
These projects have no connection to the project that I am trying to launch. Therefore I think the bug is in m2e.
I'll file a bug and update this post when it is complete.
thanks #Kris for working through it with me.
I have a simple JSP/Servlet maven application which allows a user to upload an archive file. The application will then unzip the archive which contains XML files, and parse them using basic SAX parsing. It will generate an in-memory representation of these files, and write them to a Neo4J Graph Database, currently in embedded mode.
During development, I used a GlassFish v3 but with production in sight, the request has been made to move from Glassfish to Tomcat and so I did. Apart from a few small issues with Tomcat forcing me to add JSF dependencies despite the fact that I'm not using any JSF, there is one big issue I have with Tomcat atm.
The largest testfile I have takes about 8 seconds to upload and parse on glassfish v3. After that, it takes about 2 seconds less, due to the fact that I don't clean up the uploaded file (yet).
The same file on Tomcat7 takes about 90 seconds to upload and parse the first time. The other times it takes about 20 seconds less, presumably because of the same reason.
In any case, there's a difference in performance of factor 10. I'm a little bit surprised, since I thought that using Tomcat would actually increase the speed due to it being more lightweight than Glassfish, since I'm not really using the advanced functionalities provided by Glassfish.
Has anyone encountered a similar issue, and what did you do to resolve this? Is this even resolvable, or is it due to the way that Tomcat works...
EDIT: The difference appears to be in the code section that is responsible for writing the in-memory representation of the files to the actual database... No idea why though...
I could not find a comparison of Tomcat with Glassfish but yes, the new Glassfish versions are very light weight and have very good performance. I have experienced the same. I guess running an application server instead of a Tomcat is no more huge administration and hardware waste (and you can use light weight EJB 3 and 3.1 if you like). Glassfish installations can be very small in size if you only select the necessary modules.
Check this page. It compares Jboss, Glassfish and Resin
http://hwellmann.blogspot.com/2011/06/java-ee-6-server-comparison.html
And this one compares Glassfish 3.1 and Jboss 6 & 7.
http://hwellmann.blogspot.com/2011/10/jboss-as-7-catching-up-with-java-ee-6.html