Are you using XDoclet to generate the validation.xml file for Struts' Validator Framework? If you're using Struts and you're not using the Validator - you should be IMO. It makes both client-side and server-side validation soooo simple. Using XDoclet to generate the key file (validation.xml) makes implementation a piece of cake. We have Erik to thank for this wonderful addition to XDoclet. Much appreciated sir!
I'm guessing that not many people are using this feature b/c it works kinda funky right now. It disregards the order of your properties in your ValidatorForm and generates entries in alphabetical order. This is great except the client-side (JavaScript) piece of the Validator uses the order to determine which fields to validate first. This has caused a slight headache for me on my project, so I fixed it. Checkout XDoclet's JIRA for the bug and the patch. Hopefully it'll get committed soon, but in the meantime, I'll continue using my patched Apache module that allows me to generate ActionForms from POJOs and orders my validation.xml correctly.
Sun has a Ant Quiz. Test your Ant knowledge! I missed 2 - #5 and #9. Number 9 asks "XDoclet is?" You'd think I've worked with it enough by now to know what the heck it is - but apparently not. ;-)
On my current project, we're developing an application that has two components. One is a webapp that lives in Tomcat and the other is a standalone jar that runs as a daemon. The daemon checks an e-mail Inbox every few minutes and if there's new mail, it processes the Excel attachments and enters this information in a database. My question is: where on the filesystem should we put this daemon? We're running on Red Hat 8 - maybe /usr/local/mail-daemon or something? BTW, we were running on BSD, but it's Java wasn't up to snuff (didn't support 1.4) - so we're running Linux instead. I dig the Linux/Java combo - it just works!
If my load balancing with Tomcat and Apache article is not what you're looking for - maybe you want to setup Tomcat clustering. If so, check out the tomcat-javagroups project at SourceForge.
I saw a couple of e-mails yesterday on the tomcat-user mailing list asking about migrating a Resin-based application to Tomcat. Turns out
that Resin let's you do a bunch of non-standard stuff and doesn't validate DTDs, so migrating can be a headache. So, if you're smart,
you'll follow standards and chances are your webapp will work on all appservers. Kinda like XHTML - follow standards and the containers/browsers will follow.
