It's been years since I've worked with Java EE in any meaningful way. Back then it was called J2EE and my application server of choice was Resin because it was blazingly fast and allowed me to bypass all the J2EE crud --like EJBs, deployment descriptors, war files, ear files, etc-- and just get stuff done. Truth be told, I've always disliked J2EE. It just always smacked of self important (read as, Sun/Scott McNeally) bullshit to me. Sun and their "partners" (BEA, IBM, and others) managed to turn something as simple as serving dynamic content over HTTP into a multi billion dollar application server industry that hoodwinked a lot of people.
I made a conscious decision to avoid J2EE like raw broccoli when Caucho started transitioning from Resin 2 to 3. The transition was an abomination of galactic proportions. They completely redid the configuration system and did not provided any tools to move from the old version to the new one. And to guarantee that migration was a herculean effort, they provided documentation that was grossly incomplete and mostly inaccurate. But they didn't stop there. They were just warming up. The 3.0 release was beta quality software at best but was billed as production ready. The word went out that development on the Resin 2 branch had stopped and all development effort was going to be on 3. So any existing open issues (bug reports) against 2 was null and void and would be addressed in the 3 release. That may sound reasonable but it presupposes that 3 is usable in a production capacity. It wasn't. I spent weeks chasing deadlocks and other concurrency issues in the Resin code. So if you were a user that was affected by Resin 2 bugs you were asked to move to Resin 3 and since Resin 3 had even more bugs you were just fuc*ed. The final insult was, while Resin 2 made the J2EE stuff optional Resin 3 made it mandatory. I gave up on Resin 3 and went live with the 2.1.x and never looked back. That was over 3 years ago.
I recently started dabbling w/ J2EE again in a limited capacity. I needed to provide an HTTP interface to a server application I am working on and there was no way in hell I was going to try to climb the whole J2EE mountain just to provide HTTP access to the app. The simplest way I found to provide HTTP support was to embed Jetty and the simplest way to hook into Jetty's HTTP engine is via the Servlet interface. So though I'm using a servlet I really don't consider it J2EE.
As I said before, it's been approximately 3 years since I deployed my last J2EE app on Resin 2.1.x and they have just come due for upgrading. So the quest has been on to find an application server to replace Resin 2.1.x. Don't worry. This isn't going to turn into some long winded diatribe about all the application servers on the market and their pros and cons and yada yada yada. The truth of the matter is I've only tried one. Glassfish. I downloaded it yesterday minutes after 8PM and installed it at around the same time. My first impression can be summed up in one word, Wow!
The installation and startup was an absolute breeze. No config files in sight. The web based admin interface is simple and intuitive. I have yet to click on the help button for clarification on anything. There is also a command line interface that does everything the web based interface does. This is extremely cool because it means configuration becomes scriptable and thus can be completely automated.
There were only 3 pain points in my journey from getting the software to deploying a test servlet (that tests database connectivity). The first pain point was setting up the connection pool for the database. The JDBC drivers for PostgreSQL isn't bundled with Glassfish. The reason it's a pain point is because the configuration screen listed PostgreSQL as one of it's supported databases. It even prepopulates the Datasource Classname field with the correct PostgreSQL specific classname. So as a n00b, seeing all this, my default assumption is Glassfish comes with everything needed to communicate with the database. After a bit of head banging I finally turned to Google where I learned that I simply needed to copy the PostgreSQL JDBC driver to ${INSTALL_DIR}/domains/domain1/lib and restart the server.
The second pain point is not a Glassfish pain point but an IDE one. I've been using IntelliJ+IDEA for years --I'm using IDEA 7-- and this was the first time I've tried to use it's J2EE facilities. Pretty slick! Granted, my previous experience with this kind of thing is limited to emacs and nano on a Resin config file, so IDEA 7 to me, represents a major leap forward. I mentioned my bias because if this sort of thing is your day to day shtick, I hear Netbeans 6 provides an even better experience than IDEA 7 for Glassfish integration.
The first problem I ran into is understanding the difference between the local and remote configuration. It turns out local means IDEA manages the actual running of the application server. So if you already have it running, like I did, then local can't work with it. If you don't want IDEA to manage the running of the application server you have to use the remote configuration option. Remote seems limited to deployment only.
The third pain point is also an IDE one. This time I couldn't get deployment to work. This one actually pissed me off because the failure was silent on the part of IDEA. Without error messages how the hell am I supposed to know what's wrong? Fortunately, Glassfish is not the silent type. I nuked the Glassfish logs and restarted everything. After the deployment failed yet again I checked the log. This time there was a line in the log about a failed login attempt by the admin user. Finally, a clue. When I configured IDEA to work with Glassfish it prepopulated the username and password fields. My assumption was it was grabbing the data from the same place that Glassfish stores it. Wrong! The other clue was the number of asterisks in the password field was longer than the length of the new password --I changed the password from the default during the intial configuration of Glassfish--. Obviously, the problem was the password that IDEA was using was wrong. I manually entered the correct password and that solved the problem.
Other than those 3 minor issues IDEA+Glassfish has been a pleasure to use. I just hope Glassfish's performance lives up to the hype
No comments:
Post a Comment