Sunday, October 28, 2007

No more J2EE webapps

I got my start in my programming career over 7 years ago developing web applications as part of the intranet group for a Fortune 500 company. The group was switching from developing in Haht (I believe back then it was some type of vbscript) to Java (JSPs and Servlets). I joined the group at the moment they switched to Weblogic 5.1, JDK 1.3, and Oracle 8i (I think). It was a fast paced environment as we cranked out one internal application after another. Of course back then I wasn't the best web developer, but by the time I left I felt pretty confident in being able to hold my own (but humble at the same time).

One thing that always stayed the same throughout creating each one of those applications was the ability to rapidly develop them. What do I mean by rapidly develop? To me this means making a change and being able to switch to my browser and verify that change and repeating that hundreds of times a day.

That is how things were when I moved on 5 years later: (change + save + refresh) x 100s. Now it has been around 2 years since I have developed a real web application and for some reason that process has disappeared. For some reason my fellow J2EE developers have come to accept the process of rebuilding and hot deploying or even restarting the application server FOR EVERY CHANGE! Thousands or even millions of minutes are lost everyday by J2EE developers out there producing software like this. And to that I say, not good enough.

Maybe I am missing something; if so please enlighten me by commenting to this post. Take the JBoss Application Server (AS) 4.2.1 for example. I have tried finding better ways to deploy a WAR (exploded or bundled) on JBoss with no luck. The best I can come up with is increasing the JVMs PermSpace for better hot deployment (article), but I am still left with having to rebuild the WAR and copying it over. And sooner or later I have to restart the server. What a waste.

At one time there use to be a really slick maven 1 tomcat plugin made by codeczar.com that supported the ability to tell tomcat where your webapp was, preventing you from having to rebuild and redeploy. It was a huge time saver, but unfortunately this plugin is no longer supported (see here). If you are curious you can still get this plugin here thanks to Google Cache. The documentation has also been copied here.

Where does that leave me? Any language that lets me develop at a fast rate. Even if I lose tons of reusable components. I would imagine the time I save not rebuilding/redeploying more than makes up for reusable components and other goodies J2EE offers. In fact that has been the main reason for my personal quest to learn Grails and Rails. To me these languages offer the ability to deliver faster and cheaper and I believe this article supports that. If I had to start a new web project I would definitely look long and hard at either Grails or Rails.

25 comments:

Kit Plummer said...

James.

Although, my experience with J2EE is next to nil, and my time with webapps is close to the same I do have some thoughts.

First thought, test-driven development(design)? Although, this probably doesn't work for seeing the "visible" effects of a change - everything server side should be done TDD.

Second thought, Eclipse plugin? I know that for a lot of app servers you can instantiate from Eclipse - and even have it restart every time you build.

I'm not sure about other IDEs, but if the app server doesn't have the means for rapid dev-deploy I don't want to see it.

I've seen the same problem in JBI when trying to build a comprehensive application. Because it is truly decoupled we had to restart every node, anytime any component changed. End-to-end testing is always tough...

Anyway, I feel your pain. My gut tells me that unit testing is the way out...but, then I can only imagine how tough this would be for working with a dynamic (won't say web2.0) site.

Jeffrey S. Hair said...

James,

I feel your pain and, in an environment like that, I would be finding other, quicker ways to deploy & test my application.

Developing J2EE apps has not changed since you last developed them. If you make a change to a JSP file (or JSPX if using JSF), there's no need to rebuild & deploy the entire WAR. Deploy the WAR in exploded form and just copy of the JSP/JSPX/JS.

However, if you have made a change to a compiled class or a packaged jar file, then you'll need to either build & redeploy or bounce the application server. Unfortunately, there's no getting around that.

As Kit suggested, there are IDE plugins that you can launch app servers. These can also help with the building, deploying and testing cycle. Depending upon how complicated your application is (watch out for configuration files with substitution values occur during builds), running the application from the plugin may or may not be easy.

Rich said...

Different technologies has various advantages and disadvantages or pain when it comes to testing. I'm not sure that J2EE developers have come to accept it as it's forced on them due to the house keeping required by the server.

The previous posts cover things that I would expound also so I won't reinvent the wheel. The challenge for any project is developing an efficient and effective testing environment and process. Be sure to research available tools and processes to reduce time and increase efficiency. Of course if there is enough pain then you may find a moneymaker in developing a solution to solve the pain where people are willing to pay for it. ;-)

Rob said...

I've developed a few JSP based web apps, a few PHP/MYSQL apps, a few practice Rails apps, and hundreds of Domino web apps (it's been my bread and butter).

Domino is not open source in any way, shape, or form. But because of the comparitively minimal time it takes to develop a production app for the web or the Lotus Notes client or both, mainly due to it's "convention over configuration" approach (the same as Rails) and not having to compile/package/deploy anything, it continues to be my development environment of choice.

If you need a relational database back end, Rails is better because of its ability to handle parent-child records automatically. Domino handles this automatically only in it's hierarchical built in database. And I wouldn't want to store a million records in one of those.

In certain situations, Domino is a good choice with DB2 as the back end, particularly where multiple disparate instances of DB2 exist but use a single instance of business logic / web logic on the front end.

And complex security is a breeze. The closest I've seen is .Net's latest offerings. Alas, Domino's Web 2.0 offerings out of the box are non-existent. IBM expects you to use some other framework plopped on top.

But the core offerings are there and the development community is deep -- see openntf.org and the IBM Lotus Domino forums.

I'm not saying that either Domino or Rails is perfect, but I prefer both over J2EE hands down.

Anonymous said...

I hear ya and I used to complain about this too but then I got a 2GHz Dual Core machine and I don't even notice IntelliJ redploying the app inside tomcat.

But the point is taken, there needs to be a faster way of developing, I'd even settle for smarter IDEs that makeup for the mess that is the Servlet spec.

Anonymous said...

Hey,

JavaRebel is a relatively new piece of software that very nearly eliminates the mind-numbing recompile/deploy/test cycle.

I am pretty sure that after arrival of such first birds, development stage of Java/J2EE application will soon be eliminated for most conceivable cases/environments.

Anonymous said...

I meant to say "_deployment_ stage of Java/J2EE application" of course.

Nirav Thaker said...

While I understand the pain of development in J2EE environment, your IDE can always hot replace the code (with non-structural changes) in a JVM.

Tomcat/JBoss is really developer-breeze imagine hours and hours of waiting for Websphere test environment to come up...

Chrigel said...

well, there are enough hot deployment round trips in grails, so I would suggest to get away from java completely.

grails (or rather groovy), while beeing absolutely brilliant, has the feature of beeing java, which is both its biggest advantage as its biggest disadvantage

Aldrin M said...

JBoss's Seam 2.0 provides some better support for incremental redeployments. Has anyone ever tried something like they have ?

ert said...

I'm OK with business logic being (re)deployed as an archive as you tend to be able to write unit tests with them to test out the correct functionality. However it sucks for doing that for display logic. For conventional web apps I use an eclipse plugin
PiecesOfFlare
which deploys the changed (jsp) file into the (exploded) webapp (on jboss). So I hit control-S and then refresh my browser. Saved me a bunch of time.

--Kurt

Unknown said...

With JBoss you don't even have to copy the JSP from your development environment. You can tell JBoss to look anywhere for the deployments. So just tell JBoss to look at the place where you have your exploded WAR and it will detect changed JSP files without redeploy and without restarting the server.

To see how to set up multiple deployment roots (even across a network) look here:
http://www.jboss.org/wiki/Wiki.jsp?page=ConfiguringTheDeploymentScannerInConfjbossSystem.xml

Stan

Unknown said...

Somehow the above URL got cut off. The rest is:
heDeploymentScannerInConfjbossSystem.xml

jlorenzen said...

Thanks so much for all the excellent feedback.
Stan, I appreciate the link to the jboss wiki. I assume you are referring to adding the following:
<attribute name="URLs">
deploy/
</attribute>

If I point that to my exploded directory I should be good, right?

Unknown said...

Right. You want to declare both the normal deploy directory and your development directory. So it would look something like this:

<attribute name="URLs">
file:/myproject/myWARroot,deploy/
</attribute>

Unknown said...

Oh, if you change class files as opposed to JSP files then you will need to redeploy. At that point, just touch the web.xml and JBoss will redeploy your exploded WAR.

Dimitrios Menounos said...

I have been concerned about the exact same issue. Change -> Save -> Refresh is very important for me too and I have found the solution.

On the machine I develop locally I use Tomcat.
1) I have a web-template project with an Ant script that contains a "deploy-local" target. This has to be executed only once and it will create a CATALINA_HOME/conf/Catalina/localhost/context.xml file with a docBase attribute pointing directly at the project's web directory.
2) Additionally I keep libraries and build java sources directly within project/web/WEB-INF.

These 2 combined do the trick for me.

POJO NUT said...

Yes, as soon as one uses EJB, the deployment time is very noticeable.

Tomcat however on web site development, I cant complain about, on Netbeans anyway.
You see it doesnt deploy it to Tomcat (move the application), Tomcat simply runs the "build" in your project. Because compilation can be done incrimentally, its quick. Leave the browser open, and it plenty quick.

EJB is overly complicated, if you want try something that will cut the whole development time down to a third, look at a POJO Application Server.

You dont even develop the application inside the server ;)
That probably means its as fast as your compiler will run.

Milind Rao said...

Check out MyEclipseIDE. It does EXACTLY what you want and is THE reason why I subscribed to it when I was doing web development.

For the past two years, it's been all Client Java for me so haven't used it in a while.

HTH,
Milind

Anonymous said...

Some people should really try the newer versions of ECLIPSE that's out - the one that comes with the Web Tools Platform. It easy to configure server profiles and when there are changes in the classpath, eclipse will automatically restart tomcat.

spring + (hibernate, or iBatis for legacy stuff), along with wicket really makes stuff easy.

James said...

I agree this pain must be stopped.

You might try the following:

use tomcat sysdeo plugin during dev
which allows
a. no war copies (direct out of workspace)

javarebel from zeroturnaround has been good for me as well.

Anonymous said...

you should rapid-develop your web-application in seaside and port it to java afterwards. writing smalltalk code is a mind-opening experience for most java programmers and since it is so damn easy learn, switching isn't that painful.
since seaside does have "rapid dev-deploy"(as you call it), you might want to see it.

Anonymous said...

i've been too crackbrained to post a proper link...


use this one instead

Anonymous said...

I agree with felix. Have a look at http://www.seaside.st

I was sceptical first since I never heard of Smalltalk. Learning the language was easy (just objects and messages) - but tools are different (no wizards, browsers to manipulate the system). It really rocks.
Unfortuanately many companies want J2EE. If not I would now decide for Seaside instead of Rails.

Anonymous said...

Have you thought about using the Maven Jetty plugin? This allows you to set up "scan intervals" which scans your source code and automatically restarts your app, very quickly for any code change. Any JSP changes are automatically detected without the need to restart the container.

We use this for our development and have found that this reduces development time and frustration by eliminating much of the need to restart the container.