January 22, 2004
J2EE done right
I've got a new work project, and I'm pretty excited about it. We are to build a J2EE web application. We've got a few of these floating around, but this one is to be done from scratch, and it's been made clear that it's to be done right - no cutting of corners whatsoever.
Music to my ears. ;-)
Our existing projects all either date from back when we really didn't know what we were doing, or are based on them. Our unit tests are patchy at best, our build files are nasty shell scripts with the odd Python script thrown in, deployment is totally manual, wheel-reinvention is rife, you name it. Everything works, but you wouldn't want to start from here.
Not this time.
The toolset I'm thinking of recommending:
You'll note that I'm shooting for current best practice rather than cutting edge here; hence Ant rather than Maven, Struts rather than WebWork, for example. Is there anything that should be on this list that isn't? Anything that is on the list that shouldn't be?
Posted to Java by Simon Brunning at January 22, 2004 11:48 AM
Maven is horrible, and used incorrectly by most people, so jsut Ant is a good choice. If its a simple project and you alreadyknow Struts, then that sounds fine - if you are going tobe learning struts then consider looking at webwork first. I'd be interested in seeing how you get on with hibernate - I love it and have been waiting to use it in a real world project for a while.
I'd suggest the use of XDoclet for generating your hibernate config - there is a good tutorial on this at hibernate's site.
You may also want to consider using an IoC container for setting up your services.
In fact, it looks like Hibernate might be overkill too; our data storage needs are totally trivial. We'll be extensivly querying an existing database, but in terms if new data that we need to store, even an RDBMS is overkill really. A serialised hashtable would probably be adequate! (But as a database bigot, I'll suggest that we use one anyway.)
These projects do have a way of spreading however...if you are going to use raw JDBC calls, consider using the Data Access Object pattern, using an Abstract data mapper object to create your objects. Initially you can use a JDBC implementation, then move to a hibernate implementation later on - using IoC to change with concrete implementation you use will make the transition seemless.
If you are doing lots of querying, Hibernate may help you with its built in caching (it supports plugiable caching mechanims in fact so can use OSCache if you want). Raw JDBC is fast (and hibernate is not much slower) put quering an in memory cache is faster still. If you have to code your own caches to get acceptable performances the fact that Hibernate does it for free might make it a better choice.
I prefer Resin over Tomcat, but I don't think it's free for commercial use.
Tomcat let me down too many times by changing its config file formats every single time I upgraded.
I had some trouble converting from Tomcat 4.0 to 4.1, but it turns out that it's 'cos lots of dangerous features were turned on by default in 4.0, but not in 4.1 - the 'invoker' for example. So, once over the pain, this is probably A Good Thing.
Enjoy. Its about time you got some proper work done.
Of course, the question with J2EE is just which bunch of acronyms and patterns you are going to use ;-)
Go DAO. It just works (tm). Hibernate seems to be a good choice for ORM if your data objects need to be slightly more complex than just plain value objects. As for EJBs - run like the wind.
Tomcat 4.1 works for me mate. Oh, and don't forget good old Apache (2, natch) for serving up your static content.
[ This comment bought to you by my shiny new Mac ]
It sounds like you need AppFuse (http://raibledesigns.com/appfuse). It's got all your desired technologies in it and it already has the directory structure/build.xml file to get you up and running quickly.
Good list. I would say that Hibernate is a good choice even if your data access is trivial. It is still nice to map your objects once, and have all the basic CRUD statements generated. Once you get your source good "XDocletized", this is absolutely a time saver. And when/if you introduce more complex O/R things (relationships, lazy-loading, caching, inheritence, etc), Hibernate is already integrated.
As for Struts - I'm not a big fan. I think it the industry standard by default. I was around before any other framework was. Maybe look at WebWork. I have been quite pleased with Spring's web framework.
Good luck. Always nice to start on a green field project!
If you think Struts is a bit of overkill, alternatives like Webwork and Spring are also. Try Maverick. It's realy lightweight, it does MVC, nothing more, nothing less. It's easy to learn and practical to use.
Tomcat is OK - but do a quick evaluation of Jetty as well. It's fast, easy to configure and suits development very well.
Also - Orion is free for development, and has an excellent servlet container.
Are you proposing any standard logging library? log4j or commons-logging perhaps?
Seems like projects typically morph into needing a database at some point. (or they die) I would put in something like hsqldb that is super easy to use and fills your short term needs just fine.
Ok, are you going to use notepad, wordpad or vi as editor :-) ?
I think that you haven't forgot the IDE!
If you want something for free, Eclipse is one good choice; with 30$-year-licence, MyEclipse is better.
*I* will be using Eclipse and jEdit, but the choice of IDE and text editor should be left to the individual developer, IMHO. I certainly wouldn't want anyone telling *me* which editor to use!
Hmmm, logging, good point.
We'll stick with Tomcat for development at least - we know it, and it is definitive.
I think the technologies your suggesting are all very good and quite stable.
You might want to include a continous integration tool such as CruiseControl. Httpunit is also a good extension to JUnit for testing client side functionality. Hibernate is a good tool but might be overkill if you don't plan on creating many data access objects. I would also include velocity as one of the tools. If you combine this with a simple xml you can generate all your DAO objects quite easily. Strongly suggest you look at XDoclet if there is any metadata structure to the application. A logger is also recommended, Jakarta commons logging is very good. I'm a big fan of AspectJ, it might be worthwhile taking a look and evaluating it's advantages/disadvantages for your project.
Take a look at IntelliJ as well, although not directly related to your project I think it's a great IDE with reliable refactoring tools.
I'm happy for you to contact me if you want to know more.
It's not exactly on topic, but I'll second Nelesh's recomendation of IntelliJ IDEA. But only if you're willing to shell out the money.
I suggest you use Hibernate with SpringFramework behind.
DAOs generated using Hibernate, with SpringFramework taking care of the component wiring.
It just works.
You should read this:
Data Access with the Spring Framework
Once you figure out Hibernate the first time, it's actually really easy. You will find that working with the code stays easy and the hard plumbing is done behind the scenes. So it ends up not being overkill once you know how to set things up. Generating the hibernate config from xdoclet or directly from a UML model is helpful, too.
I've long since moved away from Struts, and would recommend you do the same. It's definitely overkill for most anything; it makes simple things a lot harder than they should be. I've been using webwork extremely successfully. It is a lot simpler than struts to get running, has (IMHO) much more power, and is a lot easier to maintain. If you really want to keep the web side simple, you might try maverick as someone else suggested, or even better, just use the velocity servlet. It doesn't get much simpler than that. Of course, if you're establishing best practices, I'd recommend using a framework so that you have room to grow and get your feet wet on a simple project, and again, I'd go webwork (2).
For app server, I'd recommend Orion. It's fast, MUCH easier to configure than Tomcat, and you have an upgrade path to Oracle (their app server is built on orion) in case you ever need to go that route to appease higher-ups with lofty-sounding corporate names. I've had trouble with Tomcat over the years, especially with things like data sources. They're a lot harder to get going in Tomcat than they should be.
If you go eclipse for your IDE, I'd HIGHLY recommend MyEclipse. It's the best J2EE environment I've worked with, better than sysdeo and the other free solutions, plus it works with just about any app server and only costs $30.
Go with Log4j, it's most functional, and is very widely used. Commons-logging is sort of the lowest common denominator between log4j and java logging. Don't use it unless you really have a good reason to.
If you really want to do things right, you'll want to do some Continuous Integration. Especially if you have more than a few people on your team. CruiseControl and Anthill are the most popular tools for this at the moment.
I've been using the SpringFramework for the past three months, it is really very good. I've not had the chance yet to implement it in an enterprise environment. As Ricardo has pointed it out, I do strongly suggest you take a look at it and evaluate it's strenghts and weaknesses for your project.
I'm in the same boat as the author... have you decided on anything yet? What have your experiences been?
i thought this best site to learn lot things in java