91

I'm starting a new project now. I have to choose technologies. I need something light, so no EJB or Seam. On the other hand I need JPA (Hibernate or alternative) and JSF with IceFaces.

Do you think that such a stack on Spring 3 deployed on Tomcat is a good choice? Or a Java EE 6 web application could be better? I'm afraid that Java EE 6 is a new technology, not well documented yet. Tomcat seems to be easier to maintain than Glassfish 3.

What's your opinion? Do you have any experiences?

Piotr Nowicki
  • 17,914
  • 8
  • 63
  • 82
Piotr Gwiazda
  • 12,080
  • 13
  • 60
  • 91

16 Answers16

102

I need something light, so no EJB or Seam.

Would you care to explain what makes EJBs heavy since EJB3? Do you realize that we are not in 2004 anymore? I'd really like to read your definition of light and your arguments (and I will update my answer with pleasure because I'm pretty sure I would have a few solid things to say).

On the other hand I need JPA (Hibernate or alternative) and JSF with IceFaces.

Java EE 6 Web Profile which includes JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI,... would be perfect for this and you can use GlassFish v3 Web Profile to run an application built with the Java EE 6 Web Profile.

Do you think that such stack on Spring 3 deployed on Tomcat is a good choice? Or a Java EE 6 web application could be better?

Well, I like the idea to run my code on a non-proprietary platform (Java EE) rather than on a proprietary container (Spring). And I think that Java EE 6 is good enough (and this is an euphemism, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Note that I was a JSF skeptic but I took a second look and JSF 2.0 with CDI is so different that I can't even compare. And if you didn't look at CDI, let me tell you that it rocks.

I'm afraid that Java EE 6 is a new technology, not well documented yet.

Java EE looks pretty well documented to me. This sounds like free claim. And, believe me or not, I start to find Spring getting complicated while Java EE getting easier.

Tomcat seems to be easier to maintain than Glassfish 3.

Did you try something? Did you face any particular problem? Again, this sounds like free claim.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
  • 2
    I'm just after rater big project developed with EJB3.0+Seam on JBoss with Drools, GraniteDS and some more. I agree Seam rocks ! But I spent 50% of developement on redeployement, restarting servers, deployment errors, cleaning temp directories etc. On the other hand JBoss Tools performance was really poor (I mean really - ctrl+space and 10s hang) This realy discourages me to use JEE6 which looks like borrowed from Seam framework. As for server I don't want to think about conecion pools, jndi, jms, jmx, ear deplyment. I need something to put WAR on and run in seconds. – Piotr Gwiazda Mar 26 '10 at 14:40
  • CDI looks like copy-paste from Seam Framework (actualy project Weld IS developed from seam). I can get something similiar in Spring with SpringELResolver. – Piotr Gwiazda Mar 26 '10 at 14:44
  • 6
    @peperg Gaving King is the spec lead of CDI (Weld being the RI) so you'll find similarities between Seam and CDI. But CDI != Seam, Java EE 6 != Seam, your perception is wrong. Maybe try GlassFish v3 Web Profile, you'll be surprised (and once the connection pool defined, there is not much to worry about). – Pascal Thivent Mar 26 '10 at 15:17
  • 8
    What is it with people saying EJBs are heavy?. I'm using EJB v3.1 and they are simply annotated pojos. When they say heavy do they mean in performance or what? – arg20 Jan 29 '11 at 08:47
  • 13
    @arg20 - That's indeed the big question and Pascal rightfully asks to explain what the term "heavy" (or "light") means in this context. Most likely it's a remainder of the old feud between Spring and EJB. In the early days, EJB1 & 2 were conceptually heavy. An overemphasis on remoting and stateful beans, a ridiculously verbose XML deployment descriptor and a totally insane amount of required interfaces to be implemented gave them a very bad reputation. With EJB3 (2006) this has completely changed, but people who left EJB in 2004 for Spring sometimes still think its 2004 and EJB2 is the latest. – Arjan Tijms Feb 13 '11 at 14:52
  • 7
    Note that on Spring's about page it says "We believe that: J2EE should be easier to use". Note they use the term "J2EE" and not "Java EE", which has been the correct name since the release of Java EE 5 (I think). This says much about them... – Vítor E. Silva Souza Oct 04 '11 at 09:05
  • @PascalThivent: I have similar situation and I would really like to know your views on http://stackoverflow.com/q/9263251/164299 – Rachel Feb 14 '12 at 18:05
34

I have not used JavaEE6.

However, I have been beaten up badly enough by all the previous versions of JavaEE and EJB's that I won't trust it until it establishes itself as the de facto standard, not just the de jure standard. Right now, Spring is still the de facto standard.

Fool me once, shame on you. Fool me twice, shame on me. Fool me three times, EJB.

Some will claim that Spring is proprietary. I would argue that the vendor implementations of the JavaEE specs have been just as proprietary, if not more so.

I went through a major conversion recently of moving a bunch of Java Applications from JBoss to Weblogic. All of the Spring/Hibernate apps ported with zero modifications, because they had all the libraries they needed built in. All the apps that used JPA and EJB and JSF were a disaster to port. Subtle differences in interpretations of JPA, EJB, and JSF between appservers caused all kinds of nasty bugs that took forever to fix. Even something as simple as JNDI naming was completely different between AppServers.

Spring is an implementation. JavaEE is a spec. That is a HUGE difference. I would prefer to use a spec IF the spec was 100% air-tight and gave absolutely no wiggle room in the way vendors implement that spec. But the JavaEE spec has never been that. Maybe JavaEE6 is more air-tight? I don't know. The more you can package in your WAR, and the less you depend on AppServer libraries, the more portable your application will be, and that, after all, is the reason I use Java and not Dot-NET.

Even IF the spec was air-tight, it would be nice to be able to upgrade the appserver without having to upgrade all my technology stacks in all my applications along with it. If I want to upgrade from JBoss 4.2 to JBoss 7.0, I have to consider the impact of the newer version of JSF on all of my applications. I don't have to consider the impact on my Spring-MVC (or Struts) applications.

Beaker
  • 744
  • 7
  • 18
  • 1
    Exactly, this is a great reasoning. – Palesz Feb 29 '12 at 13:28
  • 1
    I agree with this reasoning, many problems I've faced have been with dependencies on a container's implementation of a spec. Significantly less pain from embedded libraries. Hard to argue, outside of the philosophical preference of a spec. – Peter Porter Nov 05 '12 at 05:08
  • Wonderful reasoning. However is this your experience even after JEE 6? I understand App Server implementations of specs can still be a pain - hence the same spec implemented by App Server 1 may be a simple and efficient while not for App Server 2 – Soumya Feb 05 '13 at 11:25
  • 1
    +1. also, the application server changes on Operations' schedule, where spring/hibernate is under the control of the developers. in a big company environment upgrading the appserver is a much bigger deal. – Nathan Hughes Jan 15 '14 at 17:21
  • I didn't really get the point about Dot-Net. It is as much propriatery as Spring and is developed by a single vendor which is Microsoft. Could it be explained please? – Sergey Podolsky Mar 13 '16 at 22:14
  • I wasn't jabbing at Dot-Net for being proprietary. I was jabbing at it's lack of portability since Dot-Net applications only run on Windows...or at least run best on Windows. – Beaker Mar 15 '16 at 13:14
  • the word is thrice* – Alexandros Kourtis May 27 '21 at 18:11
23

It doesn't matter. Java EE 6 is good enough and because of the profiles there, it is not "heavy" - you'll just be using the web profile.

Personally, I prefer Spring. But I'm running out of rational arguments against Java EE 6 :)

(As I was reminded by a comment - you might want to try RichFaces, as well as ICEfaces and/or PrimeFaces - depending on what components you need).

informatik01
  • 16,038
  • 10
  • 74
  • 104
Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
17

Recently, one of my client assignments involved evaluating Spring Stack Vs Custom framework stack Vs a Java EE Standards. After a month of evaluation and prototyping, I was not just happy but blown away by the Java EE 6 feature set. For any new "enterprise" project architecture in 2011 and going forward, I would go with Java EE 6 and potential extensions like Seam 3 or the upcoming Apache JSR299 extensions project. Java EE 6 Architecture is streamlined and incorporates best of many open source ideas that have evolved in the last several years.

Consider the following features out of the box: Event Management, Contexts and DI, Interceptors, Decorators, RESTful webservices, integrated testing with embeddable container, Security, and many more.

Most of my results are published in my blog explaining the key concepts of Java EE 6 that you might find useful.

Of course, there is no hard and fast rule for choosing a framework. Java EE 6 could be well bloated for simpler "web sites" that don't require a rich conversational session state. You might as well pick Grails or Play! Framework. But for conversational web applications, I can't see a better argument why Java EE 6 is not a good fit.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
pri
  • 1,533
  • 4
  • 19
  • 29
  • Java EE 6 is just freakin' slow, glassfish and glassfish web profile is just really slow to start comparing them to jetty/tomcat/whatever. Testing, embeddable container is also really slow. – Palesz Feb 29 '12 at 13:22
15

Now, after some time, I have experience with stacks :

  • Java EE 5 + Seam + GraniteDS + Flex
  • Spring 3 + Vaadin (on GWT)
  • Spring 3 + JSF 2.0 (PrimeFaces)

My colclusions are:

  • Spring 3 is much much simpler than Seam (almost Java EE 6) and runs on Tomcat and Jetty! (Jetty for developement with maven plugin is a trasure).
  • I love Flex (I actually was a Flex developer for long time so I'm biased) and if you need rich interface and can buy FlashBuilder use this, but use this wich Spring + GraniteDS or BlazeDs backend. If you can't buy FlashBuilder don't waste your time.
  • Vaadin is great!. Developement process is simpler than Flex, but you can create rich application easily without HTML mess. You wont't write a singe JS line. You just need some CSS (in Flex you need it too). So if your application interface is going to behave like desktop application and you can't (or dont want to) use Flex - use Vaadin. Warning! Vaadin has big JS overhead for browser.
  • If you create simpler website-like application use JSF2.0 (with spring backend as above). You'll need to fight with HTML (I hate it) and creating rich interface will be harder than Vaadin (especially layouts). You will get lightweight HTML for slower browsers/compuetrs. I like PrimeFaces - it's easy and well documented. Second place is IceFaces
  • If you create a website (NOT a web application) where you need to put life into HTML (instead of create enterprise application that fits into browser) use Wicket (if you prefer component based, pull attitude) or SpringMVC (if you prefer template based, push attitude) or just use Play! framework. Remember that creating rich data-based components will be much much harder but you will have control over each tag of html (your HTML/Graphics designer will love it)
Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Piotr Gwiazda
  • 12,080
  • 13
  • 60
  • 91
  • 21
    I don't see how your own answer relates to the question... – Pere Villega Jul 18 '11 at 14:36
  • 1
    -1 It seems very inappropriate to accept this answer, since it doesn't even mention Java EE 6. Moreover, it doesn't address any of the points raised in @Pascal Thievent's well-thought-out (and much more highly voted) answer. – user359996 Feb 24 '12 at 02:50
  • 1
    Actually question is not more valid. JEE 6 is now very mature, it wasn't in March 2010 when the question was asked. – Piotr Gwiazda Mar 01 '12 at 14:27
  • @PiotrGwiazda in what way did JEE 6 change since then? People were more afraid of it back then, but it was basically the same JEE 6. – ymajoros Sep 03 '12 at 08:47
  • 1
    I meant that JEE6 implementations are more mature and available. JBoss 7 is now stable and there are more implementations available. Community is larger now too. More tools and libs now support JEE 6 stack. – Piotr Gwiazda Sep 03 '12 at 09:08
8

Read Adam Bien's Future Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa), including comments to get both sides of coin. I will choose Spring for several reasons and following is one of them (reproducing one of the comments from post)

'I am not sure which Java EE 6 server you are talking about. There is Glassfish certified and TMAX JEUS. It will take quite a while (read: years) until Java EE 6 compliant versions of WebSphere, WebLogic, JBoss etc are in production and can be used for real application. Spring 3 just needs Java 1.5 and J2EE 1.4 so can readily be used in almost all environments'

reevesy
  • 3,452
  • 1
  • 26
  • 23
Adisesha
  • 5,200
  • 1
  • 32
  • 43
  • 6
    We're almost exactly one year later now and JBoss AS 6, which supports Java EE 6, is currently being used in production. – Arjan Tijms Mar 27 '11 at 10:02
8

My opinion is based on something not mentioned by others, namely that code at my work tend to live for decades (literaly), and hence that maintenance is very important to us. Maintenance of our own code, and the libraries we use. Our own code we control, but it is in our interest that the libraries we use, are maintained by others in the above mentioned decades or more.

To make a long story short, I have concluded that the best way to achieve this is by using open source implementations of Sun specifications all the way down to the raw JVM.

Of the open source implementations Apache Jakarta has proven to maintain their libraries, and recently Sun has done a lot of work in producing high quality implementations for Glassfish v3. In any case, we also have the source for all modules, so if all else fails, we can maintain them ourselves.

Sun specifications are usually very strict meaning that implementations conforming to the spec can be interchanged easily. Just have a look at servlet containers.

In this particular case, I would suggest having a look at JavaServer Faces simply because it is part of Java EE 6 meaning it will be available and maintained for a very, very long time. Then we have chosen to augment with MyFaces Tomahawk as it gives some useful additions, and it is a jakarta project.

There is nothing wrong with JBoss Seam or others. It is just that their focus is less towards the maintenance issue that is so important to us.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • It turned out that Java ServerFaces 2 in Java EE 6 could do on its own what we needed Tomahawk for with JSF 1. It is a quite capable framework (but a bit XML heavy) – Thorbjørn Ravn Andersen Nov 09 '11 at 20:57
  • Great point, unfortunately people tend to forget that software are made to live for decades and that long term support is a crucial key. – timmz Feb 24 '15 at 17:32
6

I can see using Spring if you already have it, but for the new project, what's the point? I would go directly with Java EE 6 (ejb3, jsf2.0, etc.)

If the client is fine with Flex, go for it. Use BlazeDS or similar - no mvc. You might spend more time on that part (exchanging data between server and client) but you have full control on both sides.

Don't use Vaadin, unless you want to kill your browser. Plus, you spend more time on getting around the code once your pages become more complex. Also, your mindset will need to be completely changed and anything you know about standard front end development will be waste. The argument that you don't have to use HTML or JS doesn't make much sense. You still have to know it even if you don't use it. It renders to HTML and JS eventually. Then try to debug it - make sure you got few days for simple stuff. Plus, I cannot imagine web developer who doesn't know html/js.

I just don't understand why people are trying all those abstractions instead of using Java EE directly.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Marcin Koziarski
  • 69
  • 1
  • 1
5

Why is there still rumblings about EJB being heavyweight in 2010? It seems people are not being updated in Java EE technologies. Just try it out , you will be pleasantly surprised how things are simplified in Java EE 6.

nash
  • 121
  • 1
4

The answer to your questions depends on your project requirements. If you don't require the Java EE features like message queues, container managed global transactions etc then go with tomcat+spring.

Also from experience I have found that projects that require a lot of web service integration, scheduling, message queues are best best done using some of the Java EE stack. The good thing is using spring you can still integrate with Java EE modules running in an application server.

Java EE 6 is very different from the previous releases, and it really makes everything lot easier. Java EE 6 combines the best ideas from the diverse Java community - for instance Rod Johnson from Spring framework was actively involved in the making of the Dependency Injection JSR in Java EE 6. A benefit of using Java EE 6 is that you are coding according to a standard, which could be important in some organizations for vendor support etc.

GlassFish v3 supports Java EE 6 and it is quite light-weight and starts up really fast. I have been using glassfish v3 for my developments, and it is really easy to configure. It comes with a very user-friendly admin console that lets you graphically administer your server.

If you are using GlassfishV3 and JSF 2, then you can take advantage of the CDI features of Java EE 6, that lets you easily create conversations (e.g. wizard like pages) in JSF.

Having said that, using Java EE 6 also requires you to learn a new API. Depending on the timeframe available it might not be the best choice for you. Tomcat has been around for ages, and the tomcat+spring combination has been adopted by many web projects, which means lots of documentation/forums are around.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Raz
  • 860
  • 1
  • 9
  • 12
  • I do not agree with your first sentence, the choice is not about using JMS or not. And I don't think that JSR-330 is that important in Java EE 6 (it is more there for political reasons), the important part is JSR-299 (CDI). At least, this is my opinion. – Pascal Thivent Mar 25 '10 at 09:29
  • Agree there were some politics involving JSR330 - nevertheless it is quite important as it provides a common basis for dependency injection in Java (SE or EE) rather than making DI a JEE-only technology. Also, it is supported by Spring framework and Google Guice, which means it will make Spring/Guice code easy to port over to JEE6 or vice-versa. JSR299 was also designed to extend on the features in JSR330. You are correct in that for web applications in JEE6, JSR299 is absolutely crucial. Thanks to these two JSRs, JEE6 & Spring both have very similar programming model. Thanks for ur comment! – Raz Mar 27 '10 at 07:40
3

I have worked in both Spring and Java EE 6. What I can say from my experience is that If you are going for the age old JSP or proprietary Flex then you are safe if you stay with Spring.

But if you are to move ahead with JSF then it's time to shift to Java EE 6. With Java EE 6 you are moving to Facelets and standardized script libraries and component libraries. No more script incompatibilities and component library matrices.

Regarding Spring MVC, it's good as long as your project doesn't grow too big. If it's a huge enterprise application stick on to Java EE 6. Because that's the only way you could maintain your own component libraries and resource bundles in an orderly manner.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
user373480
  • 163
  • 2
  • 9
3

If you need the Java EE full stack I recommend you GlassFish 3.1. It starts very quickly compared to other Java EE containers which implements some part or all Java EE 6 (JBoss 6, WebLogic 10.3.4), redeployment take seconds and almost all can be done by convention over configuration, it is very friendly.

I you want something "Light" you can customize an Apache Tomcat 7.x with the desired features. I used a lot with the following libraries: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - only resource local transactions JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Been a Java EE developer for the past 10 years (I suffer early EJB, JSF and web technologies), Java EE 6 is very easy, well coupled and current hardware runs smooth so original reasons that motivated Spring are no longer valid.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
ssamayoa
  • 157
  • 1
  • 5
  • 1
    I like your answer. Very reasonable. When I posted the question JEE6 was very young and Tomcat 7 wasn't finished yet. "original reasons that motivated Spring are no longer valid" - it's true, but JEE6 with CDI needs some time to cath up. For example: Javamelody monitoring is available for Spring and Guice (I can't imagine woring on applications without it). EHcache is available for Spring (I mean caching methods results). Lots of things like aspect programming are still easier in Spring, because lots of third party libraries and frameworks integrates easily with Spring but not with JEE6 yet. – Piotr Gwiazda May 24 '11 at 05:37
1

I'd still prefer Spring.

And I'd pass on JSF. I think it's a dead technology. Spring MVC would be a better alternative. So would Flex. Think in terms of contract first XML services and you can decouple the back end from the UI completely.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Do you have Flex+Java experiences to share? – Thorbjørn Ravn Andersen Mar 23 '10 at 12:25
  • 1
    I've created some applications with Java+Flex and PHP+Flex and I agree that it's the best solution for rich interfaces. But in this application I can't use Flex :( I need some high-level interface though, so Spring MVC is not a solution. I want to think about sortable datatable either than in a loop. – Piotr Gwiazda Mar 23 '10 at 12:58
  • What does "high level interface" mean? Why is JSF acceptable and Spring MVC not? – duffymo Mar 23 '10 at 13:16
  • Flex + Spring + BlazeDS is a nice combination. – duffymo Mar 23 '10 at 13:16
  • 1
    @duffymo - I can argue whether flex is a good choice. JSF is definitely not dead, especially with libraries like richfaces, primefaces, icefaces, etc. around. – Bozho Mar 23 '10 at 13:45
  • 1
    In IceFaces I create menus, trees, datagrids use actions, events and I don't think if page reloads or is it ajax request. An sortable datagrid or ajax loaded tree is a buil-in component. In Spring MVC I operate on HTML - tables, lists etc. I need to use some third party javascript framework and create AJAX magic by hand. I'd like to do it in Flex but it's a political/business decision - not mine. – Piotr Gwiazda Mar 23 '10 at 13:48
  • @Bozho, I think it's dead because it's not used at all from where I sit. It's not about libraries. I think the mindshare is going to RIA technologies, not JSF. The one application that I saw using JSF was written so poorly and consumed so much memory on the browser that you could time page renderings with a sundial. The team that wrote it might not have been the best, but it wasn't a very inspiring start. JSF is deader than the proverbial doornail. – duffymo Mar 24 '10 at 01:16
  • 1
    My current two JSF projects are definitely not dead ;) And I'm way more satisfied with the JSF way to build RIA ("rich" in "richfaces" is for that), than using Flex. One is even going public next week. – Bozho Mar 24 '10 at 09:45
  • 2
    I'd really like to know why you'd still prefer Spring, Java EE 6 is damn good. Don't you think that running on an open platform is important for the future of Java? – Pascal Thivent Mar 25 '10 at 04:50
  • No, I don't. I think the calculus changed when Oracle purchased Sun. They aren't the same company. The fact that Spring has been closed for the ten years it's been evolving hasn't hurt the quality or my future at all. – duffymo Mar 25 '10 at 10:15
  • 1
    Hmm... Spring, which is not ten years old, has taken a dangerous path very recently only (the past doesn't mean anything). And the Java EE standard isn't driven/owned by a single entity, Snoracle can't change this without destroying Java EE (which makes no sense IMO). I'm not following you. – Pascal Thivent Mar 25 '10 at 10:55
  • The open source availability of Spring isn't ten years old, but the development of the framework is. "Expert J2EE" was published in 2002, so the development of interface21 preceded the publish date. Are you referring to the VMWare purchase or the separation of the community and professional versions for Spring? I don't know about Oracle destroying J2EE, but it's certainly been dormant for a very long time now. Where's the new version of WebLogic? Where's Java 7? Nothing appears to be happening. – duffymo Mar 25 '10 at 11:00
  • 1
    I'm referring to Spring being a proprietary container and to the proprietary tc Server. Regarding Oracle, digesting BEA and Sun will clearly take some time: WebLogic 12 has been announced for 2011, don't know for Java 7 (but I don't really care, I want to play with Java EE 6 first). – Pascal Thivent Mar 25 '10 at 11:52
  • But offering a proprietary container doesn't preclude using Spring with Java EE standard containers. BEA was purchased a while ago; the Sun deal only closed recently. WebLogic 12 in 2011? That's an eternity since WL 10 came out. I'm not sure that Java EE 6 will be adopted by conservative Fortune 500 companies until after 2011. There's a difference between developers playing with technology and adoption in the workplace. I think Spring is still worth considering: I can use it now. – duffymo Mar 25 '10 at 14:19
  • *That's an eternity since WL 10 came out* Yeah, and even more since WebLogic 6 came out :) At least compare to 11g. But I get your point and it will indeed take some time before adoption of "major" Java EE 6 app servers, especially by Fortune 500 companies. Still, GFv3 (and soon JBoss 6, and more) may be an option for some people, like it is for the OP in the context of *this* question. The OP can use Java EE 6 now. – Pascal Thivent Mar 26 '10 at 12:15
  • 1
    The year now is 2012.... Its fun reading the comments made in 2010 – joshua May 10 '12 at 18:26
0

I'd recommend Spring + Tomcat unless you can wait the time for glassfish v3 and Weld to become more mature. There are currently a few issues with memory consumption/cpu load when running glassfish with CDI enabled applications.

0

Didn't read everything but just to tell that you can now use EJB3 inside a war on Java EE 6 so you can use EJB3 on Tomcat (I think).

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Sebastien Lorber
  • 89,644
  • 67
  • 288
  • 419
  • Yes, you can package EJBs in a WAR in Java EE 6 but this doesn't mean you can deploy such a WAR on Tomcat. You need a container implementing the Web Profile and Tomcat doesn't and there is actually no plan in the Tomcat community to implement it (see http://old.nabble.com/Java-EE-6-Web-Profile-td27715793.html). But there is GlassFish v3 Web Profile, there will be Resin... – Pascal Thivent Apr 05 '10 at 19:56
  • 2
    update: take a look at TomEE+ project http://tomee.apache.org/apache-tomee.html – gpilotino Apr 03 '13 at 09:59
-3

I recommended to you Tomcat with Spring because:

  1. Spring can create backing beans for JSP
  2. You will use Spring to persist object through JPA

It is good choice to choose Tomcat because you don't need any heavyweight processing

Guido
  • 46,642
  • 28
  • 120
  • 174
bassem
  • 168
  • 2
  • 7