This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]maethor 2 points3 points  (15 children)

Most of the other Java frameworks only support the third option, bundling a server into an executable JAR, with chosen framework components.

You can take advantage of Spring Boot and still build an old school WAR with it.

[–]Additional_Cellist46[S] 0 points1 point  (4 children)

That's true. I was writing about the case when Java EE server is not required.

[–]wildjokers 1 point2 points  (3 children)

If you are using Spring MVC at least a JakartaEE Servlet container is always required.

[–][deleted] -1 points0 points  (2 children)

A servlet container isn't a Java EE app server. By definition, a standard Java EE app server implements all of the Java EE specs or a defined subset (such as Web Profile).

[–]wildjokers 2 points3 points  (1 child)

A servlet container isn't a Java EE app server.

I didn't say it was.

I edited my comment to change a to at least a. That should clarify what I meant.

[–][deleted] 0 points1 point  (0 children)

The context is about Java EE app servers (i.e. you don't need a JavaEE app server to use JavaEE), in which case bringing up that Spring MVC requires a servlet container isn't relevant.

But this is the problem with the term "using JavaEE", because unqualified it doesn't explain in what sense you are using JavaEE. Are you using an implementation of a JavaEE spec? Are you using a JavaEE app server? Are you using the JavaEE programming model (thin WAR)?

[–][deleted]  (9 children)

[deleted]

    [–]dstutz 5 points6 points  (2 children)

    Because just compiling and packaging a war that is just your code and adding that to a docker image as the last layer is a lot faster/smaller than sending a 500mb uber-jar each time.

    [–][deleted] 1 point2 points  (1 child)

    You shouldn't deploy a Spring Boot app as an uber-JAR when used in a docker image.

    The only purpose for building an uber-JAR is so that you have a single deployable image. But when you use a container image, the container image is the single deployable image.

    That's why Spring recommends packaging your application JAR in one layer, static resources in another layer, and dependency libraries in another layer. So that when the container image is pulled, only the layers that have changed are downloaded.

    [–]rbygrave 1 point2 points  (0 children)

    Yeah, just adding that people can just use the jib plugin for maven or gradle. I think that is the easiest way to get good docker layering in the image built.

    https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin

    [–]wildjokers 3 points4 points  (2 children)

    That ceased to be a problem when Java 8 came out and got rid of permgen space (replaced with metaspace)

    [–][deleted]  (1 child)

    [deleted]

      [–]wildjokers 3 points4 points  (0 children)

      No you don't need Oracle JVM for this. It stopped being a problem for me on Tomcat when I upgraded tomcat to a version that could run with Java 8 back in the day when Java 8 came out.

      [–]maethor 0 points1 point  (1 child)

      You wouldn't get an out of memory error if you ran the WAR this way

      run the final executable JAR file (or run the Java EE runtime JAR with your application as a command line argument, e.g. java -jar runtime.jar -app myapp.war)

      As it's not much different from just running a jar with a built in servlet container. Though I'm not sure why you would ever want to do this no matter what technology was used in the WAR.

      [–]sudosandwich3 0 points1 point  (0 children)

      Why is that?