Seth Ladd's Blog

Hong Zhang's Blog mentions that java.net is now hosting J2EE applications for free through LocalWeb . Here's the quote that scares me: > The actual deployment of an application is done by a small team of engineers from Sun. Yikes. Even with all the deployment descriptors, it takes "a small team" to host and deploy a single J2EE application. There's something wrong with that. I've always said that deploying Java applications is Java's Achilles Heel. The LAMP community mocks Java not necessarily because the language is more verbose, but because it's so dang hard to deploy the applications. Compare with PHP, which is as easy as editing the file and then hitting reload in your browser. That's nearly impossible with a full J2EE application. So many libraries have memory leaks that play havoc with classloaders that a full application server restart is required. In any case, this is one of the main reasons I've been moving to Rails. I ca...

JSR 175, JBoss and AOP Some of the themes echoed by Spring will by found elsewhere. The idea of the container providing services via AOP is gaining ground. Here is a brief example of JBoss 4 and it's AOP handling. Note that Spring can also handle transaction management declared as metadata right now, though not through xdoclet (spring uses some commons functionality for reading javadocs). Spring also handles txn declared in the spring configuration. VERY cool stuff. J2EE without the EJB!!

Role Fragmentation - Software Reality One of the consequences of J2EE's deployment strategy is that developers can be seen staring aimlessly around the room for 5 minutes, or wandering off for cups of tea after changing a line of code and waiting for their EJBs to rebuild and redeploy. I've never drunk so much tea in my life; programming has started to become a background task. I now know what it felt like to punch programs into cards and wait my turn in the queue for the mainframe. In thirty years we've gone from computer tapes to red tape. This site is so bitter, but often they have excellent points.

Core Developers Network After a longer and more difficult process than expected, the 2.4 version of the Servlet Specification has been completed by JSR-154 and is due for release before the end of 2003. The aims of this revision of the specification were some modest feature enhancements, improved deployment descriptors and general clarifications of existing functionality. These aims, with some notable exceptions have largely been met. This article reviews the most important additions, changes, omissions and remaining problems in the specification. The key new features are introduced and some explanations are given for those that are missing in action. Problem areas that remain in the specification and those that have newly been added are also discussed.

ONJava.com: JSP 2.0: The New Deal, Part 1 [Nov. 05, 2003] The wait is almost over: the latest version of the JavaServer Pages (JSP)specification, JSP 2.0, is about to be released, along with all of the other J2EE 1.4 specifications. The jump to a new major revision for this JSP version signifies that all of the pieces are now in place for using JSP in a new way: there's no need for Java in the pages, thanks to the new Expression Language (EL) and the JSP Standard Tag Library (JSTL), and reusing code is much easier, thanks to two new ways to develop custom actions. I like the expression language. Having used it in the past, I can say it reminds me of using a scripting language. And that's what this is all leading to anyway: using a high level easy scripting language to develop web sites.

Software Reality - EJB's 101 Damnations Whilst writing the EJB modules for our JGenerator product, we started punting an email back and forth containing all the issues we had with EJB. And there were many. Before we knew it we ended up with 101 howlers. This is an old document, one that I just dug up. Some of the points are valid, some less. But it all adds up to one thing: EJBs are often used as the wrong solution.

Jakarta-Taglibs: Input Tag library The "input" tag extension library lets you present HTML elements that are tied to the ServletRequest that caused the current JSP page to run, or to a JavaBean. That is, using this library, you can easily prepopulate form elements with prior values that the user has chosen -- or with default values for the first time a user hits a web page. This is useful when you need to present the same page to the user several times (e.g., for server-side validation). This is to help me in my quest to find replacements for the pieces of Struts that I like in an effort to move away from Struts.