Home/ Questions/Q 6818723
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T21:12:50+00:00

Hi guys : I’ve used JSP/Servlet frameworks pretty broadly, generally picking up Java EE

  • 0

Hi guys : I’ve used JSP/Servlet frameworks pretty broadly, generally picking up Java EE tricks when necessary (for example, when my data access code get complicated, I usually adopt Ibatis/Hibernate ; or when my UI gets ugly, I start using tools like guice/spring DI to simplify testing) …. However, I’ve never seen the point in a “full” Java EE stack — usually most applications only need one or two of the typical Java EE features.

My question is : What is the benefit of full blown Java EE containers ? It seems like running a standard tomcat server, dependency manger, in the context of a daily test/builds cycle is capable of managing complexity pretty effectively, in my experience.

My thoughts :

1) Maybe Java EE stacks like glassfish/jboss are more scalable (i.e. they can be easily extended to handle higher volume with out spot coding or ad-hoc optimizations) ?

2) Maybe Java EE stacks are more modular (i.e. they can communicate with other Java EE components that were built for different contexts ?)

3) Maybe Java EE stacks allow seamless interoperation between different features (for example, maybe JMS interoperates cleanly with JPA data operations, so that you don’t have to “manually” glue different system components together…) ?

Any thoughts on these suggestions would be appreciated … I’m somewhat new to heavyweight Java EE frameworks and am trying to contextualize their usefulness over simpler, homegrown mvc code-bases.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    However, I’ve never seen the point in a “full” Java EE stack — usually most applications only need one or two of the typical Java EE features.

    How is that a reason not to use a Java EE container, though?

    One thing you have not mentioned is declarative transactions, you definitely need those. Spring can do that too, but from what I’ve heard it takes some extra work to get distributed transactions.

    Which leads use to the topic of clustering, which EJB containers have built in according to the standard. If you need scalability at the service level, it takes very little work if you’re running on a Java EE server. If you use Spring, there are some third-party solutions, but not a standard.

    And there’s all the other APIs that are part of JAVA EE – JMS (Messaging), Java Mail, JAX-B (XML binding), JAX-WS (SOAP web services), JAX-RS (REST web services). If you use a Java EE server, you can be sure that it has implementations for all of them ready and integrated should you need them. Sure, it’s also possible to get each of them and integrate them into your Spring-based or homegrown solution, but I’d say you’re rather more likely to run into integration problems or just simply produce a mess.

    • 0