I have created two separate maven modules (let's call them MODULE1 and MODULE2) which are submodules of a third integration module (SUPERMODULE).
MODULE1 and MODULE2 are both Spring Boot Web Applications. What I'm trying to achieve is to start (not build) both projects / web apps by means of SUPERMODULE.
As I see it, there are two options:
Deploy them both to the same tomcat server (probably the better & more interesting solution)
Deploy them to different tomcat servers with different ports
I found no viable example to achieve either one of these options (... by means of a single maven integration project). Hence, I would be glad if someone could point me into the right direction - or are both possibilities bad practice?
You said :
Deploy them both to the same tomcat server
(1) Build automation software
Any Build Automation tool (Jenkins, bamboo...) would allow you to create a job that deploys both your wars to tomcat (the same server or different server, you can setup your job as you wish).
Do you use an automation software ? I believe that would be the best the solution / best practices.
(2) Build an EAR - Deploy to Tomee
You said:
What I'm trying to achieve is to start (not build) both projects / web
apps by means of SUPERMODULE.
What you are really describing is an EAR!
I'll describe the idea, however, it seems Spring boot does not play well with EAR: Spring Boot EAR Packaging and https://github.com/purple52/spring-boot-ear-skinny-war
Since your 2 submodules are spring boot app, you could:
build the submodules as WAR
have your Supermodule build an EAR
include both WARs in the EAR (maven dependencies)
this however implies that you use (for instance) Tomee instead of tomcat (is that an option for you?).
as mentioned above, after some research it seems a spring-boot war does not work when packaged inside an EAR. The SpringServletContainerInitializer isn't called. So this would not be an option at the moment.
Related
I've seen Spring Boot Rest project that generates WAR then deployed in a tomcat container. I wonder if this is best practice because I've also read that in Spring Boot, the new final executable JAR file contains embedded server solution like Tomcat too?
Now i've seen a related post that talks about Spring Boot supports both ways but none talked about the pros and cons of each.
Can someone point out the best practice for deploying a spring boot rest project?
I'm thinking of dockerizing the JAR containing embedded server but i'm wondering if there's any drawbacks vs deploying WAR to Tomcat?
A general best practice ( from 12 Factor App ) regarding the application environment and dependencies is "Explicitly declare and isolate dependencies".
A twelve-factor app never relies on implicit existence of system-wide
packages
With that in mind one should gravitate more towards using embedded container as part of explicit dependency instead of a requirement that needs to be fulfilled separately.There are multiple choices for embedded container in the jar artifact (like tomcat, jetty, undertow, netty) and their respective configuration is also extensive, so using these in production environment is recommended ( I have used them a lot). However there might be certain times when you would want to create a war instead, for e.g., a war file will be deployable in any full-fledged EE Application server ( Weblogic, Wildfly etc) which might be mandated by your environment. With a war, your number of options in terms of app server increases. Personally for me, spring boot jar with embedded tomcat has been quite effective. With embedded container option what you need is a virtual machine with OS and Java installed and you are good to go.
However there is a special limitation related to JSP as mentioned here in Spring Boot documentaion which explain a good reason why you might need to package as a war but still run as jar.
I have a Maven component service that I package up as a WAR file. I would like to create another Maven project that builds a fully deployable Jetty container with a few custom configurations and contains my component service in it so that I can test my WAR or even deploy it. My questions for this scenario are:
Is it common to want to keep the WAR build separate from the distribution build? My thoughts behind doing this is that someone may not want to use my custom configured Jetty container. Maybe they want to create their own build with Tomcat or something else.
If this is a common thing to do, what packaging type should I use for the custom Jetty container project? It seems weird to me to use JAR or WAR since that isn't the actual artifact that ends up being built. And using "pom" packaging seems equally strange since I was under the impression that that is used for parent projects of submodules.
Ad 1. Yes, this is how I usually structure the project. There is an app project which is a container for application and a separate deploy project to handle the infrastructure. Regardless if it's building a container image, deploy to app server or whatsoever.
You can see it in an example project I've once created for a Devoxx presentation.
Ad 2. Default packaging (hence jar). If all you have in a project is a pom.xml (without any classes), no additional jar will be created nor installed. In the project I've mentioned the pom.xml contains only docker image creation 'logic'. In your scenario it will be jetty related plugin. No additional artifacts will be created.
Currently I'm deploying multiple war files into a Tomcat container. Is it possible to use Spring Boot to put all war files into a single deployable jar? I know this is possible for a single app, but can it be done to deploy multiple apps that once were in separate war files?
Spring Boot by design will run one app (one war) per container. If you want to go for the uber-jar deployment I suggest you stay with this since it is following also 12-factor-app best practices.
If you want to run multiple war files in one tomcat I suggest you follow the "old way" wrapping up your spring boot apps in war files and deploy them in an already set up tomcat or jetty or ...
So the answer will be: in principle – and with a lot of tweaking – you might be able to achieve what you are trying to do but this is not the intend of the jar distribution of spring boot apps. And always remember: work with the framework and not against it.
Tomcat container browses through the web apps and maps each war with the context root defined in it (single property of the web.xml). So, i do not think you can do merge the files in only one and still treat them as separate web apps.
What can be done is to actually merge the code of the web apps in only war file and split the functionality based on different paths after the context root path.
I am new to Spring MVC and I have now come accross tutorials that explain how to deploy your web project as a .jar. My IDE is the Spring Tool Suite. I have always used .war + Apache Tomcat.
Can someone elaborate a bit from the practical point of view why to use .jar instead of .war? Any problems to be aware of?
edit: other answers are welcome too
Spring Boot uses fat JAR packaging where is embeds Servlet container with all dependencies into this single JAR.
If you are using Maven, it uses spring-boot-maven-plugin to package the project.
Practical usage of this approach is simple. Ability to easily run Srvlet based Spring application from command line with externalized properties. Such configuration enables powerfully orchestration possibilities which are often used in modern enterprises in so called Microservices or SOA architecture.
There is group of people out there (including myself) which believe that deploying various WAR files of unrelated applications into single Servlet runtime is not very good idea.
So fat JARs are handy for separate Servlet runtime per application deployment.
About having .jar and Tomcat + .war on the same machine, it is possible and I use this. This may be not cool but I had a .war application running in a tomcat server before the rise up of spring boot. Now my new apps are spring boot apps, and we are migrating our architecture to SOA concept, but we can't change the tire with the moving car. The main application, the WAR is running in a tomcat server and the others (.jar) are self contained ( embedded tomcat ), each one running in a different port. It was the most viable solution available for us by the moment.
I am deploying the ear file each time when i making a changes as my project is multi-module and it is really tedious to upload/deployed the entire ear again in Jboss 7.Is there any way to replace only the changed jar/war/files in the already deployed ear in jboss without deploying the entire ear file again.
Thanks.
You should consider using JRebel - it allows reloading changes. After you compile any class it will automaticaly reload it, supporting modern frameworks (like reloading spring beans, etc) and application servers (JBoss included). It works as a java agent. You will find more details on producent site: http://zeroturnaround.com/software/jrebel/features/
To introduce JRebel in Maven project you just need to add jrebel-maven-plugin