To enforce the create-drop hibernate option I need to shutdown tomcat(?), however if I were to do that my jenkins server is also shut down. At the moment the jenins job simply builds the war and then copies it to webapps directory.
I want to enforce the create drop hibernate option on my web app without restarting tomcat/jenkins, is their a way to do this ?
As other users already stated you do not have to restart tomcat in order the restart a web application inside it. There is a deploy plugin available in Jenkins which is perfect for your scenario: https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin .
By the way, Jenkins comes with an embedded Jetty server so it is very straightforward to run this outside tomcat:
https://wiki.jenkins-ci.org/display/JENKINS/Starting+and+Accessing+Jenkins
In case you are just starting with this application then consider using Liquibase to manage your DB creation, upgrades, ...: http://www.liquibase.org/ . It can be integrated with hibernate if desired and you could then easily create a Jenkins jobs that does a liquibase drop_all/update to recreate your database (schema) without touching your running application.
Well i think you don't have to restart the server just redeploy the application.
Related
I am building microservices(approx 15 to microservices) project for huge organization, I wants to know is it recommended to go for external tomcat with war file or just use the embedded tomcat of spring boot with jar file. Also I am facing issue after building my project on jenkins how to copy the file from jekins server to my server and run the file there and create and automatic build and deployment pipeline i.e. everytime I push the code it should be automatically deployed.
You need to identify what compels you to go for external tomcat deployment. As SpringBoot provides out of box facility to deploy within the container, it is not required to go for external tomcat deployment.
Besides, if you are going for many microservices, it will be good to have with built in springboot with embeded tomcat. Springboot also provides the facility to use undertow or jetty. I would recommend to use SpringBoot with either embeded tomcat or undertow with docker container for more flexibility.
It will be good if you provide the issues you are facing.
You can check the below link for reference.
https://dzone.com/articles/spring-boot-with-external-tomcat
I didn't encourage until today companies using Spring Boot and deploying in an external Tomcat.
If there is no requirements from your Infrastructure department, I would go with the embedded tomcat.
JARs vs WARs
I think both have their use cases, like a car vs a truck.
Getting started with jar files is definitely easier, it's provided out of the box. However, using war files in a tomcat has a few perks too:
You can use the "manager" UI to update/redeploy a webapp easely
You can monitor server status, inspect sessions, basically have a look under the hood
You can deploy/update multiple wars independently, which might be handy for larger project
...but there is definitely some learning curve to set things up, and it feels a bit ...old. So it's up to you if you want an easy "jar car" or a whole "servlet container truck". ...or you can also have multiple cars. ;) Each has ups and downs.
Pipelines
Like for any other topic, there are very different ways to achieve this. If you use an extern tomcat, you may configure a "script" user and deploy it like this (or similar):
curl -u username:pwd -d path=/something -d war=file:target/someWar.war https://someurl.com/manager/deploy
...or you can go the other way round and create Docker images, or cloud-init VMs or whatever. Or just a shell script to stop it remotely, upload it and start it.
Depending on your situation, the know how of your team mates, etc, one or the other may be easier.
I'm complete able to configure spring boot in both cases, the question here is which of them are more robust and is the more recommended, because I didn't find in the spring boot documentation the recommended way to deploy it in a production environment, my concerns about use the embedded container are:
If I want to set it as a Windows or Linux service, is the jar file the best option?
If I use the jar file I'm not going to have access to restart the server.
Maybe in the future I need more applications in the same container.
If I restart the machine I have to execute again the java -jar.
The question in general is which is better use the jar file and execute it as java -jar jarname.jar in production or change the packaging to war set the tomcat as provided and set the generated war in an empty tomcat.
I hope you can help me.
---EDIT---
Many times the answer is depends, this is for a normal web application or REST web service.
jar packaging is perfectly suitable for production and you should rather fallback to war only if you really have to - which is often the case when you cannot control your deployment environment (which is often the case in large enterprises).
There is a chapter in Spring Boot Reference about setting up Spring Boot based application as a Unix/Linux/Windows service: Installing Spring Boot applications.
Regarding your concern:
Maybe in the future I need more applications in the same container.
With embedded containers if you need more applications running on the same machine, you should start two applications separately, each running on different port and effectively you will end up with two containers running - which is good, applications are better isolated from each other.
About a month ago I had the question like yours.
Let me share my conclusion:
1) JAR:
You can run independently every appliction with different ports (in linux, java -jar ... > app_logs.log &) and you can route it (e.g. nginx). Note that, restarting is not problem. You can write custom bash script (like this: ps aux | grep appname and kill by PID)
But there are some problems with configuring production app. Property files will archived into jar.
2) WAR
You can deploy into container and just run it. Easy managing at the server. If you want to re-configure app, open properties file from unarchived folder inside container, change it as need and restart container. So, managing and configuring will be easy.
But, if you want to run another app in this server with another port, then you must install another copy of container and config it.
So, in my practice, using war app easier than jar to manage and re-configure.
I don't know that much about Windows services but on Linux you can add the execution of a jar to a RC-Scripts (and thus make the application start at a certain run-level). For a spring boot app you just have to symlink to the jar and you can start/stop/etc like any other service, see: Spring Boot application as a Service
restart the machine or the JVM? A shutdown mechanism is built into spring boot, you just have to activate it (and you should enable security machanism so that not anybody can do that), see: How to shutdown a Spring Boot Application in a correct way?
Spring-Boot enables microservices - so the idea is to have one embedded webapp-container for each webapp/microservice. This reduces the risk of losing all services when only one is going down.
Yes. and you have to execute catalina.sh|bat start after every restart. Or you add an appropriate startup script (see 1.)
I sense that you'd rather do it the old-fashioned way. Despite the 'matter of taste' answer, there is one argument pro-jar: the only dependency is the JVM! The rest (the web-app-container, db-drivers, other libraries) is all part of the package you deliver. And if you decide to change the container for the next release, so will it be.
One more reason to use "war" file in production.
Springboot masked an error Jetty threw whereas WAR deployed in Jetty correctly caught it ( though issue below is still under review )
https://github.com/spring-projects/spring-boot/issues/8917#issuecomment-294673487
I don't know much about server kind of things, But my recommendation is
If you are using Monolithic application, better to use war with
external tomcat.
If you are using for Micro Service applications, use embedded
tomcat with different port. And each micro service applications are
independent from each other.
So I'm really new to the Java webstack world, and had a question on the most efficient solution to my problem. Some background information first; I'm running Tomcat on a Lubuntu 14.04 server listening on Port 80, developing on a separate Windows computer in Spring Tool Suite (developing Spring applications obviously). Currently, whenever I want to test something, I...
1) Export the project as a WAR file from Spring Tool Suite
2) Undeploy the old WAR file from the server from the Tomcat manager webapp
3) Deploy the new WAR file that I just got from Spring Tool Suite (which takes ~15 seconds)
Is there any faster way to do this? Normally, I wouldn't be opposed to just developing on localhost. However, I'm going to be doing a group project, so we would all need access to the same SQL server, which would be the one hosted on the Lubuntu 14.04 server.
How can I solve this issue?
Most IDEs have the ability to deploy to server for both development and production purposes.
Those that don't have this ability inbuilt, ususally have a add-on that enables this.
You can also use build tools such as maven or gradle to undertake these actions.
Since you raised a good point of working with others it is important that all are across the deployment process and that the process is standardised to ensure no weird issues/bugs pop up.
We are developing a new project (spring, mvc, jdbc, rest) which we are considering to deploy it in JBoss Wildfly 8.1.0. Before we were using the JBoss 5.1.0 where we had datasource and other configurations easily created and configured along with the war file. As I am trying to learn the Wildfly I feel it has datasources and other things to be configured separately through cli or ui console.
Instead every developer in this project configuring the datasource manually on their system-server for development, is there a way to run a script to generate datasource or other way to have a single server configured with everything the project requires so that the developers can deploy their modules (war) and test it?
I see the Wildfly has two modes, domain mode and standalone mode. Is this domain and "5.1.0 domain" are different? Which is the right mode to run the server in production? I am testing my application for now in standalone mode. From the jboss doc, I see this domain is for managing the app if it is deployed in a cluster. (This project under development is non-clustered single node web-application.)
How to deploy more than one web-applications in a single Wildfly server? Do I need to create domains for every application?
How to configure app specific property files in Wildfly? (We had a prop directory created under the jbossserver/default/deploy/prop/application.properties)
You can use CLI to create datasource from command. With CLI commands you can create script also. You can find it on Google. It will be server specific and no need to create in your project.
If you don't want to run jboss in cluster mode then you can use
standalone.
You can deploy any number of web application. You need not to create
domain. Just create WAR files and deploy. You can copy WAR files in {JBOSS_HOME}\standalone\deployments folder.
What is the best way to manage deployments of a single web-app to multiple non-clustered tomcat instances.
My ideal solution will support:
A simple API - invoked with
groovy/ant/Rest or similar
Success/failure
notification for all nodes
Atomic
deployments - if the deployments
fails on any node it is rolled back.
We had over 100 clients each running on a dedicated tomcat instance across 5 servers where most would be updated to the latest release at the same time. In our case we used mapped network drives and some tricks with the CATALINA_BASE, but personally I think it may be easier to use WAR deployment via an ANT script to the Tomcat manager if you can get away with it.
For yours you could (at minimum) have a tomcat directory for each instance and each can use the same webapps dir via a network share. Upgrading would still require stopping each instance, updating the single shared dir then starting all instances.
You could also use the tomcat management console (via ANT or other automated process) to manage a scripted local installation or start/stop but this would be not be atomic.
You might want to look at using Tomcat manager from Ant. It might not have all you are asking for, but I guess you could script what you need.