Friday January 06, 2006

Running Spring and Hibernate on Geronimo 1.0 Category: Spring Live

Since Geronimo 1.0 was released this morning, I decided to try it out. Unfortunately, I found that it doesn't work out-of-the-box with applications that use Spring and Hibernate (namely Equinox and AppFuse). Luckily, I work with Jeff (The Geronimo Guru) and got to harass him today with "Geronimo Sucks!".

Of course, he took that to heart and figured out the solution. First of all, here's the errors I got:

16:00:02,726 ERROR [[/equinox]] Exception sending context initialized event to 
listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanDefinitionStoreException: Error registering 
bean with name 'transactionManager' defined in ServletContext resource [/WEB-INF/
applicationContext-hibernate.xml]: Class that bean class 
[org.springframework.orm.hibernate3.HibernateTransactionManager] depends on not 
found; nested exception is java.lang.NoClassDefFoundError: org/hibernate/HibernateException
java.lang.NoClassDefFoundError: org/hibernate/HibernateException
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:242)

After telling Geronimo to load Spring from my webapp instead of the server JARs, I received a 2nd error:

ClassNotFoundException: org.hibernate.hql.ast.HqlToken [from org.appfuse.model.User]; 
nested exception is org.hibernate.QueryException: ClassNotFoundException: 
org.hibernate.hql.ast.HqlToken [from org.appfuse.model.User]
org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.ast.HqlToken 
[from org.appfuse.model.User]
        at org.hibernate.hql.ast.HqlLexer.panic(HqlLexer.java:57)
        at antlr.CharScanner.setTokenObjectClass(CharScanner.java:340)
        at org.hibernate.hql.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:31)
        at antlr.CharScanner.<init&rt;(CharScanner.java:51)

Excluding antlr from being loaded by Geronimo fixed this problem.

So now for the goods. To deploy your Spring+Hibernate application on Geronimo, add the following to your deploy plan:

    <hidden-classes><filter>org.springframework</filter></hidden-classes>
    <hidden-classes><filter>antlr</filter></hidden-classes>

Here's the geronimo-web.xml (goes in your WEB-INF directory) I've been using for Equinox.

<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0" configId="equinox">
    <hidden-classes><filter>org.springframework</filter></hidden-classes>
    <hidden-classes><filter>antlr</filter></hidden-classes>
    <context-root>/equinox</context-root>
    <context-priority-classloader>false</context-priority-classloader>
</web-app>

Of course, you'll need to replace "equinox" with your application's name. This has been tested with Hibernate 3.0.5 and 3.1, as well as Spring 1.2.6. (2006-01-06 18:17:20.0) Permalink Comments [5]

Tuesday January 03, 2006

Spring Live is too big for Print on Demand Category: Spring Live

From an e-mail Matt Filios sent today:

Bad news. The max book size for Lulu is 740 pages. The recent update
comes in at a hefty 780. The bottom line is we need to cut 40 pages
for the next print on demand.

My reply:

Ain't gonna happen. We need to get Lulu to up their dimensions b/c I
have two copies of the book - before Lulu and after Lulu and the first
is 1/2 inch think whereas the 2nd is more like 1 1/2 inches thick. I've
never liked the Lulu books - they're smaller (in height and width) than
most technical books and they won't stay open when you lay them flat on
a desk.

Final e-mail from Matt:

You have two choices; cut 40 pages for the 6x9 books, or we go to 8.5 x 11 
books with them.
I have recommended that they go to 7.5 x 9.5, which is standard technical
book size, but until they get more demand than from just little old
SourceBeat, they ain't changing.

What do you think? Should I trim pages 40 pages or move to a larger book? The problem with trimming pages is it leaves no room for future chapters. As far as the larger book - it'd be interesting to see what that looks like.

Update: After some thought, I think the best thing to do is for all of you to send an e-mail to Jeremy Hogan at Lulu requesting that they support 7.5 x 9.5. (2006-01-03 22:53:22.0) Permalink Comments [7]

Friday December 30, 2005

[ANN] Spring Live 1.7 Released Category: Spring Live

Spring Live version 1.7 has been released. Get it while it's hot! Download or view the Release Notes. See you in 2006! (2005-12-30 16:55:04.0) Permalink Comments [2]

Thursday December 29, 2005

Spring Live Review on ADTmag.com Category: Spring Live

Matt Stephen's has written up a nice review of Spring Live:

So, overall? It's well written with clear examples, and provides a nice, broad introduction to Spring. Recommended.

Thanks Matt! I realize this review was written almost 6 weeks ago - that's how backlogged my inbox is. ;-)

As far as a status on the next update for Spring Live? I'm pushing for a release (Chapter 7 updates) by this weekend. (2005-12-29 18:40:21.0) Permalink Comments [1]

Wednesday December 14, 2005

What's new in Spring 2.0's Persistence Support? Category: Spring Live

If you're anxious to see what's coming in Spring 2.0 persitence support, you should check out Thomas Risberg's New Persistence Features (PDF) presentation. This presentation has information about EJB 3.0 support, as well as named parameters in Spring JDBC.

The interesting thing is Thomas presented this at the first Philadelphia Spring User Group meeting. I spoke with him at The Spring Experience and he said that over 50 people showed up for the meeting. I wonder if there's that many Spring enthusiasts in Denver? (2005-12-14 16:27:39.0) Permalink Comments [0]

Saturday December 10, 2005

[TSE] Best coverage of The Spring Experience Category: Spring Live

Patrick Peralta has been doing an awesome job of covering The Spring Experience conference. If you want to know what's going on at the show, look no further than his blog. Well done Patrick.

I arrived back in Denver a couple hours ago, the weather's not too bad - 48 F (convert) and sunny. It's definitely not as warm as Florida, but it's nice to be home. The Spring Experience was one of the best conferences I've ever been to. Jay did a helluva job of putting together a good show, in an awesome hotel. I had a great time meeting a whole slew of Spring enthusiasts, as well as the guys who make Spring work. The community as a whole owes these guys a big thanks - they've done incredible work with Spring, all in an open source environment.

The best part of the whole conference is that it showed there's still lots of reasons to get excited about Spring - as well as many new reasons. I can't wait to get started with new 2.0 stuff, as well as play a bit more with Laszlo and Spring. All the things that didn't work in my demo on Thursday are working now. I hope to write up an article in the next few weeks that describes how to integrate the two. In addition, I'm thinking about doing the talk at Boulder's JUG this Thursday. If that's something that interests you (and you're local), let me know. (2005-12-10 16:04:44.0) Permalink Comments [0]

Friday December 09, 2005

[TSE] WebWork and Spring with Matthew Porter Category: Spring Live

I'm sitting in Matthew Porter's session on WebWork and Spring. This talk covers WebWork, its IoC container, WebWork 2.2 (a.k.a Struts Ti) and Spring, + XWork's Validation and Spring. The current version of WebWork is the 2nd generation of WebWork and yes, it does compete with Spring MVC. That might be the reason there's only 12 people in the room. We did a survey during the expert panel yesterday and most of the audience was using Spring MVC, which you kind of expect at a Spring conference.

WebWork is a wrapper on top of XWork, which is a generic command pattern framework. It's still up for debate, but it does look like it's going to be the future of Struts. Two of the cool features in WebWork 2.2 are prototyping (with QuickStart) and continuations.

One of the best parts of WebWork is that it can work with your domain objects, just like Tapestry, JSF and Spring MVC. Struts is the only framework that requires you to create extra "forms" for your web tier. One of the advantages of WebWork over Spring MVC is you don't have to register PropertyEditors for converting Strings to complex objects (Dates, Longs, etc.). Conversion is done automatically, and it creates subclasses for you if you try to set properties on them.

OGNL is used for the expression language and type conversion. It should be interesting to see the Struts community's reception of OGNL - especially since many developers are used to using JSTL instead. WebWork supports many view technologies (much like Spring MVC): FreeMarker, Velocity, JasperReports and XSTL. WebWork uses XWork's validation framework, which allows you to use OGNL expressions in XML. Also, Matthew has mentioned it's possible to integrate with Spring - I don't know if this means you can use XWork's validation with Spring MVC or if you can use Spring's Validators with WebWork.

The core concepts of WebWork are your Actions are POJOs, much like JSF managed-beans. However, JSF beans are a bit more pure because they don't require you to extend or implement anything. WebWork requires you to extend ActionSupport or implement Action. Regardless of which one you use, it's likely you'll implement an execute() method:

With WebWork, there are no "form beans" and Actions can be the model. This means that you can put getters and setters on your action (for your POJOs) and WebWork will take care of getting and setting their values. Another powerful feature of WebWork is Interceptors. They provide "AOP Lite" for Actions and they make up most of the core of WebWork. As an interesting sidenote, WebWork 2.2 has moved from a front-controller servlet to using a ServletFilter. I believe RIFE uses a filter for it's front controller as well.

The core concepts of WebWork include results (similar to ActionForwards), a ValueStack, exception mapping (new in 2.2), and everything is configured in /WEB-INF/classes/xwork.xml (similar to struts-config.xml). In addition, WebWork has its own IoC container. However, in WebWork 2.2, they've deprecated their IoC container in favor of Spring. Now that WW 2.2 is becoming Struts Ti, the Spring integration brings up an interesting problem. One attendee mentioned that Struts is certified by IBM, so they can easily use Struts Ti on their projects. However, since Spring is not certified - if it's the required container, IBM developers won't be able to upgrade. Sounds like the solution to me is to get Spring certified by IBM. ;-)

At this point, Matthew is going through lots of code samples, which I won't regurgitate here. If you're interesting in seeing a side-by-side comparison of Struts (or Spring MVC) vs. WebWork - you can checkout Equinox or AppFuse. The WebWork install is available in the extras/webwork directory of both projects. To see how to integrate WebWork (versions < 2.2) with Spring, see WebWork's Spring Integration documentation. The recommended strategy in 2.2 is to specify your webwork.objectfactory, as well as your autowiring mode. More details on enabling Spring integration in WebWork 2.2 can be found on WebWork's wiki.

One of the biggest value-adds that XWork's IoC framework has had over Spring is that XWork's allowed objects to be injected into the session and request. However, with Spring 2.0, you can do DI of objects into the session and request. To see how, checkout Spring Session Components Workarounds. Two other things that Matthew mentioned where a way to hook into XWork's validation system using Spring's Validator interface. In addition, he mentioned that he's working with the Acegi guys to get features in Acegi Security that allow WebWork to work with it better. From the way Matthew was talking, it sounds like he's a committer on the Acegi Security project.

Good stuff Matthew - would've been a lot better if you had a bell. ;-) (2005-12-09 16:24:38.0) Permalink Comments [3]

Thursday December 08, 2005

[TSE] Spring Agile Development Challenges by Keith Donald Category: Spring Live

After my OpenLaszlo + Spring session (PDF) this morning, I attended Keith Donald's session on the "common-build" system that Interface21 uses. Currently, the Spring Framework project has a single module that they load up in IDEA or Eclipse for development. Because the project is 165,000 lines of code, it can take quite some time to compile the whole thing.

From working on such a large project (and many others), Keith (and Colin I believe) have developed a common-build system. This is something they'll probably use to re-work how Spring is built. Instead of building as one module, they'll separate everything into separate modules (spring-aop, spring-dao, etc.). The fact that they are planning on doing this explains why there were "crickets" when Carlos Sanchez offered to re-work Spring so it could be built with Maven 2.

The system that Keith described looks pretty cool. It's basically based on Ant and Ivy. It also consists of many common Ant XML files that you include in your project. This allows you to easily build/test/deploy a project using only 10 lines of code in a build.xml. The system looks pretty cool - especially because it supports transitive dependencies. In addition, it strips off version numbers for your - so your Eclipse project settings don't have to change.

The major reason they're using Ivy over Maven 2 is because Ivy was more mature when they started building this system. They said they might look at M2 in the future, but currently Ivy is suiting their needs quite well. I spoke up and recommended they wait a few months before looking at M2 - the metadata and POMs are just not there yet. Granted, I've filed a lot of bugs for POMs and they've fixed many of them. However, to build a reliable system - the process of keeping POMs up-to-date needs to be maintained by a dedicated user of the various open source projects, or (ideally) by the projects themselves.

I've heard a lot of good things about Ivy and it's definitely something I plan to look at in the future. The common-build system looks pretty good - almost good enough to use for Equinox or AppFuse. However, I don't like the idea of requiring a 2nd package for building - Ant or Maven 2 should be "good enough" IMO. Maybe it can be made into it's own module and downloaded at build-time?

If you'd like to use "common-build" in your own projects, you just need the common-build directory, as well as a project template or two. Keith is using this system at Interface21 and w/in Spring. I don't believe it's used in the main project, but it is used in Spring Web Flow. Keith says it's currently available in CVS, but I'm not sure where. Someone in the audience asked about documentation and Keith said it's pretty good - currently in the form of README.txt files in the different directories.

After Keith finished, Christian Depuis (from Accenture) got up and talked about Spring IDE. This was mostly a demo of how you can use Spring IDE, as well as some discussion about the project itself. Christian was somewhat surprised at how many Spring demos he's seen, and no one is using Spring IDE. IMO, this is likely because you don't really need it - Spring's XML is pretty easy to write w/o code-completion. IDEA 5.0.2 has support for Spring in it's XML editor, and I saw Rob Harrop using it at last night's keynote. (2005-12-08 12:36:40.0) Permalink Comments [1]

The Spring Experience: Rod Johnson's opening Keynote Category: Spring Live

I'm sitting in Rod Johnson's Keynote at The Spring Experience, which is a very well-attended show. It looks like the room is full and they couldn't fit in any more people if they tried. I heard rumors of 275 attendees, which is a lot more than the (rumored) 150 at Java in Action. Below are my notes from Rod's Keynote.

Spring is the most powerful technology for enabling POJO-based application development. Spring had it's first public drop of code right before TheServerSide Symposium in 2003. Since then, Spring is widely adopted across most industries and proven in many demanding applications. Spring is established in the enterprise space, including Banking, Government and Airline industry. Most of Interface21's customers are in the banking industry - so it's become quite prevalent in companies that require extreme high availability, precision and reliability.

How did we get here?

Spring first began in 2002, from Rod's Expert One-on-One J2EE book. This book was released in November, and was quite controversial b/c it said that J2EE was difficult to develop with. In February 2003, Rod and Juergen decided to open source the framework on SourceForge. Juergen produced a huge part of what Spring is today. The community for Spring began on the Wrox forums in late 2002. Juergen was very active on the forums and submitted many ideas for improvement. Rod thought he was all talk at first, until he did a massive commit shortly after Spring was open sourced.

Spring 1.0 M1 was released in August 2003, and 1.0 was released in March 2004 - on the first day of Spring. One of the reasons Spring took so long to get from M1 to 1.0 was because of quality and documentation. They wanted to take the time to make an excellent product before release it. From August '03 until March '04, there was a huge amount of users - especially for an unreleased product. The core concepts and non-invasiveness allowed many people to use it and develop their apps using code from CVS HEAD.

J2EE without EJB was released in July 2004. It provided the architectural basis for using Spring. 1.1 was released in September 2004. The first Spring Web Flow release (Preview 1) was released in March 2005. Spring 1.2 was released in May 2005 and this has all lead to The Spring Experience - organized mostly by Jay Zimmerman and Keith Donald.

Nice job Jay and Keith - this looks to be an excellent conference!

Rather than calling the next release of Spring 1.3, the Spring Team has decided to call it Spring 2.0. The code for the first milestone release (M1) will be released at this conference, or shortly after (before you're at your desk on Monday). Numerous major enhancements and new features, especially:

• Simpler, more extensible XML configuration
• Enhanced support of AspectJ
• Scoping for beans: backed by HttpSession, pluggable backing store (not tied to web tier) and is currently used by Sony (major Spring users)
• Customizable task execution framework for asynchronous task execution
• CommonJ TimerManager implementation (good for WebSphere and WebLogic users)
• Message-driven POJOs - support for asynchronous reception of JMS Messages
• Configuration simplification
• SimpleJdbcTemplate: designed to take advantage of generics, varargs and autoboxing on Java 5

Domain objects are an area for possible enhancement - getting away from anemic domain model. Having so much in the service layer is not such a great thing for OO. This will allow you to do User.save(), User.delete() and such on your POJOs.

Do you need Java 5 for this new stuff? No, but you'll get an increasing amount of goodies if you are using Java 5. Spring 2.x series will run on Java 1.3+. 2.x will continue to run on all leading application servers and web containers (or w/o any other container). Spring will continue to support 1.3 based on user demand.

What did we get right?

• POJO model: proven, productive, increasingly imitated, looking even better over time.
• Understanding that it was possible to simplify without sacrificing power.
• Apache License: supports strong communities and does not lock out large vendors

"You need to have vendors involved in open source software if it's going to be successful long-term in the enterprise."

What can we do better?

You spoke, we listened:

• Configuration can be (even) simpler (2.0 M1)
• AOP can be simplified for everyday users, and enahcned for power users (2.0 M1)
• We can harness ease of use of Java 5 (2.0 M1/M2)
• Spring MVC can be easier to use (2.0 M2)
  • Tag Libraries
  • Convention over configuration

Now Rob Harrop is on stage giving a demo of the XML Namespaces feature added in Spring 2.0. Rather than having a DTD at the top of your Spring configuration file, you'll have something like the following (I was unable to capture all the namespaces):

    <bean xmlns="http://www.springframework.org/schema/beans"
             xmlns:aop="http://www.springframework.org/schema/aop"
             xmlns:jndi="http://www.springframework.org/schema/jndi"
             xmlns:tx="http://www.springframework.org/schema/tx">

The problem with the current DTD is that there's no validation of the required properties. Rob is doing a demo with IDEA, and he's written a "dataSource" bean with a JNDI Lookup - and he only typed the following:

    <jndi:lookup id="customDataSource" jndiName="jdbc/MyDataSource"/&rt;

The strong typing gives you code completion of properties, as well as data types. Below are some pictures I took of the new syntax:

Part of 2.0 will be a way to build your own tag definitions - so you can create domain-specific XML languages for your applications. Hopefully this system will eliminate the need for things like XSLT and XBeans.

Spring and the Community
Different communities are served by Spring:

• Conservative users: well-tested, robust framework they can trust
• Early adopters: the future, right now

The goal with Spring 2.0 is to make both types of users happy. In addition, you can depend on the Leadership of Spring - they've been contributing top notch code for quite some time, and they're not going anywhere. Spring has innovation and continuity (backwards compatibility is at the top) and community input is valued. There is a important emphasis on respect for Spring users on the forums.

A Leadership Example: Roadmap for AOP

Spring AOP is the most widely used AOP technology today. AspectJ is the most powerful AOP technology and it's natural to combine the two. In October 2005, AspectJ lead Adrian Colyer joined Interface21. He's currently working on both Spring AOP and AspectJ. He's not meerely a leading practitioner, but an important AOP thought leader. His blog (The Aspects Blog) is at http://www.aspectprogrammer.org/blogs/adrian.

Why is this important? Because Spring users benefit from AspectJ:

• Spring AOP gains the AspectJ pointcut expression language
• Spring AOP gains @AspectJ syntax

And AspectJ users benefit from Spring:

• AspectJ gains Spring DI (has been supported since Spring 1.1)
• Spring DI gains AspectJ, including the ability to dependency inject domain objects

Come to the Friday Keynote or an AOP session to learn more. There's a 9 a.m. session tomorrow. As a preview: you can use the AspectJ pointcut expression language to increase the power of Spring AOP. This is still done at runtime (it's still Spring AOP), and you can also use XML or with a ProxyFactory. You can also use AspectJ Annotations in your Spring classes and they'll be processed by Spring. The nice thing about this is your aspects can be used in Spring, or w/ AspectJ.

How it all comes together

Spring 2.0 features work together - it's more than the sum of its parts. It has an extensible, simplified XML mechanism - which makes AOP easier to use, and opens up new possibilities. The scoping support has existed in the sandbox since July, but it was difficult to use. You had to write a custom FactoryBean. But with 2.0, you can use the XML simplification and it's much easier to use.

"But I don't want to go to the bleeding edge..."

Spring 2.0 combines proven technologies (Spring IoC and AspectJ). It delivers features demanded by customers. It ensures backwards compatibility (your existing Spring apps will work). All of 2.0 is implemented on a strong underlying infractucture. Therefore, you only have to use the bleeding edge if you want to. All the current features of Spring should work w/o changes in Spring 2.0.

Spring 2.0: What breaks?

Nothing.

Of course, some things might break - but Rod can't think of anything significant will. It should be a drop-in replacement for 1.x JARs. This really goes to show the value of a non-invasive POJO programming model. There will be some changes in best practices, but you are not forced to change anything.

This should be the norm, but hasn't been so in enterprise Java.

Alef just did a demo of migrating JPetstore from 1.2.6 to 2.0. He copied the 2.0 JAR over the old one and redeployed to Geronimo 1.0 M5. After proving everything worked (in a browser), he changed some of the XML syntax and redeployed. Again, everything worked as expected.

Consistency and continuity

Spring has remained remarkably consistent to its initial vision: POJO based development, portable and productive. It's progressively realizing more of its goals.

Not done yet: JavaSpaces integration, POJO model for asynchronous programming. It's not officially on the roadmap, but it's the kind of things they're thinking about.

At this point, Keith Donald did a demo of Spring Web Flow using a pre-recorded demo. It was very well done and showed how far Spring Web Flow has come in the last 6 months. It looks *very* easy to use now, and you don't even have to write any Controller/Action code for the most part. The next time I need multi-page transactions, I'll definitely be using Spring Web Flow. I hope to find time someday to re-work Struts Resume using SWF.

How Healthy is Spring?

Adoption in all market segments. It's Rod's 2nd trip to the US in 3 weeks. It's particularly strong in banking: Wall Street and London Financial Institutions.

Analyst conclusion (Forrester): A majority of users interviewed by Forrester use Spring and perceive Spring to be very high quality.

Business Environment: Still wider adoption. There are now services available to underpin adoption: Training, Support, Consultancy and an availability of employee skills. Interface21 has grown from 5 to 20 employees in 2005 alone.

Timelines: 2.0 M1 by December 10th. Spring 2.0 Final solid and robust by March 2006.

What's next for enterprise Java?

Will there be an end to the anemic domain model?

• Dependency Injection in all layers, including domain objects
• @SpringConfigured - Spring 2.0 M1 provides it, now well all need to learn about its potential

Scripting languages on the JVM? There is initial support in Spring 2.0 M1.

"What happens next is up to you."

For more coverage on tonight's keynote, see Craig and James' blogs. (2005-12-08 00:30:45.0) Permalink Comments [7]

Monday December 05, 2005

How to upgrade from Acegi Security 0.9.0 to 1.0 RC1 Category: Spring Live

Acegi Security 1.0 RC1 was released last night (release notes). I spent a few minutes upgrading AppFuse to this latest version. For those interested, I filed an issue and attached a patch.

Unlike the 0.9.0 release (released 3 weeks ago), this release requires significant changes for existing Acegi users. Here's the major things I had to change:

• Find/Replace "net.sf.acegisecurity" to "org.acegisecurity".
• The UserDetails class has moved is now located in org.acegisecurity.userdetails.UserDetails.
• The DaoAuthenticationProvider (usually named daoAuthenticationProvider in context files) changed its authenticationDao property name to userDetailsService. This change effects the TokenBasedRememberMeServices class as well.
• The JdbcDaoImpl class has moved into the new "userdetails" package at org.acegisecurity.userdetails.jdbc.JdbcDaoImpl.

Hopefully this will help others upgrade their Acegi-lovin' applications. Now if we could just get them to mark all their dependencies as optional in their Maven 2 pom.xml ;-). (2005-12-05 10:18:09.0) Permalink Comments [1]