We Keep Coding

Spring boot embedded container or war file in an external container for production

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.

Difference between JAR and WAR deployment based on performance

What are the major differences between a web application deployed as a JAR versus it deployed on an application server as a WAR?
My case is that, I have developed a REST service using Spring Boot and that is packaged as a JAR file. The service may have to handle 500-1000 requests at the same time and I'm working on improving the performance of the service.
From a performance perspective, is it better to install an application server and deploy the application as a WAR rather than just execute the JAR as a standalone process?
Would the application server like Tomcat give more control related to number of configurable threads as compared to its JAR counterpart?

The question is a bit incorrect, as JAR and WAR are simply a packaging format.
SpringBoot uses Tomcat as an embedded server by default, so there won't be a difference between running Tomcat as application server and deploying your application as WAR, or simply running a JAR.
What really matters is your code. If you plan to serve 1000rps, I would highly advice looking at Spring Reactor (as you already use Spring) or Vert.x, to provide as much concurrency as possible.

Not sure if it is this is exactly what you are looking for.
But this link will definitely add a point to the discussion-
https://dzone.com/articles/standalone-web-application

They are all ZIP format files, not any differents, just the ext string.

Should we use ApacheCXF or EJBs for communicating the logic and web modules?

We are currently developing a web application for college and we would like some advice from a more experienced developer.
We have a backend using Hibernate to operate on a MySQL database. Another project is the web UI that uses the API delivered by the backend (registering user, fetching data associated with certain profiles etc.). We use the JSF framework (RichFaces) for the UI. Everything is built using Maven.
The technology we can't decide on is for the communication between UI and logic modules. The first option is to use ApacheCXF to provide SOAP webservices that UI can be a client of. The second option is to use EJBs to invoke backend methods from the UI module.
What approach is more widely-used? As far as we read on the Web, using EJB is faster than SOAP webservices. On the other hand, we don't have any experience with EJBs using Tomcat (we would prefer using Tomcat since it seems to be a cheaper option, however we don't know what we would have to do in order to use EJBs with Tomcat). Additionally, working with webservices since the beginning will allow us to add support for different platforms (for example, Android).
Another aspect which we are discussing is about how should the application be deployed. The alternatives we have considered right now are:
Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
Deploy a WAR project and EJB project.
Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)
The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.
Any advice would be appreciated. Thanks.
Edit: So any advice about how the project should be deployed? Is it necessary to use EAR? Is there any advantage if we deploy the project as an EAR module?
Edit 2: We found the advice we needed on this thread: Deploying java applications (Tomcat/Glassfish)

First things first. I would avoid using Web Services if there's no need for it. If you feel that you might need to call this system from external programs and platforms, then go for it. Even then, I would only use the web service interface for external integration, and still have an internal EJB implementation.
EJBs are awesome for enterprise applications. I would highly recommend that you look into that. They provide support for EJB Pooling, Transactions, Aspect oriented programming, Security, Stateful sessions, Java Messaging, JNDI etc. And you can inject them directly inside a Managed Bean (JSF). You said that you will eventually handle millions of users, so I assume that you will want your application to run as fast as possible, I don't think SOAP web services will be a good fit. Remember that SOAP web services encode messages as text, so if your application will be sending binary files etc, then you'll suffer significant performance issues.
As far as deployment goes I would go with an EAR, or a WAR for the JSF and and EAR backend. you can use Injection to pull the classes you need, even remotely, from multiple web applications and other EAR apps.
I'm not sure why you say Tomcat is Cheaper. Glassfish open source edition is a fully functioning JavaEE6 Server and its free. JBoss is also JavaEE compliant and is free. both of them are used in lots of production environments. I find glassfish to be much more user friendly, and would recommend it to EJB noobs :)
I also started with Tomcat, but now I don't use it at all. why use the servlet container only, when you can have the whole shabang? hope this helps.

we use ApacheCXF at work and its has SOAP and Restful. Reliable and relatively easy to setup. I am not sure why you want to use glassfish maybe it's preference but you can implement your projects in eclipse too. It's really that is up to you and your team and the requirements and skill sets your team may have to build and support, that a side CXF webservice+apache + eclipse with maybe two war files would be a good path.

I wouldn't use web services in this case. You can use managed beans as controllers.
Put the logic into EJBs, views into rich faces and control the flow using managed beans.
If you use maven you can generate a project with the structure of EAR (war for web module and jar for ejbs). I don't remember the name of an archetype but you can find it easily.

Adding a web interface (Spring MVC) to existing Java application

I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.

If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.

It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.

How can I embed Weblogic server in java?

I am searching any way for embedding Weblogic server in Java , I know its possible because we have maven plugins for Weblogic which embeds Weblogic in maven, But googling for it did'nt gave me useful output, Does anybody know how can we embed wemlogic in java program ?

WebLogic doesn't provide an embedded API so, even if it's a pure Java Server and if you can thus call weblogic.Server from Java code, you will have to handle everything yourself (starting the container, waiting until it's started, deploying things, waiting until they are deployed, etc). In other words, this will require some work.
Maybe have a look at the sources of Cargo, although Cargo isn't really starting an embedded Weblogic (i.e. running weblogic.Server in the same JVM). This will give you an idea of what has to be done. Or, depending on your needs, use Cargo Java API.
But if you need a full Java EE server and if this is an option, I would use GlassFish v3 in embedded mode instead of WebLogic, it will be much simpler. Check the following links and see yourself:
Embedding Glassfish V3 in Unit Test - Two Jars, Three Lines Of Code And Five Seconds Start With Deployment
Embedding EJB 3.1 Container Into Your Unit Tests - Boot Time: 5 Seconds
Using the EJBContainer API with or without Maven (but with GlassFish v3)
TOTD #128: EJBContainer.createEJBContainer: Embedded EJB using GlassFish v3

Do you need WLS specifically, of any servlet container would do? If the latter is OK, then use Jetty.
WLS is not designed to be embeddable. But you can do it. After all, WLS is just a class named weblogic.Server. Setup classpath correctly, setup PATH and other environment variables (see setDomainEnv.sh and startWeblogic.sh), start that class from Java, and you have an "embedded" WLS.

There is probably a way, but I don't know it. My experience from writing maven plugins tells me that the most likely way that the plugin works is that it starts up a new command line process just like you would normally start up the server. So in a sense, not really embedded it.
The best way to see is to track down the source of the plugin and see how they did it.

WebLogic doesn't support embedded mode like Glassfish but you can have control over your Weblogic using "WebLogic Maven Plugin", this provide several maven goals for managing and working with Weblogic instance.
See this link for further information.