Raible Designs

Another Hibernate Example

Konstantin Priblouda has put together a small demo showing hibernate in action:

• XDoclet generated mappings & service descriptor for JBoss (.sar file) - these were mentioned by Marc Fleury at his presentation. The basically are Service ARchives and allow for pluggability/removeability in JBoss.
• Session bean accessing hibernate.
• Small client.

XDoclet and EJBs

I saw the following on the xdoclet-user mailing list today:

Chapters from Manning's "EJB Cookbook", by Ben Sullins and Mark Whipple will be made available on TheServerSide for public review. A chapter on "Code generation" is now available for download. "Code generation" presents the most common uses of XDoclet, an open source tool, tightly integrated with Ant, that lets you generate source code or other files.

Also, I just received the following e-mail from a fellow Denverite, Mike Clark:

Subject: Nice Blog

Hi Matt!

I've been enjoying reading your blog for a while and meaning to introduce myself since we both live in Denver. I'm speaking at the DJUG in April, so perhaps we can meet each other there.

By the way, my weblog is at: http://www.clarkware.com/cgi/blosxom.

Nice - gotta like e-mails like that!! Apparently, Mike is the Author of BitterEJB and also has some chapters for review at TSS:

If you're into JMS and message-driven beans, my "Bitter Messages" chapter is up for review on TheServerSide. As always, any feedback you might have is greatly appreciated!

How Hot are your Topics?

I noticed the "hot" links over at java.blogs this afternoon. They show who has the most read topics for a particular day - at least on that website. I had 2 of the top 3 yesterday! If that's not motivation for better writing, I don't know what is. But is this really a popularity contest? Are we trying to boost our Google/Java.Blog rankings? Probably not, but it sure won't hurt when you're out looking for a new job!

That being said, I interviewed for a J2EE developer position this morning. The project sounds pretty cool - using Struts, Servlets, JSPs and such to create a web front end to an Oracle database. The guy who interviewed me seemed very smart and would be great to work for - he's chosen J2EE as an architecture and wants to run the production system on Tomcat. Nice! All the stuff I've been working with for the past year and a half. He's probably reading this right now (I sent him the url to my blog), so hopefully this post helps me out. ;-)

Another reason for writing this post is to let you know that there is another open position on this project. Required Skills: HTML, XHTML programming. Any Java/J2EE, LDAP or Apache/Tomcat skills would be a bonus to complement the team. If you're interested and you live in Denver, let me know, and I'll send you the recruiter's e-mail. I believe the contract is for 3-6 months.

Design Patterns, Marc Fleury and JBoss

I just got back from the Denver JUG meeting and have lots to talk about. I've started this post at 11:03 p.m., for the record. I want to start out with discusssing a topic that Dave and I talked about a few days ago. Basically, in his Ag application, he is using one Business Delegate and one DAO to do all his business logic and data access. Actually, he's got two DAO's, one for Hibernate and one for Castor. Basically, the DAO is determined at startup, set on the Business Delegate and then stuffed into the servlet context. While Ag is a small application, it got me thinking. I believe the recommended pattern for this is to have a Business Delegate for each entity, as well as a DAO. So for a user, you would end up with 4 classes, UserManager/UserManagerImpl and UserDAO/UserDAOHibernate. So everytime I add a new entity, i.e. account, I have to create 4 new classes. What a pain, and a lot of copy and pasting - or at least that's how I'd do it.

Dave's KISS methodology at first struck me as strange, but then I thought, "Damn, that's a lot easier." So now in AppFuse (reference implementation: security-example), I changed to use this idea - with a BusinessManager/BusinessManagerImpl and ApplicationDAO/ApplicationDAOImpl. The idea is that these will contain any and all methods to access data.

I went to the DJUG meeting still struggling this this pattern, feeling like it stunk and I should back it out and go with a factory pattern and a business delegate/dao for each entity. However, during Marc Fleury's presentation, he preached that one of the founding rules of JBoss was KISS. He said that the greatest thing about open source is that no one will ever even look at your code until it's broken. "And how bad does it suck when you have to look through 5 levels of inheritence to figure out the problem?" He mentioned that bad code was his favorite, because chances are - if there's a bug - it'll be staring you in the face, rather than buried inside some design patterns and 10 different classes. I agree, so I'm going with KISS, but I'm also interested in hearing your opinions. I like the current architecture of AppFuse because it sets the business manager on startup, stores it in the servlet context and is available for everyone to use at any time. There's nothing saying that I couldn't set a SessionBean (on the business manager as it's proxy) and call EJBs for my persistence layer.

In fact, after Marc's gospel about JBoss, I want to use EJBs. In fact, not just EJBs, I want to use JBoss - and I can't wait for "JB 4." Why? Well they're adding the ability to add all of EJB's services (i.e. Security, Transactions, Persistence) to any POJO. This means that all you need to do is write a little deployment descriptor for it, and whalla, you're in business. His sermon is something you really need to see to appreciate. I can't do it justice in summarizing it here, but I certainly liked what he had to say, and feel like I'm a better person for it. The JBoss Group's goal is to become the de facto standard for application servers. I like their idea that the app server should be free - and the money (usually spent on app servers) should be directed towards smart developers instead. He also mentioned that JBoss Group (the company) is doing great right now and will be spending some cash on Marketing and PR to squash any rumors that it's not good enough.

Marc mentioned that most of the things he talked about tonight are written in his Blue Paper (PDF, 11 pages), titled "Why I love EJBs". It's part 1 of 3, the Blue of the "Red, White and Blue Technology Trilogy."

Other news that I stumbled upon today:

• JBoss uses JavaGroups, and I've heard you can make work with Tomcat - for clustering and such.
• The release plan for Struts 1.1 Beta 3 has been committed to CVS, code freeze this Saturday.
• Ted Husted defends Struts after I posted it's recent criticizm to the mailing list.
• The xPetstore Application has a new release. xPetStore is a refactored version of Sun PetStore application that shows how to use xDoclet to build WODRA (Write Once, Deploy and Run Anywhere) J2EE application. Tested with JBoss and WebLogic.

Phew, done at 11:44 p.m.

Using JAAS and making it switchable

Erik Hatcher has convinced me that I need to give more coverage to JAAS in my chapter on Security. To quote his comment from yesterday's JAAS post:

I think you are underestimating the value of JAAS a fair bit. Suppose you want to authenticate your users against a database table of users/passwords. Without JAAS this is container-specific (sure it works nice in Tomcat, but would you be able to do FORM authentication in WebSphere easily?). We use JAAS in the big application I'm developing and it gives us the freedom to more easily port our application to other containers. What if your application needed to authenticate users (suppose for a portal, not that far fetched, eh?) where each "portlet" had a different authentication scheme: LDAP, Windows NT, database, etc. JAAS is the way to go.

While I can see Erik's point, I think that if the app servers follow the Servlet spec, implementing form-based authentication on any J2EE-compliant server should be easy. After all, Tomcat is the Reference Implementation. At the same time, the bit about the portles is a whole other can of worms - I can see what he's getting at, and I guess I need to figure out an easy way to demonstrate using JAAS. From what I understand, you do have to call the authenticate() in a servlet or filter. Hopefully, I can use a little Ant/XDoclet magic to create a sample that can switch b/w form-based, container-managed authentication and JAAS. Tell me what you think of this idea:

• Use Ant and a task that runs if ${enable.jaas} is true
• This task (i.e. jaas) will add a JAAS policy file to the webapp, maybe in the WEB-INF/classes directory so it's in the classpath
• The jaas task will do some token replacement in login.jsp to change the form's action from j_security_check to something else. Ideally, I wouldn't have to do this.
• The webdoclet task with not merge the web-security.xml file into web.xml
• The ActionFilter, which I currently use to retrieve the user's information, will call the authenticate method and route appropriately if JAAS is enabled.

One thing I really like about form-based authentication (besides the ease of setup and no required programming) is that it allows users to bookmark pages in your app. When they select that bookmark again after logging out, they are prompted for a login and routed to the bookmark upon successful authentication. I hope JAAS can do this too.

Symlinking now works in Tomcat 4.1.16!

The Tomcat developers turned off the ability to create symbolic links (symlinks) in 4.1.x. This really threw a wrench in my ability to upgrade as I use symlinks to point to resources outside my webapp all the time. I don't do it for jars, but for common image or documentation directories. In Tomcat 4.1.12 (the latest release), you were supposed to be able to turn symlinks back on by adding the following to your app's context:

<Resources
  className="org.apache.naming.resources.FileDirContext"
  allowLinking="true" caseSensitive="false" />

The bad news? This didn't work! I'm happy to report that with the lastest 4.1.16 beta, this does work! So, for instance, if you want to turn on symlinks in the ROOT context, add the following to your server.xml:

<Context path="" docBase="ROOT" debug="0">
  <Resources
    className="org.apache.naming.resources.FileDirContext"
    allowLinking="true" caseSensitive="false" />
</Context>

JSP's Evolution

There's another interesting discussion taking place over on the struts-dev list again. Man, I'm glad I subscribed (again) to this list last week! It started out as a discussion of JSP vs. Velocity and Craig (McClanahan) provided an interesting evolution of JSP (and comparison to Velocity).

Velocity:
========

(Note -- it's assumed that the Customer collection has been stored in the
VelocityContext by some preceding business logic.)

  \#foreach $result in $results {
    <tr>
      <td>$result.ID</td>
      <td>$result.Name</td>
    </tr>
  }

JSP 1.1 (with Scriptlets):
=========================

  <%
    Customer custs = ...;
    for (int i=0; i < custs.length; i++) {
  %>
    <tr>
      <td><%= custs[i].getId() %></td>
      <td><%= custs[i].getName() %></td>
    </tr>
  <%
    }
  %>

JSP 1.1 (with custom tags):
==========================
(Note -- it is assumed here and in the following examples that the Customer collection has been stored by some preceding business logic.)

  <logic:iterate id="cust" name="custs">
    <tr>
      <td><jsp:getProperty name="cust" property="id"/></td>
      <td><jsp:getProperty name="cust" property="name"/></td>
    </tr>
  </logic:iterate>

JSP 1.2 + JSTL 1.0:
==================

  <c:forEach var="cust" items="${custs}">
    <tr>
      <td><c:out value="${cust.id}"/></td>
      <td><c:out value="${cust.name}"/></td>
    </tr>
  </c:forEach>

JSP 2.0 + JSTL 1.0:
==================

  <c:forEach var="cust" items="${custs}">
    <tr>
      <td>${cust.id}</td>
      <td>${cust.name}</td>
    </tr>
  </c:forEach>
</pre>

I can't wait for JSP 2.0 - it's going to make everything so much easier. Once again, we have exciting times for the Java world. With the power of JSP 2.0 and XDoclet, deadlines should be a non-issue. Now we just have to figure out the best way to use them, and the fastest way to pump out a Struts project. Wouldn't it be awesome if you you could add a new column to a table, build your project using Ant and XDoclet and whalla, all your classes are updated! That would be cool - and I think it's possible. Now I just have to figure out how - and fast!

The Future of Struts

There's an interesting discussion taking place on the struts-dev mailing list right now. Here's a couple excerpts:

I'd be really interested in your thoughts on the XDoclet work I've done, especially in the Struts Validator realm. I'm generating validation.xml completely, and also all the form bean definitions in our system. I also use XDoclet to process form beans for a one-time starter code generation of a JSP page (templated to our specific look and feel) for a specified form bean, as well as the resource properties that can be used as a starting point for the application resource properties for the field labels. Its amazing amount of generation just on the Struts-side of things, but we use XDoclet for even more than that too. [ Erik Hatcher ]
...
I think it is time to start packaging tools and generators with Struts to help the developer -- either as standalone packages included for convenience, or integrated into the architecture of the package. It would be interesting to explore how XDoclet fits in to this vision. [ Craig McClanahan ]

What exciting times! I can't wait to use XDoclet to generate the validation.xml file for Roller - should be a great learning experience. I don't plan on writing a Struts ActionForm again now that we have XDoclet. Also, I have an update on Roller and XDoclet: Dave found this problem with XDoclet and Castor. It will be fixed in XDoclet 1.2 beta 3. So we wait...

Beautiful Denver Sunset

As I coded past the light of day tonight - I looked out my office window and the front yard and neighbors house was glowing orange. So I leapt out of my chair and scrambled for the back yard. What I saw there was breathtaking. This is one of the best parts about living in Denver, the sunsets are amazing - and we get them a lot! I don't know if it's the pollution or the altitude, but they sure are impressive.

Chimera Gets Faster

If you use Chimera as your web browser on OSX (and there is every reason to) you might be interested in a little speed boost reported recently by MacOSXHints.

It's called HTTP/1.1 Pipelining and you can enable it by adding the following lines to the preferences file ( ~/Library -> Application Support -> Chimera -> Profiles -> default -> [random].slt -> prefs.js ):

user_pref("network.http.pipelining", true); 
user_pref("network.http.proxy.pipelining", true);

There should be a noticeable speed increase, especially news heavy sites such as Slashdot or Metafilter.

{ via xlab via pixelised }

Very cool - my fastest and favorite browser gets even faster! What more could you ask for on a Monday morning?