As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
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?
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.
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.
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).
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.
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)
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'
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.
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.
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.
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.
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.
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.
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.
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.
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).
I recommended to you Tomcat with Spring because:
Spring can create backing beans for JSP
You will use Spring to persist object through JPA
It is good choice to choose Tomcat because you don't need any heavyweight processing
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I will be finishing the core Java course and now I have to move on to Java EE side.
I am so much confused that I should simply go with Java EE 6 because I have the books which easily teach from start to end and everything is there.
Or should I start with Spring only?
Because as I have to start from scratch it is good I follow the trend which is good and more job oriented.
Or even if I do Java EE only and then if I need to move on to Spring it will be fast or vice versa.
Also where does Hibernate stand between them? I mean if I use Java EE 6, do I still need Hibernate or in Java EE 6, I don't need it.
Will I be at a disadvantage if I don't use Spring or Spring can make my building web application any way easier than the core Java EE/ JSF framework.
Though your question suggests that Spring and Java EE are two different things, in reality they are not. You can use many Java EE components like
servlets and JSP for Spring MVC,
JPA for Spring DAO.
JTA for Spring security
The only major thing Spring replaces in the Java EE stack is the EJB. Unless you insist on using EJBs, Spring should be the way to go. Also Spring provides inbuilt support for webservices and other things as well.
Also checkout the Groovy and Grails that use Spring as the base.
Finally I would say, functionality wise both does the same. It's code (Java EE) vs configuration (Spring), a matter of preference really.
All my comments should be taken with a grain of salt. I've been a Spring user since version 1.0; I've never used any version of EJB in production - from 1.0 to the present.
Spring has served me well: any technique that I would want to apply from Java EE is available to me in Spring. I've used the web services, LDAP, messaging, and portlet modules along with the usual suspects from persistence, remoting, and web MVC. The code is excellent. I find that emphasis on layering, coding to interfaces, dependency injection and aspect-oriented programming benefits my designs.
The truth is that you can choose either and make it work. There's little advantage or disadvantage at this point, because EJB 3 took so much from Spring that they're supposed to be similar. I can't say that from personal experience, because I haven't used EJB 3.
None of my employers or clients are clamoring for EJB 3. People in my market are using Spring or .NET to talk to web services over HTTP.
EJBs require that you use RMI or CORBA as your network protocol. I believe that HTTP based protocols - be it RPC-XML, SOAP, or REST - are winning, because simple and open usually does.
No one can foretell the future, so job prospect advice is worthless. Your local market conditions might not be the same as mine. You can hedge your bets and learn both. Whichever you choose, it's almost certain that you'll have to learn something new in the future that won't be either EJB or Spring. So pick one and be ready to change.
From my personal experience from learning Java EE/Web programming from the just standard Java, I tried to jump right into some of the frameworks without a clear understanding of how the Java EE/Web stuff worked. While not all of Java EE is relevant if you are using a framework like Spring, I think it is a good idea to have a good grasp of some of the underlying technologies. You don't have to go overboard, but understanding some of the basics is a good idea.
When something is not configured correctly in the libraries (like Spring) sometimes they assume a certain level of knowledge on their user's part. After struggling with a few basic issues, I spent some time and went back to the basics. After that I was better able to deal with the frameworks.
I would just forgo the EJB route though.
First please understand that Java EE is not a single specification, but a set of specifications. While Spring is a framework.
Spring has a neat integration with many Java EE specifications including EJBs.
The idea of using the specifications is to make your application portable between different implementations of this specification. Unfortunately this doesn't work very well in real life.
Now regarding Hibernate. Again: it's a framework. Java EE includes a specification called JPA. Hibernate implements JPA. You may find other implementations. So if you are using another implementation, you don't need Hibernate.
Now, you are probably want to know the bottom line. I don't really have it. If you are studying Java, the more you know, the better it will be.
If you are looking for technologies to start a new web application, I believe it's better to use Spring with a servlet container (servlet container is part of Java EE!) like Jetty or Tomcat + to use JPA (Hibernate implementation) for persistency.
Spring and Java EE 6 is in some sense similiar. They goes their way in parallel. I think it will be better if you learn Java EE 6 and then (if want/need) learn Spring.
In Java EE there is Java persistence that works very well for different database query purposes.
There is really no reason to go with Spring on a new project. There are a lot of applications out there that still use it though. You should definitely learn Java EE before Spring. Spring used to make development easier. At this point though Java EE is easier to work with and you can get rid of the Spring dependency as well.
In the previous J2EE versions, it was common practice to complement the default libraries with frameworks like Spring, Hibernate, Struts, etc.
Java EE 6 seemed to close the gap (with CDI, JPA, JSF2.0, etc.) - should I still use additional frameworks (Seam? A faces library? Spring?)
I am currently using the default Oracle stack - GlassFish v3, JSF (Mojarra) 2.0
The common practice in J2EE 1.3 and J2EE 1.4 was indeed to supplement the J2EE stack with quite a lot of additional frameworks. Theoretically you could build an application using only J2EE, but I think not even Sun recommended doing that for any non-trivial application.
The frameworks you mentioned (Spring, Hibernate and Struts) are exactly the ones I remember that were often used.
Starting from Java EE 5, and now certainly with Java EE 6 you don't need additional frameworks anymore. Everything the core Spring container added to J2EE can now be done with the lightweight EJB3.1 and CDI component models, ORM support is provided by JPA (which is often implemented by Hibernate, but that aside) and an MVC web framework is part of the standard stack via JSF 2.
Of course individuals may still prefer the Spring and Struts programming APIs, but with Java EE 6 there is no pressing need to use them. Or put differently, it's no longer absolutely needed to complement Java EE.
That said, Seam does provide some nice (portable) extensions to Java EE and JSF was actually build to be used with extension and third party component libraries. Such component library is however not really a 'framework', but just gives you extra widgets to use on your pages. It's not the same thing as replacing JSF with say Struts or GWT.
I'm not really sure I understand your question.
If a third-party library/framework adds some functionality that is non-trivially beneficial to your application, you should almost certainly use it (political restrictions notwithstanding). If you don't get any benefit from a framework, leave it out.
I really don't think you should think of this in terms of "complementing the default libraries" - it's simply a case of what's the most efficient and most robust way of creating an application with the functionality that you need.
So simply evaluate the technical merits of each framework (individually) against what you're currently using, and then go with the most appropriate one. The correct answer will vary depending on your individual circumstances, so it would be wrong for someone to say e.g. "Yes, you need Spring and Hibernate but ignore Struts."
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My goal is to make web applications!
I finished reading the Books "Headfirst - Java" and "Headfirst - Servlets and JSP".
Because this topic (web applications) is so big and complicated, I would like to ask what I should learn next. I feel overstrained when I read catchwords like Java EE, EJB, JSF, JPA, Glassfish ... but I won't give up.
Can anyone please tell me how I should proceed with learning? Should I grab a book like this:
Beginning Java EE 6 Platform with GlassFish 3: From Novice to Professional or should I just make some Online tutorials?
Thanks!
Even if I know that this will be controversial, my advice would be to start with Java EE 6 only. So, grab GlassFish v3 and either get the book Beginning Java EE 6 Platform with GlassFish 3: From Novice to Professional or follow the Java EE 6 tutorial. In my opinion, the book (that I've started to read so I know what I'm talking about) provides more guidance which might be preferable if "everything" is new for you (it covers both the Java EE platform and its APIs and the environment to build, deploy your applications).
Now, as I said, I can already hear voices saying things like "Java EE is heavy, use Spring instead, learn Struts or Wicket or Stripes for the presentation layer, learn Hibernate for persistence, or not because I don't like ORM, use iBatis or straight JDBC instead (you'll see, it's cool with Spring, Spring is so cooool), and use Tomcat (and why not Jetty), or JBoss, or just forget all this and go for Grails, and bla bla bla...".
But I don't think that this is really helping you and, without mentoring or guidance (and you won't find a non outdated unique resource covering all combinations), this must sound very confusing for a beginner.
So, because I think that Java EE 6 is a big improvement over previous versions of Java EE, because it provides really nice standard APIs for all your needs (Servlet 3.0, JSF 2.0, JPA 2.0, EJB 3.1 lite, Bean Validation 1.0, CDI, etc), because these APIs are all more than decent, because there is nothing really wrong in learning them, because this is already a big task, because you have to start somewhere, I'd focus on Java EE 6 only and forget the other frameworks for now. More precisely, I'd start with the Java EE 6 Web Profile (and then add things if you want to go further).
By doing this, 1) you'll get started and you'll learn brand new things and 2) you'll give some time to all other frameworks and/or tools to adapt and prove that there is still a need for them. And if there is, it will still be time to experiment the survivors and you'll be able to understand much better why they exist.
My advice1 is to stop reading books and start implementing stuff. In my experience, book learning is poor a substitute for the knowledge you get by actually doing things.
Obviously ... you can come back and do some more reading later. And you will probably get more from the reading when you do.
1 - Context: this is advice to someone who has just finished reading two books on the topic, and is looking for more books to read. In practice you need to balance reading with doing.
Java EE 6 is really amazing. The only problem is that it's about 2 weeks old, and there is only 1 container currently offering it's features -- Glassfish.
I have nothing against Glassfish, I use it all over the place, several production instances, I love the product and the project.
That said, the details of Java EE 6 do not translate back to Java EE 5. Some do, many do, but the Web Profile, Servlet 3.0, the new Bean types, JPA 2, etc. Those aren't there.
So, by learning Java EE 6 first, you're simply constraining yourself to a single container. More are coming, but they're not here yet.
Tomcat, JBoss, OpenEJB, Glassfish, Jetty, Resin, Geronimo, etc. all work well with the Java EE 5 spec (at least those parts of the spec that they support, Tomcat doesn't have EJB for example).
I can't think of anything in Java EE 5 that wasn't carried forward to Java EE 6. Java EE 6 made some very old aspects optional, and those you simply wouldn't learn today anyway. Java EE 6 made some Java EE 5 stuff even easier (packaging notably, EJB Lite for example).
Learn Java EE 5 now so that you can actually apply what you learn in a variety of environments, rather that learning Java EE 6 now and discovering you may not be able to use much of what you learn.
No single book will teach you what you need to know. Servlets, for example, are a nice foundation, but for anything larger than a couple of pages or endpoint, you will want to use one of the many 3rd party frameworks, or JSF, and no book covers the core and then a framework on top of that.
The Java EE 5 tutorial is good at getting the foundations down, my major complaint is that they don't show you the source code. Rather they expect you to just download and run it. It's not discussed in the tutorial. I've found the Head First books to be pretty good.
For web programming, raw Servlets are important enough just to understand the request/response cycle but you don't need a deep understanding to make a leap to a 3rd party framework.
I'm a big fan of Stripes for an Action framework (vs a component framework), and the single Stripes book available is excellent (making choosing that an easy choice).
I can't suggest a Component framework book, and I actually would not recommend one right off. The component frameworks truly bury the HTTP core request/response structures. They bury them for a reason, and they gain value BY burying them, but I believe to be effective you need to have a solid understanding of these concepts early on. That's why I don't suggest learning a Component framework first.
The JAX-RS REST framework, included in Java EE 6, but readily installable in Java EE 5 or any servlet container, is excellent. Arguably it is what Servlet 3.0 should have been. But I don't know any books for that.
For Tomcat, read the manual on the website. It is very good. Particularly, the first few chapters on web app organization and deployment, and the chapters on the Servlets API and JSPs.
For Spring, the Manning book Spring in Action is very good. Similarly for Hibernate (the Manning book) but I think Hibernate is mostly outside the scope of webapps. Your call, though.
Wicket - Manning book also. But really, just write your front-end code in Javascript. It will be less painful, IMO.
I won't comment on other technologies but if you want to learn Hibernate get "Hibernate Made Easy" by Cameron McKenzie(www.hiberbook.com). It is worth every penny. You can finish reading that book in 2 days(literally). it is like a novel and at the end you find yourself dealing with Hibernate like a Semi-Pro.
Jpassion provides good videos and material to learn Java EE 6 and other stuff.
You should also see applications examples:
Petstore. Requires Maven, Glassfish recommended. Written by Antonio Goncalves who wrote the mentioned book.
JBoss Ticketmonster. Requires Maven & Jboss Forge. Deploy in Jboss.
If you just want to create web applications in Java, check out the Play Framework. It is similar to "Ruby on Rails"
I have many years of experience in Java including Swing, Servlet and JDBC, but have never programmed for a Java EE server.
Many job advertisements from large companies are specifically asking for Java EE experience. Are there specific skills or development environments that I should learn to qualify for these kinds of jobs?
Download JBoss and get to work on the sample applications in the documentation. If you've done java, you're 95% there. Java EE adds the container and naming aspect to the java you already know and love. With the advent of EJB3, beans got a lot simpler as you only need a couple of annotations to get rolling with EJB. Java EE can be a bit daunting with the acronym soup of technologies available, but concentrate on the basics: EJB3, JNDI, JMS, data access (like Hibernate/JDO), and container basics.
"Are there specific skills or development environments that I should learn to qualify for these kinds of jobs?"
If I were to interview someone for a typical Java EE shop, I would like to know how well you know the following
1) servlets
2) EJB (maybe)
3) JSP
4) ant
5) junit
6) subversion or other VCS
7) http and html
8) javascript
9) struts
10) hibernate
11) spring(maybe)
I'm not trying to scare you BUT 1/2 of what you need to know you can get by the "PROFESSIONAL J2EE" from WROX press. Rest of the skill, you should be able to get by with a spring book(most spring books also talk about stuts and hibernate) -- for example "The Spring Primer" -- http://www.sourcebeat.com/books/springlive.html.
Good Luck
Those jobs are most likely asking that you have experience with one or more of the major app server vendors, i.e. WebLogic, WebSphere, or JBoss. It's a bit different from what you're used to with servlets & JDBC, but it's still just Java. Typically you have to deal with things like JNDI lookups, dependency injection, messaging queues, maintaining application state between transactions, object/relational mapping, etc.
I have found that for most Java EE projects, it's more about knowing how components and systems are configured and how they work together than it is about any specific programming skill. And you also spend a lot more time waiting for the server to start up ;);
get the book "Professional J2EE" from WROX press -- it is 6-7 years old BUT the content is pretty good. You should be able to get by just fine with that book and a 3.x version of JBoss or a 4.x version of JBoss and eclipse.
Whenever you do start interviewing, Ken, be aware that the nutty Java marketing machine seems to be renaming J2EE to Java EE. You could conceivably run across an HR department in the near future that has never heard of J2EE, but desperately needs Java EE experience.
I think you're in good shape. Servlets are part of Java EE so you already have one skill. JDBC are used as well pretty much the same, but most of the time under some other frameworks.
So I would say you already have ( some ) Java EE experience. Read about EJBs, Transactions, and I think you're ready for an interview.
A lot of times the only way to get that experience is getting hands on. If you convince your interviewer that the skill you have already are enough as to get the position, you'll get the rest by experience.
Go on! You're ready. ( if not at least you'll learn from the interview :P )
Do you still use session or entity EJBs in your project? Why?
EJB3 is a vast improvement over previous versions. It's still technically the standard server-side implementation toolset for JavaEE and since it now has none of the previous baggage (thanks to annotations and Java Persistence), is quite usable and being deployed as we speak. As one commenter noted, JBoss SEAM is based upon it.
EJB 3 is a viable alternative to Spring, and the two technologies may become more tightly related. this article details that Spring 3.0 will be compatible with EJB Lite (which I'm not sure what that is, exactly) and possibly be part of Java EE 6.
EJB is not going anywhere.
We're working with EJB here and it works quite well with JBoss Seam and JSF, Faclets and MyFaces Trinidad. Good UI, Templating, AJAX and stable production 24/7 running on JBoss 4.2.
It's a good stack for business processes, workflows, messageing, webservices and ui control. Fast delivery of features, easy programming and stable ground based on entitybeans with mysql persistance.
I don't want to miss the featureset of EJB 3 for the tasks our product demands.
See the overview of new features in Java EE 6. EJB 3.1 and WebBeans 1.0 help make a Java EE 6 container environment become easier to use, similar to frameworks like Seam on Java EE 5 or Spring. If you're familiar with Spring 3, this article illustrates how Java EE has evolved to become a comparable framework.
EJB is still there and growing up. There are many new features (SOAP/RESTful webservice, JPA entities, JAXB...) depend on it or at least reuse the philosophy of developing.
Yes, but EJB were stupidly complex for most use cases. Very clever, but real overkill in most cases. Hence the lightweight approach taken now-a-days.
Justin
I've just started back to work on an EJB project. I didn't remember how heavy and hard was to work with this technology. It was luck when Spring, Hibernate and Maven came. Since then everything was different and much easier.
I always could see this technology was never used properly and was taken as a pattern that I never understood.
It was supposed you needed two containers and if it was possible one server for each container. One for Business(EJBs) and another one for Views(MVC). I never saw that.
Well, it's good to know that EBJ is upgrading.