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
I'm building a webapp that uses jboss-seam with jsf, facelets and rich faces, running on top of jboss AS 5.1.
I would like to add a portlet area where I could add my own portlets, but from what I got (reading forums and documentation) I need to be running a portlet container/portal (something like liferay or gatein). But I don't want to be running a portal. I just want some kind of control where I can embed a portlet (something like an iFrame).
Is this true or I got it wrong?
If I'm wrong, how can I add an area to my webapp where I can add a portlet?
Thanks
Best regards.
If you are looking for a JSR 286 (Portlet 2) or JSR 168 (Portlet 1) compliant portlet, what you have read is correct. You need a portlet container. JBoss used to have JBoss Portal that should fit in your stack if you are focused on the JBoss products. In fact, you can find an entire bridge between JBoss Portal and the stack you are using. If you decide that you need a portal and want to look to other apps, I have successfully run Liferay on JBoss in the past.
At the same time, you can get something that looks and behaves like a portlet by using iframes or a div and JavaScript and back-end coding. With more specifics on what you want your pseudo-portlets to do, the community can more specifically help you figure out if wiring your own smaller framework within your existing code or attempting to have some sort of larger portlet container seems more reasonable. If you want to reproduce all of the Portlet 1 or 2 spec, I'd go with the container. If you want to reproduce a mini-iGoogle, you can probably do someting with JS and HTML.
EDIT: Looking through other questions with the same portlet tag, I found the jQuery UI Sortable - Portlets demo that might provide just the portlet-like features you are looking for without an entire Portal framework. It does, of course, pull in jQuery UI.
Frankly, if you're not going to go "whole hog" with portlets, or the portlet you wish to embed is particularly sophisticated, I don't think there is much value to switching over to a portlet container.
With JSF being a component framework, the difference between a "portlet" and a "JSF component" are really more ideological than actually technical (yes, the development model is different, but not dramatically). You likely be better off create a new, high level, JSF component to act as your portlet than bringing in the whole weight and complexity of a portlet container in to your app for a single service.
What are the different ways to create a web-application in Java? Are there tools available other than straight-up servlets?
Open source web frameworks in Java and related view technologies:
Tapestry
Apache Cocoon
Apache MyFaces
Spring MVC
Google Web Toolkit (GWT)
Java Server Faces (JSF)
Apache Struts
Turbine
Seam
Makumba
Java Server Pages (JSP)
Stripes
OpenXava
JPublish
wingS
Strecks
AribaWeb
Echo
RIFE
Anvil
WebOnSwing
Click
ThinWire
Facelets
Wicket
Check http://java-source.net/open-source/web-frameworks for more options and to read a brief overview of each one.
There are many many web frameworks for Java that allow you to build Web Applications. The vast majority are built on top of the Servlet API, but provide a layer of abstraction that you interact with instead of dealing with servlets directly
My favourite (for what its worth) is Wicket
An quite old and simple standard is CGI, and java can do that: http://www.apl.jhu.edu/~hall/java/CGI-with-Java.html
A more recommended today would be to use a web-framework. These usually abstract from the Servlet API and provide a ground for common patterns in web development.
Here is a quite long list of available choices: http://java-source.net/open-source/web-frameworks
In java there's also Facelets, JSF and many other frameworks, like Spring MVC.
JuanZe gives a good answer with the list of frameworks. Here's some more detail.
I'd say take a look at Struts, as it's one of the oldest and simplest frameworks. Struts v1 and v2 are two different beasts; Struts v1.0 was written mostly in a day, and you can learn it in an hour, and might be a very good introduction to web frameworks.
I currently use Spring, and wouldn't go back to Struts from there. The nice part of Spring is that it comes with the framework (Spring MVC), but there are dozens of other "nice to have" components that really help you out as you continue to learn 'em.
Other developers I work with complain regularly that Seam is the way to go. They've said some pretty intelligent things in the past, but I really like Spring, and our project is married to it.
Wicket also looks interesting; Spring is very heavy on XML, and Wicket gets rid of that, which is a very happy thought. That said, there's a pretty huge gain with some of the XML in Spring, so I'd worry about losing that.
As an addition, I'd take a look at Apache Commons, formerly called Jakarta Commons. It's a collection of useful libraries of stuff that probably should be included in the core Java API. Discursive has a wonderful book that walks you through it.
if you are asking about tools interface to develop a web application.i suggest eclipse coz its too convenient to use,flexible and can run on pcs with low configurations.i have just 512 mb ram and i m using it easily
As a quickstart you could download Netbeans http://netbeans.org/ , you can try almost all kinds of J2EE technologies with a preconfigured app-server and database using included sample projects. It tooks only seconds to build and run and if you like analyze the code.
and here there is another one, a very young one this time: (ยต)Micro. It is open source, Apache 2 license, and available on Github. I built this framework for fun and I was trying to port and simulate as much functionality as I could from my experience as a Sinatra/Rails developer. Cheers!
I'm looking into implementing one of our internal applications as a portal using portlets, as it has many functionalities and not all of them are required by all users.
I've looking at the Apache protals site and I saw that there are two projects - Jetspeed 2 and Pluto.
Although Jetspeed is described as portal and Pluto as a portlet container, it also provides a portal of its own. What is the real difference between them and their functionalities? Can you recommend which should I start "playing" with?
Jetspeed 2 uses Pluto as its portlet container, but it is geared towards being a fully functional enterprise application, including its own suite of portlets, SSO, customizable security, themes etc....
If you are looking to get started with portals/portlets, the Jetspeed 2 project is moving along rapidly, and I would suggest joining the mailing lists, as they can be incredibly helpful. Also, download and build the portal from source using the tutorial on the apache portals site and you should be up and running with a custom portal in no time.
I have worked extensively with Jetspeed 1. I have been a bit out of the loop since J2 and JSR 186, but here is my best guess. It is only a guess, but I'm confident enough to post it here.
(Assumption: a portal uses a portlet container, and a portlet container cannot really run by itself.)
Jetspeed 2 aims to be a full enterprise portal which uses Pluto as the portlet container. Pluto has its own simple portal, as it does not want a dependency on any given portal project. I believe the Pluto portal is not intended as enterprise-level.
The statement above is supported by this part of the Pluto FAQ (from here):
Is Pluto an Enterprise Portal?
No, the Pluto project aims to provide a Java Specification compliant
Portlet Container. In order to support
the container, the Pluto project
provides a simple portal, however,
this does not provides optional
services such as single sign on. If
you are looking for an Open Source
enterprise Portal implementation,
there are several available. Apache
Jetspeed is an enterprise portal
hosted by the Apache Software
Foundation. Sakai and uPortal are both
educational portals which utilize
Pluto as their container. There are
many other open source portals.
Pluto is really not intended to be use as Enterprise Portal. It's useful for development(it's tiny&fast) and you can embed it if you want to develop you own Portal server. But that's a lot of work.
If you want to just "dive in" look at JetSpeed. Or I can recommend you to have a look at Liferay Portal. It's open source as well and it's going with a lot of plugins(portlets) right out-of-the-box. So it gives you a quick impression what is possible to do with it.
Do you know a technology which can provide me a portlet-like interface?
But I do not want to use JSR 168/268 portlet specifications and a portlet container.
The reason is: My web app is a product which can be installed on the client's server (it can be weblogic/websphere/tomcat).
Packing the portlets container along with my application to be installed on clients web server is just too much.
Besides, there are a lot of features this technology offers which I don't need. Actually, all I need is the porlets look and feel (dragable and customizable windows,adding and removing windows and so on).
I know there is also the possibility to do it with client technology (like jquery) and that is cool, but I would like to know if there is any kind of java technology out there which will also give me that.
So, if you know something like a struts or a spring-mvc component library which does this job or maybe a third party product, I would like to know.
If you think my whole approach is wrong I would also like to know that.
Take a look at gwtportlets. From their site;
GWT Portlets is a free open source web
framework for building GWT (Google Web
Toolkit) applications. It defines a
very simple & productive, yet powerful
programming model to build good
looking, modular GWT applications.
The programming model is somewhat
similar to writing JSR168 portlets for
a portal server (Liferay, JBoss Portal
etc.). The "portal" is your
application built using the GWT
Portlets framework as a library.
Application functionality is developed
as loosely coupled Portlets each with
an optional server side DataProvider.
Take a look at the demo here
Another suggestion would be JSF 2.0 which provide AJAX support for updating part of the HTML-page out of the box.
Have a look at this series to get an idea of the possibilities:
http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html