Raible Designs

Hibernate's AdminApp - a demo of WW2 and Hibernate

After looking at Hibernate's AdminApp, as well as other WW2 apps - I've noticed something. WW2 developers don't seem to give a rats ass about referencing their POJOs in their Actions, or using Hibernate directly in their actions. At first glance, I think to myself, "boy that sure makes things easier." But then again - doesn't that tightly couple your web layer to your persistence layer?

I can understand the POJO reference in Actions - I'm about to give up on doing a parent/child relationship with Hibernate where the children are converted to ActionForms and then converted back (Hibernate loves to tell me "a different object with the same identifier value was already associated with the session: 1").

It would be SO much easier (with this particular problem) if I could just toss up POJOs to my view. The thought of importing "persistence.User" into my Action makes me cringe though. I don't know why, it just does. I need to get out of this patterns mindset I've been in for the last couple of years and get back to what really matters - simple, easy to learn, and fast to develop. I'm tired of banging my head against the wall with Struts and Hibernate.... I've been doing it for two days. It's not Hibernate, and it's not Struts, it's me... (thud, thud, thud).

Yet Another Web Application Framework: Shocks

From watching the struts-dev mailing list, I discovered a new Servlet Framework called Shocks. The thing that interests me about this framework is that the author looked extensively at Struts and WebWork both before creating it. It's feature-set sounds nice too:

It has an aspect-oriented workflow engine that can add crosscutting
system logic (like form processing, L10N, security, logging, etc) dynamically at
runtime (without having to mess around with the bytecode).  It can trade actions
across classloader boundaries, enabling web applications to span across multiple
.WAR files.  This allows users to drop in a new .WAR with new metadata and new
actions, which updates the application workflow at runtime across all modules in
the application namespace.  It handles workflow versioning and version rollback
(in case you make changes you come to regret).  It does instance pooling of all
components and sequences.  Every aspect of the system can be managed with JMX at
runtime.

Sounds like Spring, eh? Yes, says the author.

I think there are appreciable differences that have yet to be realized between 
the two (I haven't read their code at all), but definitely a lot of conceptual 
crossover.

I would think that introducing a new framework into the mix (and convincing folks to use it) must be pretty tough at this point, unless you create an IDE to go with it or introduce it in a book. BTW, did you know you can use Tiles with Spring.

The good ol' Struts vs. WebWork Debate

Jason Carreira has been nice enough to post a technical comparison of Struts vs. WebWork. Don Brown (creator of many Struts add-on packages) and Jason have been going at it ever since. It's funny, there's a small part of me that doesn't believe there's a future for Struts (because of JSF). I believe that JSF and WebWork are quite similar, and if I'm going to take the time to learn a new framework, I should learn JSF. Why? Because, I'm willing to bet the literature for Struts -> JSF is out there, and there's probably no literature for Struts -> WebWork. Also, I believe there will be JSF jobs in the near future, but not many opportunities for WebWork. In a perfect world, I'd do something like Kris is doing and learn them all - extend AppFuse to support my favorite framework (if I find one better than Struts) after the learning process, and use that for new projects.

Where does Kris find the time to learn all these frameworks? I barely have enough time to workout and complete my 8-hours-per-day of productivity-for-pay. Then again, I've been getting up around 7:30-8:00 a lot lately vs. the usual 4 a.m.

In my current gig, I'm teaching a fellow programmer how to write webapps in Java. He's never written Java, HTML, CSS or JavaScript. He wants a tool to do it all - so he can drag-n-drop, point-n-click and voila - he's created a webapp. This is a fundamental problem with J2EE - it's not possible? Or maybe it's the beauty - you have to get down and dirty with the code to create a webapp. Another issue is that we're using Struts Resume as our baseline and architecture - and there's really nothing in this app that's drag-n-drop or tools-friendly. Everything is Ant, JUnit, Struts and Hibernate. You have to be somewhat familiar with all of these to build/deploy this app. Personally, I like getting down-n-dirty with the code, but that's because I'm familiar with it and have been working with it for years. Teaching someone else how to get down-n-dirty (and to like it) is proving to be a whole other battle.

AppFuse and all it's libraries

I received a question about AppFuse that I've been pondering every since. The question basically boils down to two things:

• How do you manage Eclipse's .classpath file in conjunction with lib.properties (the file that manages it for Ant)?
• When using AppFuse for multiple projects, do you put a "lib" folder in each project or use a central repository?

Quick Answers: I replace files in the appfuse/lib directory and update lib.properties. Then I update my project properties in Eclipse to reference the new jars. A pain, yes - but only a 2 minute process. I run all my tests before I bother changing the Eclipse classpath. As for multiple projects - the easiest thing to do is to move $yourProject/lib to a folder called "libs" in the same directory as $yourProject and change the ${lib.dir} property in properties.xml to point to the new folder.

Begins Rambling... I'm currently using AppFuse on 3 different projects. 1 is AppFuse itself, the 2nd is Struts Resume, and the third is for a client I created a webapp for in August. Right now, when I synch up Struts Resume with AppFuse, I copy paste from appfuse/lib to struts-resume/lib and update the lib.properties appropriately. I can't just copy lib.properties to struts-resume/lib because struts-resume uses libraries that appfuse doesn't. Yes, this is admittedly a pain in the arse. It's almost as bad as changing all the method signatures when moving the Hibernate Session from all method signatures into the constructors (can your IDE do that?!). I don't want to make people download appfuse to build struts-resume though, so I doubt I'll change this process.

The whole "massive lib folder" has been bouncing around in my head for quite some time. I'd like to use Maven or Greebo to download the dependencies for AppFuse, but at the same time, it's nice being able to download the whole thing at once and be up and running. I don't want to go the Maven route because I don't really want/need a website for AppFuse and it sounds tough to get it working with XDoclet (though WebShop looks like it might be a good template). KISS

The project.xml in AppFuse is my feeble 20-minute attempt to get it Mavenized (it's currently not used). I tried Greebo this morning, and it really does nothing for me. Especially since I've setup separate compile/test classpaths (read from lib.properties). It'd be a real pain with Greebo to separate out the classpath's for testing and building - it seems to only support one long classpath. Also, who wants to make their whole best-practices open-source app dependent on a 0.1 open-source app?

As for having my IDE (wether it be Eclipse or IDEA) reading the classpath from Ant - that would be the sweetest feature of the year! Currently in Eclipse and IDEA, I have to give an absolute path to j2ee.jar since I don't want to distribute it (it's 11 MB). When I switch b/w OS X and WinXP, I always have to change this classpath. I'm sure there's an easier way with setting variables in the IDE, I just haven't figured it out yet.

The other thing that is annoying is that IDEA doesn't seem to read my $ANT_HOME environment variable. Does it have it's own $ANT_HOME? It's annoying for me b/c I check for JUnit classes in the classpath in my "init" task, and IDEA doesn't find them. Don't worry Eclipse bashers - it doesn't work in Eclipse either. This is fine with me b/c I prefer the command line, but those "I use my IDE for everything" folks might not like it because they can't run AppFuse's build.xml file from w/in their IDE.

Web Frameworks - which one should I learn?

I've seen a lot of talk about Web Frameworks these last couple of weeks - particularly JavaServer Faces, WebWork and Spring. There's also been great articles posted comparing Spring and WebWork as well as an Introduction to Spring from TSS. Spring, WebWork and JSF all look like excellent frameworks to me, but I also continue to believe that Struts is a great framework. And I would go so far as to say that it's the best web application framework. Yep, I said it - Struts is the best web application framework to learn if you are a web developer wondering what to learn. Why? Because it will get you a job.

I've continued to receive a fair amount of calls and e-mails over the last couple of weeks - and they're all calling because of my Struts experience. Good luck in finding a company that wants you to build their web application using WebWork or Spring. Maybe someday I'll be lucky enough to hire employees for Raible Designs and build web applications in my own office with my own employees. Then we'll get to choose whatever technology we want to build customers' apps. Until then, I'll stick with Struts and continue to be an employed developer.

I strongly believe the best way to learn anything is to get paid to do it. I've learned Struts over the past couple of years, not because I wanted to, but because someone else wanted me to - and they paid me to do it. Of course, there are some companies that will probably pay you to learn WebWork or Spring, but most would rather not.

Another thing to consider is that WW and Spring will probably someday develop "migrating from Struts" documentation. Sounds like a good idea to me - until then, and until someone pays me to learn the others, Struts is #1 for me.

Now it's your turn to tell me why my logic is flawed... if you can. ;-)

Skinning your applications and Apache+Tomcat on RH9

Here are a couple of links I found on mailing lists that might be of use:

• Xkins: Xkins framework uses Velocity to process snippets of HTML, but you can use any other template processor (Xkins comes with it's own default processor). Xkins also comes with Forms Tag Libs, that allows you to create forms using Xkins and comes with four Skins. Xkins Forms integrates with Struts framework. Xkins also fits perfect in JSF world, playing a role as a RenderKit, and can work with other presentation frameworks, (i.e. struts-layout).I'll stick with simple XHTML and CSS. If I need different layouts (HTML), I'll use a different base tile.
• John Turner has published a Tomcat 4.1.27 + Apache 2.0.47 HowTo. This is similar to mine, but looks much cleaner and to the point.

Later: I discovered the beauty of John's HowTo this evening. It allows you to specify one measly line in Apache's httpd.conf file and only a few lines in Tomcat's server.xml file and viola Tomcat configures itself! It sets up aliases and such for each webapp that you have deployed. As an example, here's dynamically created section for AppFuse:

#################### localhost:/appfuse ####################                                       
                                                                                                       
# Static files                                                                                     
Alias /appfuse "/opt/dev/tools/jakarta-tomcat-4.1.27/webapps/appfuse"                              
                                                                                                       
<Directory "/opt/dev/tools/jakarta-tomcat-4.1.27/webapps/appfuse">                         
    Options Indexes FollowSymLinks                                                                 
    DirectoryIndex index.jsp                                                                       
</Directory>                                                                                  

# Deny direct access to WEB-INF and META-INF                                                       
#                                                                                                  
<Location "/appfuse/WEB-INF/*">                                                                 
    AllowOverride None                                                                             
    deny from all                                                                                  
</Location>                                                                                 
                                                                                                       
<Location "/appfuse/META-INF/*">                                                              
    AllowOverride None                                                                             
    deny from all                                                                                  
</Location>                                                                                   
                                                                                                       
JkMount /appfuse/j_security_check  ajp13                                                           
JkMount /appfuse/auth/*  ajp13                                                                     
JkMount /appfuse/register/*  ajp13                                                                 
JkMount /appfuse/passwordHint/*  ajp13                                                             
JkMount /appfuse/*.do  ajp13                                                                       
JkMount /appfuse/*.jsp  ajp13                                  

I had all of this working great - I even had Apache upgraded to 2.0.47 on OS X (serving localhost/~user files and everything)! And then I rebooted... Now in catalina.out, I'm getting the following - ugh...

BAD packet 256                                                                                      
In: : [B@c283b5 4/843                                                                               
01 00 03 47 00 00 00 00 00 00 00 00 00 00 00 00  | ...G............                                 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 

WTF?!

Solved: I got this solved fairly easily. I had modified /usr/sbin/apachectl so that the HTTPD variable pointed to /usr/local/apache2/bin/httpd rather than /usr/sbin/httpd. I fixed it by removing /usr/bin/apachectl and executing "ln -s /usr/local/apache2/bin/apachectl /usr/sbin/apachectl". Now if I could only get the Rendezvous mod working on 2.0.x.

WebWork and JDD

I attended the Boulder Frameworks meeting tonight on WebWork, followed by the Boulder JUG meeting. The WebWork (a.k.a. WW) presentation had a mere 5 attendees, but Kris gave a very good overview of WW and showed how simple it was. Here are some of the strengths of WW according to Kris:

• It's not dependent on J2EE. Many method signatures are empty and it uses interfaces everywhere, rather than parent classes. Sounds cool. Kris likes it because "it gives you a warm fuzzy feeling you're not tied to WW."
• It's not Jakarta. "Jakarta is like a Ketchup bottle - you have to beat it to get anything out of it." I don't know that the WW team produces software much faster than Jakarta though...
• Instead of using the HttpServletRequest, WW uses a Stack, which is essentially the same thing (sans J2EE).
• WebWork has Interceptors. They're like Filters, but WW comes with built-in Interceptors that can be applied declaratively. Kris mentioned there's little documentation on the built-in Interceptors - a wiki page would be nice.
• Action packaging - you can turn a portion of your WW application into a jar and it can be added to another WW application. It sounds good, but I can't think of a use for it right now. Sounds like modules in Struts.

Kris's biggest reasons for liking WW was Interceptors and Inversion of Control. However, Struts has those too. Good presentation. I plan to learn WW and give up this whole my framework is better than yours stance. In fact, I hope to do this with many of the technologies I use everyday. I'm going to start using Orion and Resin so I know if Tomcat really is better, or better yet - when should I use one appserver or the other. I'm learning IDEA so I know when to use Eclipse and when to use IDEA. Today I discovered how IDEA warns me about invalid Javadocs (very nice feature). Eclipse continues to rule the CVS integration world, and I see no reason to quit using it and bitch about IDEA's lack of CVS integration.

After WW, I walked across the hall to listen to James Duncan Davidson talk about "James Driven Development" (my phrase) - also known as Objective Object Orientation. Rather than bore you with the details, here are the highlights:

• Don't abstract too much - just enough to fit your needs. Examples of too much abstraction can be found in Apache's Repositories (James's words - he didn't specify any projects).
• Don't extend, instead create objects do something, then you don't need to know the interworkings of the object.
• Dynamically typed languages rock (i.e. Smalltalk, Ruby, Python). They're much easier to develop with, especially when backed my TDD. You can accomplish similar things in Java using lots of casting.
• He can't wait until something comes along and kills Ant and Tomcat - he never thought they'd make it this far - especially considering he wrote them when he was a Junior Programmer for Sun. He gave Tomcat its name because he thought it'd be good animal on the book cover of an O'Reilly book. He never thought it would happen, and now that it does have a book, he said he's disappointed it's not an actual Tomcat (apparently it's a snow leopard?).

His point about Ant and Tomcat is that 1) something better than Ant will rock, so we should all be happy when something better comes along and 2) Tomcat was never designed (or tested) to be used in the environments its being used in (i.e. Nuclear Facilities). Good stuff - brain is full.

JSF and Apache Axis at DJUG

I attended tonight's DJUG Meeting. The meeting was informative and well attended, but it was way too long. I just got home and it's a bit after 11:00. To put it in perspective, I arrived at 6:00. That's 4 1/2 hours of Java love. Elections contributed to the delay, as well as David Geary's 2 1/2 hour JSF presentation.

The basic concepts meeting covered Apache Axis, presented by Scott Davis. He showed us how easy it was to use Axis to create a web service and how to call it from the command line. The biggest highlight of his presentation (for me) was Keynote - his presentation software. It had wicked transitions and the slides looked awesome (good purchase Scott). Other cool software noted during Scott's preso was CodeTek's Virtual Desktop.

Next up was David Geary for a presentation on JSF. This guy has quite a resume: worked for Sun from 1994-97, member of the JSF and JSTL Expert Groups, author of 6 books, designed and implemented the Struts Template library (2nd committer to Struts after Craig). Books coming soon from David: Core JavaServer Faces, Core Rave, and Extreme Struts. Extreme Struts sounds very much like the Struts chapter I wrote for Pro JSP - XDoclet, StrutsTestCase, JUnit, Tiles and Validator. If you're looking for documentation on AppFuse or Struts-Resume, you'll find it in this book. If you don't remember, I wrote these apps for my chapters.

Most folks reading this blog probably know what JSF is. If you don't, it's a Java-based framework for building web applications. It is designed to replace Struts, but that probably won't happen until well after it's 1.0 release (March, Beta in December). JSF was also written to compete with .NET's WebForms, kinda like how JSP was developed to compete with ASP.

Sun's Project Rave is what supposedly will make JSF easy. Can Rave really be that much better than Eclipse or IDEA? Good luck Sun, those are two killer IDEs that are going to be very difficult to beat. And besides, has Sun ever produced any good applications? iPlanet sucks, so does Forte - comparing both to the other options out there.

I could go on and on about what I learned at this presentation, so let me just give you a brief synopsis. JSF generates JavaScript for you for event handling. The JSP tags are long and ugly, but they're named this way (i.e. <h:selectone_menu>) to distinguish a component (selectone) from a renderer (menu). David said he complained about this immensely when he joined the Expert Group, but now sees the point. No XML attributes are used in faces-config.xml - it's all entities. Reminds me of web.xml, lots of typing for not much information (what a pain - today's tool suck at deployment descriptors). JSF has no client-side validation - looks like Commons Validator will be around for quite some time. Especially since JSF requires you to specify your validation after each component in the JSP (vs. declaratively using the Validator). JSF EA4 does not work with Tiles - they're working vigorously to fix this. You can specify your navigation-rules separate from you actions in faces-config.xml (very cool feature).

If you know JSPs and Servlets, it's much easier to learn Struts (and presumably other webapp frameworks). If you know Swing, it'll be much easier to learn JSF. To me, this seems wrong. Some of the examples given tonight had HTML in .java files (for custom renderers). Are we reverting back to Servlets? Is Sun making a mistake with JSF? How is it better than WebWork or Struts? It seems to me to be an over-designed product developed by a bunch of Swing addicts.

My first impression of JSF is that it's going to be harder to teach to newbies (vs. Struts). Everyone says it's a standard so the tools vendors will come through and make it easy. The tools vendors haven't done shit for JSP and JSTL IMO, so how is JSF different? It's a good idea, it just needs to be simplified - a lot. KISS.

What's the best way to test Tag Libraries?

I know of two tag libraries that are in dire need of unit tests - the displaytag and struts-menu. Both have no tests. I've looked briefly at TagUnit, but aren't you just writing JSPs (with custom tags) to test JSPs? I'd rather have an Ant/JUnit driven solution. Also, are there HTML versions of the user guides for TagUnit (Simon ;-)? I hate PDFs.

So my question is - how do you test your tag libraries?

JSF: Allows WebWork style Actions

Am I working too late or does JSF allow a WebWork style Action? According to this post, you can have your properties and your logic in the same class (like WebWork). Also, no more worrying about BeanUtils.copyProperties()?

Struts encourages you to use Strings for field values that might need conversion, in order to redisplay correctly in case of conversion errors. You don't need to worry about that with JavaServer Faces, because the redisplay is handled by the components themselves. You will generally use the native data types for your field properties.

Regardless of what the WW Developers say, I think I'm gonna dig Java Server Faces.