Raible Designs

My JSF Experience

Of all the MVC Frameworks I've developed with in the last few weeks (Struts, Spring MVC, WebWork and Tapestry) - JSF was by far the worst. And it's not the implementations that are the problem, it's the spec itself (as far as I can tell). Plain and simple, it does not simplify web development.

I spent 3 days developing a simple JSF app - most of it which I had done in the first day. The last 2 days have been spent migrating to MyFaces and trying to find clean ways to do things. My perspective on JSF after this experience? Run away. Run far, far away. All of the above mentioned frameworks are MUCH superior to this technology. Let's get on with the things I learned.

• MyFaces handles duplicate posts nicely. If you hit "reload" on your browser after saving a record, you get presented with an empty form rather than a duplicate record. I believe I got a duplicate record with Sun's RI.
• The ability to specify an "action" attribute on a button (or a link) and them map that action to a page (in faces-config.xml) is pretty cool.
• Every button or link clicked results in a form post. That's just wrong - why can't I have true links like the web is supposed to? So much for bookmarks.
• Saving state on the client results in enormously long URLs and/or hidden fields.
• JSF support is fairly non-existent. Unlike the other MVC frameworks, the MyFaces mailing list has hardly any traffic and the Sun forums aren't much better.
• The MyFaces website seems to be down whenever I want to look something up on it, like right now.
• I did find some CRUD examples, like this this one, but was disappointed to find that i18n is not considered for setting success messages. I ended up using the solution described in this post. 6 lines of code to set a success message - you've got to be kidding me! Most frameworks have a simple 1-2 liner.
• Waiting for JSPs to compile the first time has surprisingly become painful after using Tapestry, Velocity and FreeMarker for the last 2 weeks.
• Integration with Spring is fairly easy (code is in CVS), but MyFaces spits out an error when it shouldn't be.
• Validation messages are ugly. For instance, when a required field isn't filled in, I get: "lastName": Value is required. I was able to override the default messages, but I was never able to use the label of the field (vs. the field's id).
• The <h:messages> tag is practically worthless. Sure it's great for displaying messages (error and success), but that's about it. It has a "layout" attribute that doesn't even work in Sun's RI, and in MyFaces it just wraps a <span> with a <ul><li> or a <table>. Both of these layouts are useless b/c you can't set a css class on them. I ended up using "table" and having to set a generic CSS rule (width: 100%) in order to get the message/error bar to show across the top of my page. This tag also doesn't allow you to escape HTML.
• The <h:dataTable> component is nothing like the displaytag. MyFaces claims to have a pageable/sortable component, but it requires custom logic/methods in your managed-bean. Yuck. I ended up using <h:dataTable>, which has neither sorting or paging. This is only because I couldn't get an <h:commandLink> working inside a displaytag column.
• JSF-created apps are pretty much untestable. Managed-beans are testable, but the UI seems really difficult with jWebUnit and Canoo's WebTest. IMO, it should be possible to specify a URL to edit a record (i.e. editUser.html?id=2). With JSF and my master/detail app, the link to edit actually sets about 5 hidden form fields with JavaScript and then submits the form. I could probably figure the URL out, but it'd be ugly. Also, the MyFaces <h:dataTable> will not render an "id" attribute if you specify one. This is needed to verify tables and their data with jWebUnit.
• When using "ant reload" to reload my application (using Tomcat's Ant Tasks), I kept encountering a ThreadDeath error. This seems to be specific to MyFaces as I never saw it with other frameworks or Sun's RI.

Like Tapestry, I felt like I was banging my head against the wall a fair amount. However, with Tapestry (and all the other frameworks), I was able to get exactly the behavior I wanted w/o too much work. I could produce clean and user-friendly error messages - (Tapestry already had clean required messages built in). I was able to write a jUnitWebTest to test all CRUD activities. With JSF, I was able to test one thing - adding a new record. I couldn't edit it b/c the JavaScript support (which I tend to not use) puked every time it encountered a JSF-generated JavaScript function.

My opinion after all of this? If you know Struts, Spring MVC and WebWork are fairly easy to learn. WebWork is simpler and elegant, but Spring MVC supports more view options out-of-the-box. Tapestry is cool, but you'll have to invest a lot of time into learning it and you'll probably get caught up in its cult and forever be claiming "Tapestry Rocks!" which can get annoying to your fellow developers. Finally, I can confirm that SiteMesh rocks - it worked for all the frameworks I used and I never had to change a single line of code.

Whatever you do, don't use JSF. Not yet anyway.

JSF: Which implementation should I use?

A few weeks back, Bill Dudney recommended I use MyFaces for my JSF app. He said it was less buggy than Sun's version. When I looked at MyFaces's website today, I noticed all their releases are betas - which is not a good sign IMO. Anyone have experience with either one? I think I'll go with Sun's as it probably has a larger community, and therefore more information.

I'm also hoping to use the JSF-Spring package. I was a little scared when I saw it's lack of documentation, but then I discovered it's in the JavaDocs if you scroll down. I'm not looking forward to the JSF's tag soup, but hopefully it won't be too bad.

AppFuse Changes: Unit Testing with Easy Mock and Spring's Struts Plugin

I have a couple of proposal for the next AppFuse release. Let me know what you think:

• Change service and action/controller tests to use Easy Mock to mock dependencies. This will likely require a bit more code in the test, but it'll allow true unit testing of components. Current tests are more like integrations tests, which tend to be slower. The Canoo WebTests will continue to act as the integration tests that verify functionality top-to-bottom.
• Change Struts to use Spring's Struts Plugin. XDoclet's Spring stuff should make this pretty easy so you don't have to modify any XML - just like the current situation. The advantage of this is you can use dependency injection on your actions, rather than getBean(...).

I hope to get these in, along with a WebWork option, in the 1.6 release. I'd love to get 1.6 done and released in August, but I'm probably dreaming since I'd like to finish Spring Live in the same time frame. Of course, I'm also planning on fixing any bugs that are currently entered.

[ANN] AppFuse Light 1.0 - a.k.a. Equinox

For those of you looking for an AppFuse Light, I have good news for you. I've actually been sitting on it for several months now, but now I'm prepared to release it. It's name is Equinox and it's much, much simpler than AppFuse. Equinox has only one build-time dependency (CATALINA_HOME being set for the servlet-api.jar). There's no code generation and no features - not even security. However, it supports building, testing and deploying from Ant, and even has support for managing Tomcat out-of-the-box.

To get started with Equinox, you can download the QuickStart Chapter from Spring Live. This chapter shows you how to develop a simple webapp using Struts, Spring and Hibernate - which talks to an HSQL database. Struts and Spring are integrated using the ContextLoaderPlugin and all tests are designed to be run out-of-container using JUnit and StrutsTestCase. Equinox ships with project files for both Eclipse and IDEA so you can develop and run the tests in either of these top-notch IDEs. There's also a demo available. Thanks to Boér Attila for the kick-ass CSS.

If you like what you see in the QuickStart Chapter, there's much more in the other ERP chapters of Spring Live - now available for download. Too see what's in the other chapters, checkout the Chapter Summaries.

This is a nice milestone - feels good to have made it this far. Have a good weekend!

[NFJS Denver] Howard Lewis Ship and Creating Tapestry Components

Tapestry - "we try to make the simplest approach the correct approach." I haven't been blogging much of this session b/c I'm just sitting back and soaking it up. It's a good session and Howard is a good speaker. I'm learning a lot about Tapestry and it's philosophy about web development. I especially like the line-precise error reporting - it's something that all frameworks need to do better.

Tapestry looks very cool. You basically write an abstract Java class that has abstract methods for properties you define in an XML file. Tapestry them implements this class and its abstract methods. The class that Howard wrote to handle a login form is very simple - it's only about 7 lines long - and 4 of those are abstract methods! The HTML form is cool too - not much of the HTML has changed since it was bare-bones HTML. He's merely added some a few "jcwid" and "listener" attributes to some of the elements.

Tapestry is a large system of subsystems, all implemented behind interfaces. It ships with its default behavior (i.e. page/template pooling), but you can (supposedly) easily change this behavior or implement custom classes. Internationalization is a first-class citizen in Tapestry - no surprise here since it is in most MVC frameworks. Tapestry 3.1 will embed Hivemind at its core and will provide much easier integration with tools like Hibernate and Spring.

Tapestry's "Validation Subsystem" looks very rich - providing both client side and server side validation. It uses Field decorations to highlight both labels and fields when validation fails. By default, it promotes using CSS to change colors, backgrounds, etc. There are a couple of Helper Beans for validation: the Validation Delegate and the Validator. It's pretty neat that you can bind a label to a field in XML. Since HTML already allows binding <label>'s to form elements - you'd think that Tapestry could harness this by parsing the template. I suppose it's just easier to require the XML binding - then you don't have to worry about the user writing invalid HTML.

Howard is trying something new in this presentation - real-time coding. I use this in my presentations and it works pretty good. He's having some serious issues b/c he can't mirror his laptop's monitor with the projector. This obviously makes it difficult to code since the slide show is his monitor. I try to use pre-canned code (i.e. IDEA Live Templates) so there's less chance of fat fingering things. I also use a Mac - on which mirroring works great.

The "Page" object is pretty cool in that it contains a bunch of lifecyle methods you can override. Most frameworks don't have lifecycle methods. I guess Spring's SimpleFormController does with onSubmit, onBind. Lifecycle methods are a Good Thing IMO. The formSubmit() method is always called, regardless of validation errors. Therefore, you have to get the IValidationDelegate and check if it has errors before continuing. I wonder what the logic behind this is? Most frameworks seem to support automagical validation - with no further work required by the programmer. I guess it's kinda cool b/c you can continue with validation errors if you want to. Choice is always a good thing.

Howard just showed us a client-side validation example. The wicked cool thing is that the client-side script is configured in a .page file rather than in the HTML template. Most frameworks I've seen (that support client-side validation) require you put something into your template. This was a good talk, I'm definitely interested in Tapestry and excited to start learning it in the next couple of months.

[NFJS Denver] David Geary and Advanced JSF

David is going to cover some JSF advanced topics: data table, tiles integration, custom components and validators. I was talking with Rick Hightower last night. He mentioned that he's been doing a fair amount of work with JSF lately and really likes it. He actually said he thinks he can develop a webapp faster with JSF than he can with Struts. He also said that JSF ships with a lot of what you need - and a lot of the JSF books seem to cover how to add new stuff (custom components and validators) you don't need. This is to say that the books tend to cover the features of JSF, rather than how to develop successful projects with JSF. I said I thought it'd be nice if there were some JSF books by folks who'd used it to deliver applications. More of a "here's what you need to know" kindof manual. I think that's what JSF needs.

The <h:dataTable> in JSF is pretty much the same as the <c:forEach> tag in JSTL. An interesting note on the JSF expression language - it starts with a # instead of a $. For example:

<h:dataTable value='#{tableData.names}' var='name'>
...
</h:dataTable>

The major difference between JSF and JSTL's expression language is that JSF EL can access managed beans. The JSP 2.0, JSTL and JSF expert groups are going to work together to try and synch up their expression languages. Personally, I don't see why the JSF folks didn't just use JSTL and simply include managed beans in the lookup logic. Here's a wierd one - if you use any "template text", i.e. in a dataTable - you have to wrap the text with <f:verbatim>text</f:verbatim>. David says this is one of the embarrasing things about JSF. He hopes it'll be fixed in the next version.

The <h:dataTable> looks very similar to the DisplayTag. Sweet - that's one less thing I'll have to worry about when creating a JSF app. I've said it before and I'll say it again - my two favorite tag libraries are the DisplayTag and Struts Menu. As I'm learning new frameworks, one of my major goals is to reproduce the same functionality I enjoy in my Struts+JSP apps. It's been pretty simple so far with Spring and WebWork, since both support JSP. However, it might get a bit tricky with Tapestry and JSF. I'm sure it'll be possible (and hopefully easier) to reproduce this functionality, it's just a big unknown at this time.

"Form" beans in JSF are not like form beans in Struts. It's really just a class that doesn't extend anything and has action handler methods. An interesting point - the actionListener's value (which is really a class.methodName) can be any class in any scope OR it can be a managed bean. How about some code:

public class Form { 
    public void changeLocale(ActionEvent e) { 
        FacesContext context = FacesContext.getCurrentInstance(); 
        Map requestParams = context.getExternalContext(). 
                            getRequestParameterMap(); 
        String locale = (String) requestParams.get("locale"); 
        if ("english".equals(locale)) { 
            context.getViewRoot().setLocale(Locale.UK); 
        } else if ("german".equals(locale)) { 
            context.getViewRoot().setLocale(Locale.GERMANY); 
        } 
    } 
}

The major reason behind the FacesContext is to support Portlets. So rather than using a ServletContext or PortletContext, the FacesContext provides a level of abstraction. The underlying theme of JSF: To be as flexible as possible. This is to say that there are many ways to do things with JSF. I often think it's better to have less choices when learning a technology, but once you're versed in it - choices are great. I guess I just wanna know the best way to do things, not all the options. Actions are for business logic, ActionListeners are for UI logic. ActionListeners are always fired before Actions - in the event that you have an actionListener and an action defined for the same component. Listeners and Actions are really just methods on a class and they can actually both be in the same class. JSF is starting to appeal to me. This session has been one of the fastest so far - there's only 20 minutes left and it feels like it's flown by.

JSF ships with converters for dates and currencies out-of-the-box - cool! Now David is explaining about a custom CreditCard converter. This is what Rick was talking about last night. Why do we need to know this stuff? Would a normal talk on another MVC Framework talk about converters and validation? I bet not. I think it's a good topic - maybe something that other frameworks should cover more visibly. The Converter interface has two methods: Object getAsObject() and String getAsString(). The Validator interface has one method: void validate(FacesContext context, UIComponent c). I just asked David about using Commons Validator instead of JSF's core validator. He said, "Yes, it's possible." Sweet! You can use Commons Validator with Struts, JSF and Spring! Now if we could only get support for it in WebWork and Tapestry - then I'd eliminate my need to learn another validation engine.

Now David is talking about using Tiles with JSF. It looks as simple as using the <tiles:insert> tag to insert dynamic content into an <f:subview>. Any time you insert a tiles component, you need to wrap it in an <f:subview> tag. That was short - we're done talking about Tiles. I had some questions - i.e. can you refer to a definition directly from an action or in the action's navigation definition? Oh well, onto custom components and renderers. Custom components and renderers seems to me to be something that should be left out of these types of presentations. Sure, it's cool they're possible - but who's using them? Have you needed them in a real-world JSF application? I only want to know the things I need to know to develop a real-world JSF webapp. Sorry, I forgot - there aren't any real-world webapps written with JSF. If I'm wrong - send me a link. ;-)

This presentation was good - it inspires me to learn some more about JSF. Maybe there'll be some projects in my next gig that require JSF - that would be wicked cool. After all, the best way to learn this stuff is to get paid to do it. If nothing else, I'll get to learn it later this year when I write AppFuse's web layer in JSF.

How does your MVC framework handle duplicate posts?

One of the problems that you'll often see in webapps is that when a record is added - hitting refresh on the browser will cause a 2nd record to be added. This is because the "Save" action usually does a forward, rather than a redirect, and the full post is re-created. I'm curious to know how other MVC Frameworks handle this issue, particularly Spring, WebWork, Tapestry and JSF. In Struts, it's pretty simple to solve. When the form is first displayed, you'll likely go through an Action. In AppFuse, this would be something like UserAction.edit(). In the edit method, you add a saveToken() call to put a token into the session:

Then in the save() method, you can check for a duplicate post using the isTokenValid() method:

How does your Java MVC framework handle this? Do you have to programmatically handle it like Struts - or is it built-in to the framework to handle it auto-magically?

MySQL Conference - Day 2

JBoss and MySQL
I'm sitting in Mark Fleury's session on MySQL and JBoss Integration. I'll try and record the things I learn in this session. The first thing that Mark mentions is how they own many popular open source projects: Hibernate, Tomcat, etc. - because they employ the lead developers on those projects.

JBoss Numbers
A standard in the market: #1 in development - more than 4 million downloads in last two years alone. A standard for System Integrators: #2 in growth - CRN survey puts JBoss certified consultant at #2 fastest growing certification with large system integrators. A standard in the market: #3 in production - JDJ survey: 70% of users to go Deployment. BZResearch survey. 13% in 2002, 27% in 2003, largest growth of all servers (IBM at 40% and BEA at 34%).

"Federated" Projects
JBoss AS, Hibernate, Tomcat, JBossIDE (Eclipse integration, XDoclet driven development, debugging), JBossCache (distributed data), JGroups (reliable multicast and cluster communication), Nukes (portal and CMS), JBossAOP and Javassist (bytecode manipulation library).

Cache and ORM: Scalability for MySQL
Keep your data in a MySQL instance. Put an ORM (Hibernate) layer on top of it. Replicate the data with cache infrastructure. Cache is King.

Mark is now talking about Hibernate and what it's useful for. I'm guessing that a lot of folks in this session are either interested in JBoss or Hibernate. He's talking about RDBs and what they do well. Next I'm guessing he'll talk about Hibernate and all its features. No need for me to regurgitate that information here - since I suspect a lot you are familiar with Hibernate. If not - what the hell are you waiting for? ;-) If you can't use Hibernate b/c you're standardized on SQL, you should at least use iBATIS. BTW - did you know that BEA's Page Flow demo app is a re-written version of Clinton's JPetstore? If you're standardized on JDBC, you might want to use Spring's JDBC support - which solves many of the problems with JDBC (try/catches, closing connections, etc.).

What is JBossCache?
A transactional replicated cache for JBoss with and without AOP. A cache for frequently accessed elements: Stateful Session Beans, HttpSession. Caches are used in a number of places in JBoss - this one provides a central cache service (MBean interface).

AOP Cache
Java is very dumb - Mark hopes the next OO language we use (in 10 years) is more event-driven (i.e. triggers in Java). This is possible today with AOP. In the example below, Joe's state is automatically transactional and replicated. State replicated, synchronized at transaction commit/rollback.

tree.start(); // kick start tree cache
tree.putObject("/aop/joe", joe); // add aop sanctioned object

tx.begin();
joe.setAge(41);
joe.getAddress().setZip(95124);
tx.commit();

Mark says, "HQL - soon to be EJB 3.0 QL". Interesting quote, eh?

PHP PostNuke - wasn't scalable when they first installed it because it hit the database all the time for security information. The Zend PHP didn't have the notion of global variables - so there wasn't a way to build a cache. According to the PHP guys, MySQL was the cache. JBoss re-wrote it all J2EE and now their server is at 5% utilization with an average of 500 concurrent users. Forums are a port of PHP BB - which is a very nice forum software package IMO. Personally, I'd prefer to use PHP BB over JBoss Nukes since most ISPs offer PHP out-of-the-box. I'm guessing that JBoss Nukes only runs on JBoss. Also, PHP BB is much cleaner and prettier out of the box. I'm a sucker for good looking webapps. ;-)

BTW, Jeremy Zawodny (Yahoo guy) has a number of links that might of interest for this conference. For your convenience, here's the best link: the 2004 MySQL Users Conference blog aggregator.

My Review of Java Studio Creator (a.k.a. Rave)

I attended a Rave Demo at Sun in Broomfield today. The meeting actually had two parts - the first hour was a marketing schpeel about Sun's Enterprise Java System and the second hour was a demo of Java Studio Creator. The first hour was boring and very marketing esque - they did have an interesting price point though - $100 per employee. This is small business friendly, which is nice to see.

The Rave (a.k.a. Java Studio Creator) Demo was when things got good. Here's my notes from Dan Robert's presentation, followed by my impressions and comments. Dan is the Product Manager for JSC and was seemed to be very in tune with the tools marketing (i.e. all the good stuff from Intellij and Eclipse - and how JBuilder sucks).

What is it?

• New Java Development Tools initiative
  • For the corporate developers who write code, but don't understand all of the complexity of J2EE and just need to get their job done.
• A full fledged Java IDE
  • Visual Design Tools, 2-way editing, Editor, Debugger, Repository Management, and Project Management
  • Cool new Look and Feel
• Complementary to NetBeans and Java Studio
  • Even Enterprise developers can use it for Rapid Prototyping
  • Use Java Studio or any other tool to add persistence layers (heh, this is b/c they think that persistence can only be EJBs ;-))

What does it do?

• Quickly builds web applications that solve time-critical, real world problems
  • Complete web application creation for departments, workgroups and businesses of all sizes
  • Focus on easy to understand, event driven coding model
  • Simplifies access to existing infrastructure
  • All Java-standards based servers, all databases, all Web services, all desktops
  • Their main goal is to do web applications well, they'll catch up with the rest later

Standards-based solution for all developers

• A development solution based on 100% Java standards
• Delivers "Write Once, Run Anywhere"^TM benefits: portable apps, portable developer skillsets
• Quickly solves time-critical app development needs
  • Drag and Drop, rapid visual access to databasess and web services
  • consistent UI look/feel/behavior across all apps

Visual features to speed development

• Palette for widgets, custom graphics, code clips, etc...
• Query Editor

Simplified Access to Existing infrastructure

• Use any JDBC Compliant Database (3.0)
  • Drag in and automatically create DB connections to data-aware components
• Web Service Consumption
  • Easily pull in existing web services from Enterprise wide solutions or business partners

Java Studio Creator Roadmap

• Hammerhead:
  • 2-tier dynamic content web applications based on JSP and JSF with Page Flow design tools
  • Releases: Early Access Spring 04 (today!), FCS Summer 04 (at JavaOne)
• Thresher:
  • Minor Update Release
  • Focuses on Ease of Development and Stability
• Mako
  • Extended Client Support

Download today from http://www.sun.com/jscreator. OS X version will be available shortly after the release (JavaOne).

After the PowerPoint, Dan started into the Demo. The first thing I saw that was cool was that when he clicked on the "Run" button, it actually deploys the app and opens the browser to run it. What you see in the browser looks very similar to what you see in the IDE. The IDE looks very simple. My current client went with me and he remarked that it "looks a lot like Eclipse."

The IDE has lots of palettes, and the UI essentially looks very clean. The pallets can be docked just like in IDEA - which I like. It looks a lot more like a native Windows application than it does like Swing. Here are the palettes it has:

• Server Navigator
  • Data Sources
  • Web Services
  • Deployment Servers Palette
• User Defined
  • JSF Standard Components
  • JSF Validators / Converters
• Property Sheet
• Project Navigator

Dan then dragged a drop down component and a table component onto the page. Secondly, he added a stylesheet and it visually changed the background and fonts on the page. I asked him if there was an imbedded browser. He said they took a look at using Mozilla, but it was too much and apparently one of the "real smart" engineers wrote the embedded browser component from scratch. Dan said it was the same guy who wrote the demo from scratch in 2 minutes at JavaOne last year. The thing I found very cool was that the HTML that is written into the JSP is XHTML - none of this Netscape 4.x support. Fuck Netscape 4.x - I'm glad Sun had the foresight to drop support for it.

After adding the stylesheet, Dan used the Data Sources navigator to grab a table and drag it to the drop-down. Then he did the same for another table and the data grid. Using the Visual SQL Query Builder (which looks a lot like M$ Access) he linked two tables and added a new column from a 2nd table to the grid. He then showed us that JSC has pretty good support for 2-way editing. Edit the code, the visual representation changes. Edit the visual, the code changes. This seems to be a big problem with WYSIWIG editors, especially when it comes to dynamic webapps. It appears that they've done a pretty good job to solve this.

Next he showed us some cool features of the components. For the table, there is an "enable paging" checkbox - and for the drop-down, you can right-click and select "auto-submit on change." He then set a couple of converter types on the drop-down and had to hand-code the event handler for the drop-down. Two lines of very simple code and he was done. The code was simple enough that you could have guessed the syntax. Code completion popped up nicely as well. Apparently the JSF coding style is that each page (JSP) is backed by a Bean that contains different event handlers. The code looked pretty simple and all the data was retrieved via RowSets.

Bill Dudney was there and asked about testing tools (i.e. Cactus or JUnit). Dan's response was that these are usually used by more advanced Java developers and there's talk of it, but nothing has been done yet. Now he pulls up a very cool page navigation creator which he uses to drag and drop buttons and links to point to different pages. Then someone asked about cost - and here's what makes it great. Under $300. They also hope to have lots of add on components for JSF by JavaOne. Unfortunately, there's no tooling for building JSF components in Java Studio Creator. For more information checkout http://developers.sun.com/jscreator.

The main reason I really like Java Studio Creator was that you literally never had to see any JSF code - and you get all of the features I like to use in webapps. Furthermore, I've been training a couple of guys all week on JSPs and using JSTL's SQL tags to do CRUD on a database table. While it's simple stuff, since they've never done web development before, it's a bit advanced. I'm sure their eyes will glaze over tomorrow when I start showing them how to write JUnit Tests, DAOs and how to use Hibernate to CRUD an object. They'll probably fall asleep by the time I show them how to wire the DAOs to Hibernate using Spring. When they saw this demo today - there eyes lit up and they got inspired to do their projects again. It looks easy for them now. All they need is a JDBC 3.0 driver for DB2 and they should be able to rapidly develop webapps with Java Studio Creator. I don't blame them for wanting to use this tool - it greatly simplifies things.

After the meeting, I asked Dan about transactions and if it was possible to use Hibernate instead of the RowSet stuff. He said that since JSC is based on NetBeans, you could probably write a plugin to use Hibernate instead of RowSets. As far as I know, the main reason you'd use Hibernate is for caching - but rowsets probably have that too. I know that the spec lead for JSF is talking to the Spring developers about JSF-Spring integration, so maybe that will be a future option as well.

Another thing that's not currently supported is the use of great technologies like Tiles or Sitemesh. Sitemesh integration would likely be pretty easy - you'd just never see your decorated UI in the IDE. Tiles is definitely something on the roadmap, but they don't have a solution yet. Dan indicated that using "includes" in your JSPs should work just fine - rendering in the IDE as they would in your browser. Good stuff - I hope we start using it at my current project - I think it'll do wonders for productivity. Since it's based on standards (JSF and RowSets) - the generated code looked pretty clean too.

Make your JUnit Tests run faster when using Spring

JRoller is down, and has been down for an hour or so - so I've decided to post this Spring Live entry here.

I discovered an interesting thing today about Spring and my JUnit tests. I noticed that the VelocityEngine I was setting on my PositionManager was getting initialized once for each test* method in my Test. This means that since my PositionManagerTest has 10 test methods - it would load the context 10 times.

Loading the context so many times was because the following code was in my Test's parent's constructor:

    ctx = new ClassPathXmlApplicationContext("/applicationContext.xml");

I suppose I expected any constructor-iniatialized variables to be initialized once and only once. So I figured out a solution to make my JUnit tests run faster. By making the ctx variable static, and loading the file in the member variables definition, I greatly reduced the amount of time needed to run tests. Below is the new code I'm using:

    protected static ApplicationContext ctx = 
    	new ClassPathXmlApplicationContext("/applicationContext.xml");

By doing this, the ApplicationContext is only set once, and my tests run much faster. Here's some performance comparisons from Struts Resume:

Average time to run "ant test-dao": 36 seconds
Average time to run "ant test-dao" after this change: 26 seconds

A 10 second improvement - that's crazy talk dontcha think?! I've tried it on single tests, as well as suites - and it seems to improve performance by approximately 30% across the board.

Because of this experience, I have to recommend that when you write JUnit tests that use Spring - you should initialize your ApplicationContext in a static member variable. It seems to be the best performing and logical choice. Of course, if I'm off my rocker - please let me know.

On a sidenote, it would be cool if Roller allowed me to turn off comments for a single post. I like how Simon posts stuff on java.net and then aggregates it to his personal weblog.