James provided me with the answer I was looking for this morning - use Run >> Debug As >> JUnit Test. Cool - it worked! I had to add a few additional JAR files to my project's classpath to make it run a test succesfully - but I'm stoked that it's working! A comment I left on James's weblog might interest you:
I don't *need* Ant to run JUnit tests, but as strange as this may sound - it's the only way I've ever done it. In fact, I've hardly written or run *any* Java classes with a main() method. ;-)
Crazy, huh? I guess that's what happens when you start out writing JSPs and Servlets vs. command-line or Swing apps.
I'm planning on attending today's Struts training and will be reporting here again. I got up at 6, hoping to do the labs and discovered the first step was downloading the latest Basic Portal setup. Since it's 200 MB, I've been dicking around for the last hour and a half, waiting for it to download. Yikes - I thought struts-resume was bad at 10.5 MB! I guess the difference is that it includes JRockit, Mozilla, OpenOffice, Vim, Ant, Eclipse, JMeter, Jikes, PostgreSQL and Resin.
Today's session seems to be covering databases, SQL and database performance. Vic mentions that 90% of performance is in the data model design. If you can fit your database on a laptop, then performance will probably not be an issue. I agree with this. I did the first lab during the first half-hour of the preso. Pretty simple stuff: creating HTML files and accessing them through a browser. This is probably a good lab to get everyone going and stuff installed. Also proves that Resin is running. Of course, it took me two hours to complete this lab, including the download, so I guess it's not that short!
Commons SQL is a new version of Torque (a manual persistence layer). Vic uses RowSets a lot, has one site with 40,000 concurrent Struts users with sub-second response times. He attributes this to rowsets. He says, "To create high-scalable applications, you need to know SQL and use things like RowSet, Ibatis.com, Commons SQL and Scaffolding." I tend to disagree - I think that EJBs (and possibly Hibernate) are your best bet for highly scalable application (i.e. 10,000+ hits per second). If your EJBs are slow, it's probably your code or your appserver. Try EJBs on JBoss and I'm betting you will be pleased. Then again, I've never created a highly-scalable application, and Vic has, so I'm not much of an authority. He, he - he mentions that Castor has lost a lot of mindshare; "Great for development, but not very scalable in production." So true - or at least Roller seems to prove this. From the folks he's talked to, Vic says that TopLink has a horrible reputation.
Hmmmm, interesting. Vic puts all the database connections and CRUD in his ValidatorForms. This is not saying that his bean matches his database tables. I don't know that I'd recommend this, but it certainly might simplify things. However, personally, I'm more comfortable with keeping my POJOs and ActionForms pretty dumb (just getters and setters). He has a DAO that handles CRUD and population of the bean. I wonder where you'd put the business rules in this implementation? In the DAO? If it's in the DAO, what if you have to write a new DAO implementation. For instance, if we used this approach on Roller, we'd have to re-write our business rules for Hibernate and Castor. Ugh.
For testing, he puts a test() method on his beans and uses a Servlet or a plain class with a main() method. Personally, I'd recommend using JUnit and JUnitDoclet (and Ant) to generate and run your unit tests. It's much easier than writing a servlet to test - and can easily separate your tests from your real code. See struts-resume for examples. I'll be releasing AppFuse in the next couple of weeks. This (hopefully) will provide a nice starting point for creating web applications. In reality, if no one uses it, I'll probably be better off (less support). It's been working great for me on my current project and has easily saved us a month of startup time. Right now, appfuse == struts-resume.
Vic mentions using a BaseAction that dispatches to the appropriate method in your subclasses. He says that the only difference between
this technique and DispatchAction (or LookupDispatchAction) is you can specify a default method. Here's a tip: use the unspecified method. Here's how to make your edit() method the default:
public ActionForward unspecified(ActionMapping mapping, ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception
{
return edit(mapping, form, request, response);
}
Vic hints that the next iteration of Basic Portal will be written to use the iBATIS Database Layer and MySQL. Interesting, I thought iBATIS was a company, but nope: it's from the author (Clinton Begin) of JPetstore. On most days, I'd recommend Hibernate here, but I've spent the last 3 days wrestling like mad with it, so I won't. Of course, after leaving work last night, I think I might've figured out the problem. My brain is likely to blame more so than Hibernate.
Ted Husted chimed in at the end and mentioned that he is going to touch on Hibernate next week. Cool!
