My question is about deployment to a Tomcat server instance which hosts multiple applications and hosts application contexts for Struts, Spring, and Hibernate. I would like to deploy changes to one application without restarting my Tomcat server.
As an example, many times in our firm we have to deploy new applications or versions of applications to our tomcat enviroment and the process could be:
Move class and jsp to the exploded folder then the context reload itself, or
Another scenario is when we have to deploy new features which require
modifications to xml contexts such as struts-config.xml or spring-application-context.xml.
Currently we have to restart the web-server to load new configuration. This would be OK if Tomcat did not have other live applications which we did not want to interrupt and restart. As an example, if I have an application which uses hibernate and struts, then I have to re-deploy it to a Tomcat server with many other applications running, and I deploy the new application and restart the server. This is not ideal.
So the question is when deploying changes to Tomcat, including context changes, do I have to restart? Is there a way to do a hot deploy for only this specific application and maybe re-start only its context without restarting the webserver?
Thanks a lot!!
Best regards
You can set the "autoDeploy" attribute to "true" in server.xml. You can read more detailed information here http://www.mulesoft.com/tomcat-deploy.
Hope this helps.
Related
We have multiple web applications in one tomcat instance on 1 server, all running a spring-boot application inside.
Whenever we start tomcat and it starts to boot up all the spring-boot applications we mostly see that each application might use property files/settings from another application.
What especially happens is that we see it sometimes use the database information from other applications being used, resulting in a database which holds tables from other applications. This is scary since we might start a database migration or something.
We also see that the logs are written to the wrong project log file.
We define these settings using a application.properties like (or sometimes application-test.properties or application-secret.properties):
spring.datasource.username
spring.datasource.password
logging.file.name
Anyone have an idea why this is happening?
We found 2 possible causes for this behavior:
if Tomcat is started in a directory where application property files are present, or where application property files are placed in a /config subdirectory, like a WEB-INF/classes directory, these application property files are used by every Spring Boot application deployed in the tomcat instance. To fix this, make sure the Tomcat start script changes the working directory to a directory not containing application property files.
if the 'startStopThreads' attribute of the Tomcat Engine element in server.xml is set to values higher than 1, Spring Boot applications seem to occasionally and randomly use application property files of other Spring Boot applications deployed in the Tomcat instance. When 'startStopThreads' is set to 1, we don't see this behavior.
I'm running a spring boot executable jar as a service under Linux and it works fine.
My question is, there is a way to replace the running jar with new jar without stopping and rerunning the service?
Thanks,
Avi
In a nutshell, it is impossible to reload spring-boot jar in production environment.
I guess your final goal is to "hotswap" your application without user notified. Thanks to service discovery, you can do this by:
Start your new application and keep the old ones running.
After the new one started and registered in service discovery server, shutdown the old ones.
That's how we do upgrade of our services, and Docker saves us a lot of time.
I need to simulate the presence of a Load Balancer (WebSeal) in my local installation of WebSphere 8.5. In detail, when an application is exposed through webseal is added into the URL, before the Application Context Root, the webseal Junction name. For example, an application with context-root "myapp":
Without webseal: localhost:8080/MyApp/......
With webseal: localhost:8080/JunctionName/MyApp/......
So i need to simulate this because i have shared DB with common configuration between my local installation, without webseal, and test installation balanced by webseal.
There is the possibility to configure a common context-root that the AS have to add to the URL of the deployed app in WebSphere 8.5?
I'm not aware of a way for one app to have two context roots, but for your local installation testing purposes you might be able to install two copies of the app, one at each context-root. It's probably a change to application.xml, or if you're deploying through the console UI, I think it's
configurable there.
Is it possible in Jboss deploying a ear and war file in the same server instance? If so any good source to get started? Any suggestion.
I have two applications deployed under my default deploy folder of jboss. I am running one application from which i have to call the other application to get some data. Is this possible? If so how to get started??
It is actually recommended that you only put 1 application in a server instance as a time. That said, I have had multiple ears and wars running in the same instance while I am developing. But for production it is better to separate them out. Since there is no extra cost involved this makes it easier to observe and debug apps.
Do you have a specific reason for wanting them to run side by side?
What version of JBoss are you running.
Can we develop a struts+spring+hibernate application on tomcat server and later deploy it on say Web Sphere or Web logic Application servers?
If this can be done please explain the process of deployment? If this cannot be done please let me know the reason?
I am new to working with application servers. An explanation will be greatly helpful.
Thank you,
user181333
Most of the time, Spring is application server agnostic (but well, people always, always debate such things). That means that you should have no trouble deploying web applications in different containers.
Anyways, some portability issues may arise. The only ones I am aware of is classpath loading resources because of the servlet container implementation of class loading. Another is if you registered a TomcatInstrumentableClassLoader or something similar. And maybe JtaTransactionManager lookups.
For exact details in concern of deploying a web app just refer to the documentation of your specific application server.