Raible Designs

Acegi Security adds OpenID support to its sandbox

From the Acegi Security mailing list:

Thanks to the efforts of Robin Bramley; we now have a first draft of OpenID support in the sandbox. The code is mostly as-is from when Robin submitted sent it to me. I've done all the standard jalopy formatting of the code so it blends in and has the proper file headers.

I don't know how much this will help folks developing intranet applications, but it's pretty cool for those doing otherwise. Anyone want to take a stab getting OpenID working with Roller? It uses Acegi and supports SSO, so hopefully it won't be too difficult.

See Timothy M. O'Brien's writeup as well as Ray Krueger's for more information.

Sonatype - a new company around Maven

From Jason van Zyl's Maven Diaries:

Since my departure from Mergere I've been quietly and steadily working to help start a Maven related company that I'm proud to say I'm a part of. No grandiose launch, no marketing hype, no VCs, haven't talked to a single analyst, and we hope that you can actually understand what we do by looking at our website. The company's name is Sonatype and I'm finally happy with the people involved and the direction we're headed in. We are focused on facilitating the adoption of Maven through our partners network, providing training, and delivering Maven related products for software development.

Having two companies wrapped around Maven can't be a bad thing. However, let's hope Sonatype has some funding to pay folks to work on the project more, rather than other products that may or may not be successful.

Two things that could make this company very well liked in the open source community:

• Clean up the Maven Repository: Add/delete/modify as requested by users. There's other projects using the repo now and even folks campaigning against Maven. If Maven folks are responsible for cleaning it up, they'll be heroes.
• Provide repository statistics: A lot of open source projects like to track their download statistics. It's a metric for measuring success (in addition to mailing list traffic). If they move to a full Maven-based distribution model (like AppFuse is), there's no more statistics.

Are there other things you think Sonatype can do to make Maven easier to use and more successful?

Congrats to Neel, Jason, John, Kenney, Andrew, Eric and Eirik. I hope you succeed in your mission. I think w/o the VCs and the get-rich-quick folks, it should be a lot easier. Cash isn't always the key indicator of success - more often happiness and job satisfaction are.

OSCache vs. EhCache for Hibernate's 2nd Level Cache

Hibernate has a number of options for configuring its second level cache. For more information on configuring this, you might want to read John Ferguson Smart's article titled Speed Up Your Hibernate Applications with Second-Level Caching.

Up until today, I thought EhCache was the default cache provider, but apparently not anymore. From Hibernate's documentation:

Note that versions prior to 3.2 defaulted to use EhCache as the default cache provider; that is no longer the case as of 3.2.

So what's the default now? It can't be Hashtable since that's not for production use. I doubt it's OSCache since OSCache can't even get its patches into Hibernate. Looking through the release notes, I found out it's NoCacheProvider - seemingly because of an issue with EhCache:

Due to the upgrade to EhCache1.2 and its new non-singleton cache setup, we should no longer default the cache provider to be ehcache. Instead, default to NoCacheProvider.

That's reasonable I guess. EhCache added support for distributed caching in 1.2. It's a shame they didn't maintain backwards compatibility or they'd still be the default caching provider. Regardless, it doesn't matter who the default caching provider is because it's very easy to change it. Here's how it's configured on one of my projects:

<bean id="sessionFactory" 
    class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="configLocation" value="classpath:hibernate.cfg.xml"/>
    <property name="hibernateProperties">
        <value>
            hibernate.dialect=${hibernate.dialect}
            hibernate.query.substitutions=true 'Y', false 'N'
            hibernate.cache.use_second_level_cache=true
            hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider
        </value>
    </property>
</bean>

Of course, you can also configure it directly in hibernate.cfg.xml or a hibernate.properties file.

This leads me to the reason for this post:

What is the best 2nd level (clustered) cache to use for Hibernate?
I'm sure some folks will say Coherence, so let's narrow the question to what's the best open source option?

I've used OSCache in the past. It worked well, but it was kind of annoying that I had to patch Hibernate to make it work. The Hibernate folks say it's OSCache's fault, the OSCache guys say it's Hibernate's fault - so this issue will likely never get resolved. So what about EhCache? I don't know, I've only used it in a single JVM environment and haven't tried it in a clustered environment. Is there anyone using Hibernate + EhCache in production that can verify its effectiveness?

Of the options listed in Hibernate's documentation, the only other options seem to be JBoss TreeCache and SwarmCache. You can quickly eliminate SwarmCache since it never made it past 1.0 RC2 in October of 2003.

That leaves JBoss TreeCache, EhCache and OSCache as choices for a clusterable 2nd-level cache. OSCache is an invalidating cache, which definitely works - but might not work as you expect it to. JBoss Cache only seems to allow a replicated cache which also works. EhCache seems to support both. I don't know if invalidating or replicating is better, but I imagine replicating can get quite chatty if you're dealing with large amounts of data.

But wait - is there another open source option? According to Terracotta's CTO, Terracotta is much faster than JBoss Cache. However, if you read about it on DZone, you'll see that JBoss Cache has no "official" benchmarks.

So what's a developer to do? My current client likes OSCache, but I'm leaning towards EhCache. Which would you recommend?

Of course, if Coherence is only $1K per CPU, maybe that's the obvious choice? Unfortunately, I couldn't find their pricing using Google.

JSF still sucks?

Granted, this post about how painful JSF is is almost 6 months old, but I think it's still mostly true.

Want to compare times? More than three man-weeks have been spent fixing silly JSF navigation problems. A full CRUD AJAX interface with Spring MVC and prototype in the same project took four days, and there was no previous experience with Spring MVC.

If you're going to use JSF, I highly recommend Facelets or Shale/Seam. However, those are mentioned as well:

The default view technology is JSP, even when no one in the real world would recommend it; instead, use Facelets, or Clay, or some other non-standard framework. Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'.

IMO, Facelets is very easy to learn. If you know how to program JSPs with JSF, you should be able to use Facelets in under an hour. When we converted AppFuse's JSF flavor from JSP to Facelets, rarely did the body have to change - we just had to change from taglibs to XML namespaces.

When you are not working with persistent data (if you are living in a cave or developing wizard interfaces) there are two scopes to store model state: the session context, which raises concurrency issues and is not recommended by the Faces community, and the conversation/process/whatever context, which is not standard and imply installing shale or seam to put even more lipstick on the pig.

There's two problems with Shale and Facelets - the activity on these projects is very low. Shale still has its creators around, so even while its seldom used, you can probably still get your questions answered. However, Facelets seems to be suffering from "developer abandonment".

Conclusion: don't use JSF simply because it's a "standard". Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.

If you still want to use JSF, you should probably use Seam, but don't simply use JSF because it's a standard. If it was a de-facto standard, that'd be another story.

Of course, you could also help improve JSF 2.0. But that's not scheduled for release until late 2008. I'm sure 2 or 3 commentors will claim we'll all be using Rails or Grails by then.

Ant vs. Maven

I found a good post from Steve Loughran on what's wrong with Maven's repositories. I agree with most of his points, but would like to point out mvnrepository.com. This site seems to provide good XML Feeds for what's been uploaded to Maven's Central Repository. If you're using Maven, you should probably subscribe to its Atom Feed.

In related news, Timothy M. O'Brien has an entry about Steve's upcoming book: Ant in Action. This book is the 2nd edition of Java Development with Ant. I have a hard time believing Erik Hatcher is helping Steve write Ant in Action - AFAIK, he's off in Rails-land enjoying himself. Regardless, I'm sure Ant in Action will be an excellent book. Java Development with Ant is one of my favorite technical books of all time and is largely responsible for inspiring me to write AppFuse. I read JDwA way back in October 2002 and used a lot of its code to develop AppFuse 1.x's Ant-based build system.

Like Tim, I still like Ant. However, AppFuse 2.x uses Maven 2 and most of the projects I work on these days use Maven 2. It may surprise some folks, but I actually like Maven 2 (not Maven 1). Sure it has issues, but after a year of using it in anger, I know how to solve most of its quirks. AppFuse 2.x users will benefit from this greatly and I'm thinking of changing its tagline to "We make Maven work."

One of the most interesting things about moving to Maven is we were easily able to make AppFuse more like a framework than a project starter kit. We thought this is what most folks wanted - especially the ability to upgrade a project to the latest version of AppFuse. While some folks wanted this, it seems like most folks liked the full-source version that was a pain-in-the-ass to upgrade. I don't blame them. On the project I'm on, I'll likely be converting to a full-source version before the project is over. That's why APF-675 exists. I doubt we'll make it happen for the 2.0 final release, but it is on our radar of things to do shortly after. With any luck, we'll create a way to migrate projects using embedded AppFuse to full-source AppFuse.

I'd also like to point out something ironic. With AppFuse 1.x, there were a lot of folks that advocated we move to Maven. Their primary reasoning - the Ant build scripts were too long and complicated. How about a good ol' lines of XML comparison for those folks:

• Lines of Ant-related XML in AppFuse 1.x: 1655
• Lines of Maven-related XML in AppFuse 2.x: 2847

Oh wait, that's not a fair comparison. The above number is for AppFuse in SVN, which end users won't deal with. A new project created with AppFuse 2.x will likely have a pom.xml with 634 lines. That's about 1/3 of the amount needed for Ant in AppFuse 1.x. Maven hasn't exactly gotten us away from XML hell though. How about a LOC count for archetypes vs. installers:

• Lines of Ant-related XML for AppFuse 1.x framework installers: 2786
• Lines of Maven-related XML for AppFuse 2.x archetypes (including archetype's pom.xml files): Too much to count. Creating archetypes is waayyyy too complicated IMO. Basic archetypes seem to be around 740 lines (pom.xml for archetype project, archetype.xml and archetype's pom.xml), modular archetypes are around 870. 740 x 4 + 870 x 4 = 6440. I'm guessing the full-source archetypes will add another 5000 lines of XML. Ugh.

This XML-for-archetypes comparison might be unfair as well. With 1.x, you could only create a webapp, with 2.x, you can create a modular application and chop off the web-portion if you so choose.

Of course, the real benefits of moving to Maven are elsewhere. We've seen quite an uptick on the mailing list in the last few months. There's tools cropping up and I've gotten quite a few inquiries about training (yes, I do have a 3-day course on Spring, Hibernate, Ajax, Maven and AppFuse). To me, AppFuse 2.x seems more complicated than 1.x, but it seems the community thinks otherwise. Judging from the increased amount of developer activity on the project, developers seem more interested in a Maven-based system too. Then again, we are making Maven work!

RE: 5th anniversary of Blogging Roller

From the Blogging Roller himself:

Today is the fifth anniversary of this blog, which I started on April 11, 2002 to promote the Roller blog software that I had just finished writing.
...
Now, five years later, Roller has graduated from the Apache Incubator to become Apache Roller, blog-tech is my full-time job at Sun and I'm still Blogging Roller. Thanks to Roller users and contributors everywhere for helping to make this possible.

Congrats Dave - 5 years is 20 years in Internet Time isn't it?!

It's hard to believe I've been reading Blogging Roller for that long. Thanks to Dave for getting me into blogging and creating Roller. It was his article that got me interested in blogging and inspired me to setup this site. Thanks to Roller, I met Lance, who got Dave and I the Pro JSP deal, which lead me to create AppFuse.

Thanks Dave! I owe you a beer or 12 for all the good things you started.

It's funny to think back when there was only a handful of Java Bloggers: Russell, Dave, Lance, Erik and good ol' Mike. Remember Mike and his "Java blogs" blogroll?

From Vegas to Snow to Boston

Our visit to Las Vegas was a lot of fun. Little did we know, some friends we were meeting there were getting engaged on Thursday night. Of course, the girl (Kim) didn't know, but the guy (Mike) had been planning it for quite some time. We had a great time celebrating with them - as well as at the craps and blackjack tables.

I was planning on staying until Saturday, but Julie made me leave with her on Friday night. Her reasoning was because she was up and I was hemorrhaging cash. I didn't like the idea at the time, but loved it once I slid into my own bed late Friday night.

Leaving Vegas's 90°F temperatures and arriving in Denver's 30°F was kind of a bummer, but the 1" of snow yesterday and today is kinda cool. I leave in a few hours for Boston, where it's supposed to be cold all week. I was hoping for a warm and sunny Red Sox game on Thursday, but with a forecasted high of 40°F it doesn't look like it's going to happen. Oh well, bad weather means I'll probably bill and work on AppFuse more, so it's not necessarily a bad thing.

Happy Easter Everyone!

Update: I just went online to check in for my flight tonight and found out that United cancelled my flight due to "crew legalities" - whatever that means. Orbitz booked me on the next available flight, which isn't until tomorrow morning at 7:00 a.m. Doh!

The good news is I get to spend another night with the wife and kids. Unfortunately, tomorrow is going to be a brutal work day since I won't get on site until 3 in the afternoon.

Candy for AppFuse

Candy for AppFuse tries to easy the adoption and usage of AppFuse 2.0 by adding some eye candy in the form of Eclipse Plug-ins. If you want the power of an integrated set of excellent J2EE tools and frameworks managed from the comfort of your IDE, give Candy for AppFuse a try.

I downloaded and tried out this plugin yesterday. Seems to work quite nicely. See Abel Muiño's blog for more details. Well done Abel!

Vegas, Boston, Amsterdam, Stuttgart, West Palm Beach and Connecticut

I have a hectic travel schedule in both April and May. The good news is it consists of trips for both pleasure and business, so hopefully I won't get too tired of planes. Tomorrow, Julie and I are heading to good ol' Las Vegas. A good friend of mine got us a free room at the Bellagio. Most of my trips to Vegas in the past few years have been for TSSS or bachelor parties, so it should be a lot of fun to enjoy it with my wife. Knowing us, we'll only be in our free room for a couple hours.

On Sunday, I'm heading out to Boston for a week on site at my client's. They wanted me to come out this week, but I convinced them that coming out for the Red Sox home opener was a better idea. I don't have tickets to the game Tuesday, but a good friend has tickets for Thursday and I'll probably go to Saturday's game too. If you have extra tickets to Tuesday's game, let's talk. I'd like to organize a tech meetup while I'm out there, but I probably won't have time. I'll be working long hours Monday - Wednesday in hopes of taking Friday off.

After Boston, I'm home for two weeks, then it's off to ApacheCon Europe. I'm leaving Saturday the 28th, staying in Amsterdam until two hours after my talk on Friday and then heading to Stuttgart for the weekend. I fly back from Europe and head down to Florida for a week's vacation with Julie and the kids. Then I'm off to Connecticut for a week to teach a training class on Spring, Hibernate, Maven, Ajax and all the other fun stuff that developers like to learn.

Phew, it's going to be quite the ride over the next month and a half. I'll try to take a camera and post pictures from all my adventures.

Apache Struts 2 from Square One

Ted Husted has put together an impressive training course together for Struts 2 called Apache Struts 2 from Square One. He's released an initial version of the 127-page PDF on SourceForge.

Thanks Ted! The fact that you're contributing this hard work to the community (for free!) is amazing.

I'm teaching a 3-day training course in May that covers Spring, Hibernate, Maven 2, Ajax and AppFuse. I'm not sure if the client wants Struts 2 or Spring MVC for their web framework. If they want Struts 2, you can be sure I'll checkout Ted's course as a starting point.