Blogging Roller

I've been evaluating Dreamweaver MX 6.1 for 16 days now. I downloaded the 30-day trial, so I have 14 more days to figure this out. For a Java web application developer, what is the point of Dreamweaver?

I already have a couple of favorite code/text editors and access to simple Wysiwyg HTML editors like Mozilla Composer and Open Office, so I've got simple HTML editing pretty well covered. What I would like from a high end web application development tool like Dreamweaver is full Wysiwyg support for JSP, for custom JSP form tags like those in Struts, for page templating/layout systems like Struts Tiles, and for CSS-based layouts. So far, Dreamweaver has fallen short:

• Dreamweaver doesn't support Struts (or Webwork, I assume) custom JSP form tags. Sure, Dreamweaver supports custom JSP tags, but support only goes so far. You can use the taglib directive and you can place custom tags on the page, but they show up as invisible elements or tiny icons. So, if you are using the Struts form tags such as <html:form>, <html:text>, and <html:submit> instead of the standard HTML form tags, then your form will not look like a form in Dreamweaver.
• Dreamweaver's support for CSS-based layouts support is a little flakey. Sites that look fine in MS Internet Explorer and Netscape7/Mozilla don't always look quite right in Dreamweaver. If you want to use Dreamweaver to design a site with CSS-based layout, then you are effectively adding a third browser to your support matrix. Not only do you have to make your pages pixel-perfect in IE and Netscape, now you have to please Dreamweaver's HTML renderer as well.
• Site template/layout frameworks like Struts Tiles (or Open Symphony Sitemesh, I assume) don't work well in Dreamweaver. The Struts Tiles tags don't show up in Dreamweaver, so there is no way to view your pages in the Dreamweaver design view.

In addition to HTML editing, Dreamweaver also supports multiple server technologies including JSP, ASP, ASP.NET, PHP, and ColdFusion. I would imagine that developing, maintaining, and supporting a full-featured HTML editor and web application development environment like Dreamweaver is a huge engineering effort. Maybe that explains why JSP support is so shallow.

I hope I am missing something here. If you find Dreamweaver MX useful for JSP development in this age of MVC frameworks like Struts, Webwork, and others, then I'd like to hear from you. Are there any Dreamweaver extensions that solve or help with some of the problems I mentioned above?

If you search for HTML tree control on google, you'll find lots of links for JavaScript-based tree controls. To allow tree expansion/collapse without going server-side, these components require that all tree data is downloaded to the browser. This approach is not suitable for situations where your tree has thousands of items. What I'd like to see is a tree control that keeps the tree data on the server-side and allows you to "page next" and "page prev" paging through multiple pages of tree data for tree nodes that have more than a page-full of children.

Searching for JSP tree control, I happened upon the BEA Weblogic Workshop's JSP tree control tag <a href= "http://edocs.bea.com/workshop/docs81/doc/en/workshop/taglib/www.bea.com/workshop/netui-tags-html-1.0/tree.html"> <netui:tree>. The BEA tree control uses an MVC approach where tree data is held in a server-side model baed on a TreeNode interface; close, but not exactly what I want. The BEA control does not seem to support paging. Are there any open source components similar to the BEA tree control?

James Robertson of the Cincom Smalltalk blog picked up on my post about the final keyword and one of his readers, Blaine Buxton, made an interesting comment on the topic. Software is never perfect, as Blaine says, and I agree, but if you allow your users to customize your software by extending classes and overriding methods, you can get yourself into trouble very quickly. When you deliver a new version of your software to them, you might find that you have broken many of their customizations and enhancements. It takes some thought to write a class that is truly safe for users to extend. An typical object is like a state machine and by calling methods in the wrong order or incorrectly overriding a method, your users can easily put that state machine in a bad state. Open source helps, of course, because users of an open source application or class library can see the internals of the classes and, one hopes, understand how to correctly extend them.

I'm not saying you should never allow users of your class libraries or applications to extend your classes and override your methods, but I think, in general, it is better to provide them with extension points in the form of interfaces that they can implement to extend and customize the behaviour of your library.

Blaine Buxton In this context, it would be more natural thought for a Schemer/Functional programmer. Functional languages frown upon mutable variables because they make "proving the correctness of the code" more difficult. They see variables as you would in mathematics, they never change. Personnally, I forbid the use of final on methods in any projects that I have anything to do with because of the exact problem you explained. Software is never perfect. But, I do advocate using final on variables for constants and that's it. I think trying to turn Java into a functional language (in the sense of Scheme and Haskell) is like trying to make pigs fly. Now, just don't even get me started on the use of the private keyword on methods! My hatred for it is the same as final on methods and you should NEVER do it.

I work with a couple of Programming Languages geeks who are, it seems, always Scheme-ing and Smalltalking behind Java's back. One of these guys has a thing about the final key word. He believes that all fields, variables, classes, arguments, etc. should be final be default and that, instead of having a final keyword to declare immutables, Java should have a mutable keyword to declare those that may be mutated.

He argues that, wherever possible, fields, variables, classes, arguments, etc. should be declared final. Since Java does not default to final, you should default to final. Here are some advantages to this:

• If you declare and initialize a variable final, you never have to worry about it being null later. Nobody can change it, so it will never be null.
• Extending classes that are not carefully designed for extension, and let's face it most are not, is problematic. By mentally defaulting to final classes, you prevent potential problems.
• If you need to declare an anonymous class, you don't need to wory about redeclaring your variables as final because you already declared them that way.
• Other reasons? ...

My coworker is not the only one with the final fetish. Renaud Waldura is a final fan too. Brian Goetz writes that final can simplify your life, but points out that declaring classes or methods final does not make them faster.

I love the way that James Robertson of the Cincom Smalltalk Blog monitors my weblog for material to use against Java, J2EE, and static typing. I'm serious. I learn something everytime he fires a shot from the tower. You can learn a lot from a Smalltalker with an I-told-you-so attitude.

is having to switch back to JSP 1.2 after using JSP 2.0.

I logged into the FreeRoller server for the first time in long time and, on a hunch, I started investigating the OSCache configuration. Turned out, the disk cache directory did not exist. I created the directory and gave it the right write permissions, but OSCache is still not using the disk cache. I'm not sure why. I turned on DEBUG logging for OSCache and I saw the message below, so OSCache clearly knows the location of the cache directory. These settings were good enough for OSCache 1.7.5. What's the deal with 2.0?

INFO HttpProcessor[80][2] com.opensymphony.oscache.base.Config - Properties { 
   cache.debug=false, 
   cache.path=/sites/hosted/freeroller/cache,
   cache.unlimited_disk=false, 
   cache.capacity=600, 
   cache.memory=true
}

I'd like to set cache.unlimited_disk=true and then use a cron job to clear the cache every night, but right now I just want to get the disk cache working. Any ideas?

I've been working feverishly against a Friday deadline, having lots of fun, and learning more than I ever wanted to know about Struts, Hibernate, XDoclet, etc. I'm the closest thing that we have on the project to a Struts expert, so I've had to come up to speed fast on Struts Tiles, Struts Validator, and XDoclet's Struts support. So far, so good, but now I've hit a snag. I've run up against what appears to be a serious Struts Validator limitation: no support for java.math.BigDecimal.

I tried using the double validator, but when I apply the XDoclet tag for the double validator to a field that is a BigDecimal, XDoclet does not generate an entry for the field in validation.xml. Maybe, if I can fix this I can get away with using the double validator. Hmmm...

To resolve this problem the right way, it seems that I'll need to write my own validator. No problem right? I think this involves four steps:

• Provide a class with a validateBigDecimal() method for server-side validation.
• Write the JavaScript for client-side validation.
• Write the XML for my validator and put it in validator-rules.xml.
• Fetch XDoclet from CVS and hack the Struts Validator support to handle my new validator.

That last step is a doozy. There's got to be an easier way, but googling turns up nothing. I guess I have figured out how I will spend my evening.

InfoWorld: Red Hat to ship JOnAS J2EE software - The key question now is whether or not the JOnAS software will become the first open source application server to receive J2EE certification, an expensive process whose price tag has thus far helped prevent the JBoss application server from being certified by Sun.

Wow. First Apache with Geronimo, now Redhat with JOnAS. Whatever happened to The End of Free? I wonder why Redhat chose JOnAS. Did the Fleury vs. Sun antics scare them away from JBoss or was it the LGPL?

Geronimo proposal: There are two main aspects to this Apache project:

• a complete J2EE certified server which is fully ASF/BSD licensed and backed by a healthy open source community.
• to create a fully modular J2EE stack so that the Apache community can use whichever parts of the J2EE stack they require separate from the J2EE server project.

Very cool.

I just tried the new OSCache 2.0-beta2 release and it is quite an improvement over the 1.7.5 release. Wow. Look at these numbers:

Testing Roller 0.9.7.5 with the old OSCache and the new:

Test	Cache-TO	Threads	Loops	Max-Delay	Avg	Med	Dev	T-Put
OSCache175	5/5	20	10	1000ms	4684	1382	8012	138.7/min.
OSCache200	5/5	20	10	1000ms	2237	821	6624	201.4/min.
OSCache175	60/120	20	10	1000ms	2601	1382	3136	186.9/min.
OSCache200	60/120	20	10	1000ms	1680	731	2113	242.9/min.
OSCache200	60/120	20	1000	1000ms	2248	1603	2079	271.5/min.

See Roller0975Throughput for more information on the tests.

It's a nice coincidence that the very week that I have to dig into the Struts Validator, two articles appear by Erik Hatcher on XDoclet and Struts. After reading these articles and browsing Matt Raible's AppFuse project code, I was able to fit the pieces together and get XDoclet to generate the right struts-config.xml and validation.xml entries for my form beans. Below are links to Erik's articles and some other resources I found useful in investigating Struts Validation:

• Erik Hatcher: Form Validation and Action Mapping
• Erik Hatcher: Exploit XDoclet's Struts Capabilities
• Matt Raible: AppFuse project
• <a href= "http://www.raibledesigns.com/page/rd/20030226#struts_validator_validating_two_fields"> Matt Raible: How To Add a TwoFields Validator
• Struts website: Struts Validator Guide
• Chuck Cavaness's Using the Validator Framework with Struts

Seems like everytime I try to use XDoclet, I have to tweak one of the XDoclet template files to work around a bug. This time was no exception. I found that XDoclet would only generate the right entries in struts-config.xml if my form beans extend ActionForm, but to use the Struts Validator, I need my form beans to extend ValidatorForm. The only way I found to get around this problem was to copy struts_config_xml.xdt out of the XDoclet xdoclet-apache-module-1.2b4.jar file and to change the first forAllClasses like so (my change in bold):

  <!-- ========== Form Bean Definitions ============== -->
  <form-beans>

   <XDtClass:forAllClasses type="org.apache.struts.validator.ValidatorForm">
   <XDtClass:forAllClassTags tagName="struts:form" superclasses="false">
    <form-bean
      name="<XDtClass:classTagValue tagName="struts:form" paramName="name"/>"
      type="<XDtClass:fullClassName/>" />
   </XDtClass:forAllClassTags>
  </XDtClass:forAllClasses>

I believe there needs to be one of those forAllClassses loops for each type of form: ActionForm, ValidatorForm, and ValidatorActionForm. This does not appear in the current XDoclet CVS for <a href= "http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xdoclet/xdoclet/modules/apache/src/xdoclet/modules/apache/struts/resources/struts_config_xml.xdt?rev=1.11&content-type=text/vnd.viewcvs-markup"> struts_config_xml.xdt. My chance to get a patch in?

Java World: JSP [document use] XML-compliant include and forward actions, as well as custom tags, so making the entire document XML-compliant leads to increased code consistency.

Jason Carreira: Scaling doesn't have anything to do with whether your objects are remote. How often do you really have one web request cross JVM boundaries? The whole Servlet-tier and Business Object tier topography has been pretty well discredited. It doesn't scale to have to make remote calls.

I've been investigating web application testing tools, both for unit testing of web components such as Struts Actions and for functional testing. I read about JUnit extensions Cactus and HttpUnit in Hightower and Lesieki's book Java Tools for Extreme Programming. I learned about StrutsTestCase and JUnitDoclet from Matt Raible's gold-mine of example Ant code: the AppFuse project. That was enough to get me started.

I put together a simple test app with Cactus and StrutsTestCase and was pleased to find how easy it is to invoke Cactus from an Ant script and have Cactus start Jetty, run my tests within the Jetty, and shutdown Jetty when the tests complete. Cactus is going to make it really easy for us to unit test our Servlets, Filters, JSP pages, and Struts Actions. Cactus uses HttpUnit and HttpUnit makes it easy to make sense out of the responses that come back from the web layer, see the HttpUnit cookbook page for an example if this. I wish I had done this a long time ago, how did I live without this stuff!

So, I'm all set for unit testing. Now I need to figure out what to do for functional testing. HttpUnit, MaxQ, and Canoo look promising. I found the bewilderingly long list of functional testing tools at opensourcetesting.org. What open source or commercial tools have you used for functional testing of web applications?

Slashdot picked up Andy's <a href= "http://linuxintegrators.com/hl30/blog/general/?permalink=LGPL+clarification.html">LGPL is viral for Java story and provoked a response from the Free Software Foundation (FSF):

<a href= "http://developers.slashdot.org/developers/03/07/17/2257224.shtml"> FSF Executive Director, Brad Kuhn LGPL's S. 6 allows you to make new works that link with the LGPL'ed code, and license them any way you see fit. Only the LGPL'ed code itself must remain Free. Such 'client code' can even be proprietary; it need not be LGPL'ed.

I'm so confused. Is that the final word? He didn't mention Java specifically. He is not a lawyer. I don't think this is going to be the final word for Apache. I'm starting to think that FSF wants this to be a confusing issue.

Andy Oliver: I clarified the LGPL in Java issue with the FSF and posted to poi-dev. According to the FSF, the LGPL is indeed viral towards Java code. Thus, in essence GPL and LGPL are the same for Java. You could still find that the copyright holder of a particular software package held a different view and is willing to state that explicitly, but it looks like the Apache Software Foundation and Sam were right and I was wrong.

That really sucks. Not the part about Andy being wrong, that happens all the time. I'm talking about the now confirmed viral nature of the LGPL when applied to Java. I believe that Roller uses a couple of LGPL components, JSPWiki for example. I guess this means that either those components should be removed or Roller should switch to a dual GPL and APL license.

I was unable to use the early Tomcat 5.0 alphas when I was working on Professional JSP 2.0 and I've heard plenty of complaints about Tomcat 5's extreme instability, but the latest alpha seems to work just fine. I downloaded it, loaded my Data Access for Web Applications example in, and it just worked! I was also happy to find that the Sysdeo Tomcat plugin has been updated to support the Tomcat 5.X line.

Thank goodness. I was starting to think that the Java-GNOME project had died.

I'm still totally bogged down in my new job and in finishing up the ProJSP chapters for APress. That's not going to stop me from making time tonight to go see Matrix Reloaded at the IMAX theater.

I'm still at work now, but I'm waiting for my DB2 install to wrap up, so I have some time. I'm testing the limits of my new laptop by installing WebSphere, WebLogic, DB2, and Oracle. I need to learn the nitty-gritty details of J2EE/WebApp/EJB deployment on those platforms.

I also need to get back up to speed on XDoclet and EJB. To get a jump-start on the re-learning curve, I downloaded JBoss-IDE. JBoss-IDE is a plugin for Eclipse that does two jobs. Job #1 is starting JBoss, stopping JBoss, and viewing JBoss log files. Job #2 is providing a new GUI for configuring and running XDoclet. Take a look at <a href= "http://unc.dl.sourceforge.net/sourceforge/jboss/Tutorial_1.1.0.pdf">the tutorial (PDF) for more information and screenshots.

The JBoss-IDE XDoclet plugin works like this. You use the GUI to configure XDoclet for your project, then the GUI generates an Ant script containing the code to run the XDoclet taks that you configured. You can then call this generated build script from your project's Ant script. This works pretty well and it is really helpful, especially if you are new to XDoclet or if your XDoclet skills have grown rusty. My only complaint is that I cannot figure out how to make JBoss-IDE generate relative jar paths, so I can't share the generated Ant scripts with other developers.