Raible Designs

Erik's Struts/XDoclet example application

Erik Hatcher has released his "much hyped and long awaited sample application" demonstrating how to generate some Struts goodness with XDoclet. You'll be happy to know that I've been swapping e-mails with Erik a lot in the past couple weeks - so my struts-xdoclet app is very similar. Here are the details:

It is a trimmed down version of the application Steve and I developed
for our Java Development with Ant book.

Relevant to Struts folks are these tidbits:

  - XDoclet is generating struts-config.xml, validation.xml, web.xml, 
and antbook.tld

  - LabelTag (currently mysteriously busted for required tagging) is 
included.  This tag styles field labels differently if its in error, and 
(when its not busted, it works on my production app actually) it shows 
an asterisk by required fields.

  - strutsgen: a one-off starter generation for JSP's and 
ApplicationResources.properties snippets for cutting and pasting into 
the main application.  It uses XDoclet to process a specified form bean 
and uses the fields it finds for generation.

  - Use of StrutsTestCase for Cactus testing.

  - Maybe some other Struts goodies lurking there that I've forgotten to 
mention.

The application itself is a document search engine, based on Lucene, and 
should run out of the box in Tomcat or JBoss.  It even has the ability 
to (at build time) toggle between whether to use a session bean or not 
(functionality is the same either way).  By default, you can simply 
deploy the WAR that you've built and it will work without EJB, but if 
you are interested in exploring the session bean piece it can be turned on.

I am in the process of creating much more detailed documentation, but I 
wanted to get this out sooner rather than later.  If you find any 
problems or have any questions, please do not hesitate to let me know so 
I can refine it and post updates.

The one documentation I need to provide now is to note that you'll need 
j2ee.jar to build.  I include all other API's.  To build, unzip the file 
(link below) and it will expand into JavaDevWithAnt directory.  In that 
directory, run Ant.  If you have J2EE_HOME set you shouldn't need to do 
anything... just "ant".  You'll also need to build a site index, so run 
"ant build-site-index".  This is intentionally two separate steps.  If 
you don't have J2EE_HOME set, then you need to provide j2ee.jar to the 
build.  Do it this way:

	ant -Dj2ee.jar=/path/to/my/j2ee.jar

Where "/path/to/my/j2ee.jar" is the actual path to your j2ee.jar

Post any questions/problems to me directly.  E-mail me at 
[email protected].

Download: http://www.ehatchersolutions.com/downloads/

You will need JUnit 3.8(.1) as I take advantage of the new lack of 
required String-arg constructors.  junit.jar should live in 
ANT_HOME/lib.  Ant 1.5(.1) is required also.

There will be updates in the next week or so as I polish the 
documentation and address any issues that turn up.

	Erik

JSP 2.0 and Servlets 2.4 Research

I'm going to record a few items from my JSP 2.0 and Servlet 2.4 research tonight. I hope you don't mind.

From JSR 152 (JSP 2.0):

We plan to incorporate two main new features into JSP, and a few incremental features. Additionally we expect to incorporate erratas and clarifications as well as opportunistic improvements.

The two key features are the use of JSP to author custom actions, and adding expression language support into the container. The main goal of this JSR is to deliver these new features into the JSP specification in a timely manner. This goal will likely limit what other features can be incorporated.

So (to me) this means that if you know JSTL, you already know half of JSP 2.0. And the best part of JSP 2.0? One main theme of this update of the JSP specification is that we want to simplify, not complicate, the view of a JSP that most users, specially page authors, have.

From JSR 154 (Servlet 2.4):

Servlet 2.4 will be a relatively small upgrade to the existing API. Since the technology is highly popular, we have a large number of small requests for enhancement to the API that we would like to be able to accommodate. Over and above that, Servlet 2.4 will address the following areas in a portable manner:-

* Modularization of the deployment format

The goal is to achieve a level of modularity with the deployment format which is not currently possible using the current DTD based deployment descriptor. The intent is to enable this modularity to manage the organization of deployment information of related technologies that use the web container as the underlying platform. These frameworks include dependencies on other J2EE components, JSP technology, JavaServer Faces, JAXM, JAX-RPC and other frameworks that build on servlet semantics.

Hmmm, this almost sounds like the module idea in Struts. Does this mean they want to allow sub-applications (or modules) within a web application? After a little research, it appears that the 2.4 spec will allow you to add new namespaces to your web.xml file, and therefore, you can extend the deployment descriptor for your own needs. Look for vendors to use this, as well as UI Frameworks like JSF. The top of your web.xml will resemble the following on 2.4 container:

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://
    java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

Also on the list:

* Enhancements to the security model
     - Provide a facility for logging out of web applications portably
     - Clarify, possibly by adding API or deployment syntax, the relationship between HTTP session state and authentication state

* Smallish enhancements to the filter and listener models
     - Provision of deployment syntax for declaring API dependencies between elements in a filter chain
     - Addition of request and response level listeners and event notifications.

Cool, sounds like good stuff. Logging out of web applications portably? You mean there's more we can do than invalidate the session? I wonder what else there is to logging out? Maybe it'll remember the last page the user was on? No such luck (but you can do that with Cookies). It appears that there's a strong effort to encourage vendors to implement single sign-on for webapps. Tomcat is the only one I know that does this now. HttpSession has a new logout method - if the servlet container implements single signon, the logout logs the client out of all web applications on the servlet container and invalidates all sessions associated with the same client. I guess this is cool if you have more than one webapp on your server. Now we just need an API to allow webapps to talk to each other on the same container. I guess you could call this HTTP, but I want something better than that. Another interesting item I found is that you'll be able to use a servlet as your welcome-file, which is currently not allowed in the 2.3 spec.

So how do these new specs influence how you write your webapps? It doesn't seem like there's much that's new, and certainly no ground-breaking features. So learn Struts, so you'll have a headstart on JSF, and learn JSTL, so you'll know the expression language used in JSP 2.0. If you've been put off by writing tag libraries, it'll be easier with JSP 2.0, as you'll be able to use JSP fragments as a type of tag library. Lastly, if you're not using container-managed authentication (i.e. BASIC, FORM), you might want to consider it. The thing I like most about container-managed authentication is that you can bookmark pages in an app, and then get right back to them by entering a login/password - this is how it should be vs. login -> main menu -> bookmarked page. You can use filters to restore any session or request information that is needed for the bookmarked page.

Pheww, boy am I lucky! I copy-pasted this post before I tried to submit it, and whaddya know, Chimera crashed after I hit the "Post to Weblog" button!

Form-Based Authentication

I posted the following message to the tomcat-user group yesterday:

On Tomcat 4/5, I am able to use the following configuration in my 
web.xml:

<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>/login.jsp</form-login-page>
    <form-error-page>/login.jsp?error=true</form-error-page>
  </form-login-config>
</login-config>

However, I know that there are app servers out there that do not support
this - the form-error-page MUST be a different JSP.  So I'm wondering,
is there a value I can grab in my login.jsp that tells me the URL of the
protected resource the user is trying to get to?

I tried <%=request.getRequestURL()%>, but that gives me .../login.jsp -
and I am expecting welcome.do.

I know iPlanet used to set a cookie and I could use that as described
here.

Thanks,

Matt

Craig McClanahan responded with the following answer - which was just the information I was looking for:

There is no portable mechanism to acquire the request URL that was originally requested, nor any guarantee that this is even possible. All you know is that the container has detected that a protected URL was requested, and that there was no currently authenticated user.

So the lesson learned is that if you want to make your webapp portable across different app servers, use two separate pages for the login and login-error pages.

Struts-XDoclet 0.1

I did a bunch of work today to get struts-xdoclet off the ground. Basically, all that exists write now is the generation of struts-config.xml and web.xml from xml files in a merge directory. There are no .java files in this project yet.

I'm posting this to you in hopes of getting some validation of the directory structure and Ant-based build/deploy process. The deploy task originally worked as Erik Hatcher suggests in his book, but whenever I tried to redeploy, it would give me errors when trying to remove a .jar file - so I resorted back to a simple copy to $CATALINA_HOME/webapps. The build.xml file I put together is based on what I found in struts-blank.war (for 1.1), roller's build process, my own experience and good ideas from the Ant book.

I've also configured form-based authentication and I plan to add a bunch of optional modules (i.e. SSLExt for SSL Switching, password encryption) to the mix.

I'm still searching for a sample-app idea for the persistence layer (i.e. authors and books). I'd like to do something that folks can use, so I'd definitely like to include an admin section for administering user's and their properties. Maybe even offer features such as registration (might be a bit difficult using tomcat-users.xml, but not so bad with JDBCRealm or an LDAP server), and password recovery.

You can download the first cut of this - which should build and allow you to login - at http://www.raibledesigns.com/struts/.

Next steps include the security modules I mentioned above, and generating validation.xml and persistence classes from a POJO. I'm still undecided on using Castor or Hibernate for the persistence layer. Dave (Johnson) seems to think Hibernate has some great stuff, and he's used Castor for a while, so that's probably the direction I'm leaning towards. It would be great do be able to do both.

JSP 2.0, Struts and Security

I've been asked to write some chapters in an upcoming JSP book that covers JSP 2.0 (JSR 152) and Servlets 2.4 (JSR 154). I'm thinking of doing a chapter on Struts and a chapter on Security. In the Struts chapter, I'd like to cover developing a Struts application using Ant, XDoclet and Middlegen - but I don't know if Middlegen supports Struts 1.1, nor if the generated JSPs can be modified to use JSP 2.0 syntax. I'd hate to spend a lot of time contributing to these projects to make my struts-based app work. So I'm asking you (the developers) what kind of app you'd like to see me develop?

For the Security chapter, I was thinking of developing an app that has form-based authentication, a Filter to look up the user's information, password encryption and an SSL login.

For the Struts chapter, I want to develop an app that developers can use to 1) learn about Struts and JSP 2.0 and 2) also has code they can use in their own projects. I'm torn because I really want to redo this photo album software (the site doesn't appear to be rendering images right now), but I want it to be useful. Hopefully by using XDoclet extensively, it doesn't matter what I write - the build and generation process will be useful.

My biggest hurdle to overcome in all this - it's due in 3 weeks! That should be a nice ball of stress that will keep me from sleeping night after night. Any advice or suggestions are welcome.

To see what JSP 2.0 is all about, check out the JSP 2.0 Early Access Release and here is a short and sweet article of changes.

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...

XHTML Strict and Forms

Did you know that with XHTML Strict, a <form> element can't have a name attribute? Actually, the only required attribute is action. But, if you do want to identify your form, then you have to use the id attribute. The problem with this is that many of us web developers are used to referencing a form (with Javascript) with document.formName. So as a service to my readers, if you do decide to XHTML 1.0 Strict, you will need to reference your forms (in Javascript) using one of the following syntaxes. For the sake of this example, pretend our form is named "webForm":

document.getElementById("webForm);
// assuming it's the first form on the page.
document.forms[0]; 
document.getElementsByTagName("form").item(0);

Of course, if you're trying to get the value <input> tag within your form, and that input has an id attribute, you can just get that using document.getElementById("inputId");.

You ask - what insired you to post this? Well, the Struts enhancement to produce XHTML-compliant code from the tag libraries. It was closed yesterday, and they seemed to have missed this - in other words, the <form> still has a name attribute. It'll be interesting to see how they resolve this. I'm hoping that Struts is not tied to the name attribute at all, and the fix just requires a bunch of fixes to Javascript that is written (by the tags).

Use Labels in your Forms

You should use the <label> tag in your forms because it'll increase the accessibility and usability of your web interface. Consider this, when you add a label to a checkbox, the user can click on the label (or the checkbox) to select/deselect. When you add a label to an input element or textarea, clicking on the label sets the focus on the field. It just makes it easier, so spend the extra 5 seconds to add one next time you're developing a form, you'll be glad you did.

W3C Supports SVG

I found this while using the latest (1.0.2) version of NetNewsWire to surf my RSS subscriptions.

In a development that could help Adobe erode some of Macromedia's vector graphics lead, the Web's most influential standards group issued a draft designed to make its vector graphics standard work more easily on cell phones.

Facing an end-of-year publishing deadline, the World Wide Web Consortium (W3C) this week also released a flurry of proposals covering linking and querying Web pages and XML documents.

But the consortium reserved most of its enthusiasm for the vector graphics changes, which it hopes will help nudge the industry away from the accepted--and proprietary--standard, Macromedia's Flash technology.

"What we're seeing are some exciting developments on the SVG front," said W3C representative Janet Daly.

SVG, or (Scalable Vector Graphics), is the W3C's method for creating vector graphics, which are more flexible than the common bitmaps that form most of the graphics on the Web. In contrast to bitmaps, which are shipped fully rendered and defined pixel by pixel, vector graphics are composed of mathematical descriptions of curves and forms. This composition results in a more compact file, the ability to render the image to fit television or monitor screens with varying resolutions, and greater ease in animating the image. [W3C sees graphics on cell phones]

SVG is cool - it allows you to draw graphics using XML. It'll certainly make for lighter web pages and flash-type presentations using simply text. Watch this one, it'll be hot!

Later: I found this simple SVG Example and a whole slew of W3C Presentations.

Cool Comments

Scott Andrew points us to Joe Hewitt's weblog. He's got a sweet commenting UI that I'd love to see in Roller.

Because I'm always looking for new ways to exploit browser technology for some new marginally useful purpose, check out my new commenting UI! I make Movable Type output comments to XML files, load them through script, and turn them into HTML in this webpage for your commenting convenience.

Also, the comments form is inline with the page and is submitted without reloading the entire page. Woop-dee-freakin-doo.

Very cool! Hopefully there'll be some code soon we can modify for Roller.