sampa : colin’s blog

EclipseCon have graciously offered Spring Framework one of the 10 ‘pods’ in the open-source pavilion at EclipseCon 2006. The closest tie right now between Spring and Eclipse is probably the Spring-IDE plugin for Eclipse (also used as the basis for Spring support in MyEclipse IDE), but you can also expect to see some Spring integration with the OSGI service platform which drives the Eclipse plugin mechanism, and will increasingly built as a general gross component assembly platform. Of course, Eclipse users are aware of Spring simply because they’re using Eclipse as their IDE when building Spring-based apps.

Since we love to spread the word about Spring, and I have a number of much overdue meetings with people in the Bay Area, we decided to accept the offer of the space, and I’ll be manning the pod (tentatively) from 9:30 to 1 and 3 to 5 on Tues, and 9:30 to 3:15 on Wed. Stop by and say hello! Tell me about your usage of Spring, and find out about some of the things coming in Spring 2.0 and beyond.

I find it a little bit distressing how few Java developers understand that using JTA does not automatically get you XA/Two-Phase-Commit capabilities.

Here we’ve got Matt Raible, who really should know better, or at least should not be blogging about it, posting on Two Phase Commit in Tomcat with JOTM and Spring. Somebody flew out to see Matt, and they spent some time setting up a system with TomCat and JOTM, and apparently they went away thinking their app was now XA capable. I wouldn’t want to be using this app in production if they’re depending on coordinated rollback across multiple datasources.

Now it looks like JOTM is getting (it’s in CVS, and part of a new Jonas reelase) XA recovery, but the release version doesn’t. I really welcome a version of JOTM which can do proper XA recovery. It’ll be great to have that option, but until that’s actually available there’s not really much of a reason you’d ever want to use JOTM in a new Spring app deployed in TomCat.

Without the full XA capabilities, the only thing JOTM really adds is making the standard JTA apis available (the UserTransaction and TransactionManager interfaces), but Spring itself doesn’t need those, it can handle non-XA transactions in a very performant and robust fashion with just a local Spring transaction manager like HibernateTransactionManager or DataSourceTransactionManager. Bringing JOTM into the picture will just add overhead and another potential source of problems (certainly in the past JOTM was not the most robust or spec-complete piece of software around, although from what I know it’s gotten a lot better).

Now if you have user code which needs to work agains the JTA apis (without needing XA), that _would_ be a reason to bring in JOTM. It’s just not needed for Spring-only apps. So if you’re deploying a non-Spring app, or perhaps have an app which is partially using Spring transaction management and partially (for legacy reasons) working against JTA, JOTM may make some sense But you still won’t get XA.

Also, aside from the transaction manager, to get proper XA recovery capabilities, your JDBC driver and database itself need to be XA capable. You’re not going to get 2PC with HSQLDB no matter what JTA driver you use…

One note to people looking for 2PC like functionality in a Spring environment, for other kinds of non-transactional data, such as LDAP access. You can actually pretty easily hook into the Spring transaction synchronization, so that for example when a database transaction which writes a partial user record to the db rolls back, you can also do something like a manual rollback (via the synchronization) of the data you wrote to LDAP.

There is by the way a great series of articles on XA and 2-phase-commit, written by Mike Spille, available here. These are truly in depth and well worth reading.

This is pretty big news. Back in November, BEA acquired SolarMetric, makers of the excellent KODO JDO persistence library. I’ve always had a lot of respect for Kodo JDO, as it’s very performant, is very flexible in terms of mapping complex schemas, has excellent error messages, and comes with good tools and excellent documentation. Now BEA have announced, as described in this dev2dev article, that they will be putting out an open-source JPA (Java Persistence Architecture, the persistence half of the EJB3 spec) implementation based on the KODO engine.

For Java developers, this is great news. We already know that the JPA reference implementation, being produced by Oracle, is not going to be a toy; apparently the core engine is 95% based on TopLink, a very capable product. Hibernate has been including JPA preview code for a while. So now, with this addition, by the time JPA is fully finished as a spec, developers will have a choice of at least 3 very capable products, Open JPA (what the BEA Kodo based project will be called), the reference implementation, and JBoss’s implementation, based on the Hibernate engine. Developers can choose the best tool for the job, based in performance, flexibility, general quality level, and product license.

I was reading Diego Parilla’s Spring is not designed for scalability, and simply had to respond. I actually first wrote a comment directly on his blog, but I guess he’s not going to allow the comment to be posted, as some other stuff has appeared but not mine, after a number of hours…

(Edited 20 minutes later: my comment has appeared on Diego’s blog. This entry below is however much more fleshed out. What is funny is Diego’s reply to my comment, where he says, “Spring is good for simple web apps. If you are going to face a complex project, don’t bet your ass only in Spring: do it on Spring + J2EE.”. I say funny because we’ve of course always said that J2EE is a great base specification, and J2EE and Spring are very complementary, with only some of the higher-level APIs (such as EJB) being flawed. A much more detailed treatis on this whole subject area (agile, effective, and performant J2EE-based architectures) is Rod Johnson and Juergen Hoeller’s Expert One-on-One J2EE Development without EJB. )

This is a very confused post. The main issue is that Diego apparently does not realize that J2EE doesn’t necessarilly equal EJB, and that the EJB 3 spec consists of a container spec (Session beans as POJOs, along with pretty weak IOC and AOP capabilities), as well as the separate spec for JPA (Java Persistence Architecture), which is the replacement for the old Entity beans of EJB 2.1. Of course, the various JPA implementations from people like BEA, Oracle, and JBoss, will run inside or outside of an EJB container.

The following statement alone from the blog entry is proof enough that Diego doesn’t realize JPA is usable from Spring: “”"Strictly speaking, Spring is not bad scaling, simply it was not designed to scale. EJB3 is really good simplifying the complexity of developing enterprise class applications, but the new POJO entities are really good not only simplifying the development, but hiding the complexity of clustering data to the developers. This is why I see EJB3 as a winner.”"”

Of course, in terms of scaling data across a cluster, both an EJB 3 solution and a Spring solution would be working with JPA (or another persistence API) to persist “POJO entities” (as Diego calls them; most people would talk about “transparent persistence for the domain layer) and have the same data scaling mechanisms available, including something like Tangosol’s Coherence product working as a second level cache behind JPA. Both the EJB and Spring solution would have access to a ‘transparent’ data clustering library such as TerraCotta’s, although I would make the case that usage of AOP-based libraries in the Spring case would normally be easier since the Spring app can run in any environment, while an EJB 3 app needs to run in an EJB 3 environment, with some classloading and other constraints enforced by that environment.

On the question of scaling access to POJO services, the general concensus is that a stateless service layer, duplicated horizontally, (and sitting behind a load balancer) is the most scalable approach. (State then lives in the database, or a clustered cache as per the above paragraph). Both Spring and EJB 3 facilitate this scenario, although Spring will give you more choice as to a deployment environment, including simple J2EE servlet engines if that’s all you need. Now if there is an actual need to cluster stateless services at the level of invocations between those individual services (and there’s not much of a case for this), this can be easily done outside of an EJB container by using something like WebLogic’s T3 protocol. Of course, you can also depoy the Spring app to a full EJB container and take advantage of EJB remoting. The point is, there is no disadvantage to using Spring here, anywhere EJB-only apps can get clustering for services, so can Spring-based apps, along with some environments that the EJB ones can’t.

Part of Diego’s ammunition seems to be Bob Griswold’s statement here that with regards to “some of these freameworks”, “In some respects, they actually make the task of scaling out harder than it would have been if the application were written with full J2EE specifications and run within an expensive, mission critical application server like WebLogic Server.”. Now Bob needs a good spanking (he should really know better) for mixing two completely separate things: was the app written to the full J2EE specs (as he puts it, and it’s undefined what this is, but presumably a full EJB 2.1 or EJB 3 based architecture, as opposed to a POJO/J2EE Spring architecture)? and what environment is it deployed in? I will make the claim that (as per the points above), in the same enviroment that an EJB 2.1 or 3.0 based app can run, a Spring app can scale out at least as easily as the EJB 2.1 or 3.0 app. It will also scale out very nicely, thank you, in some environments where EJB apps fear to tread…

The problem with Diego’s post and others like it is that it has a fairly inflamatory title, but there is no real substance there, and ultimately misunderstanding of the products he’s talking about. J2EE and Spring are not competitive in nature. The base J2EE spec is a great spec, and Spring allows you to build great architectures upon it. Spring will also leverage fully the persistence portion of EJB 3, i.e. JPA. Now the value proposition for the container portion of the EJB 3 spec is much more mixed. It’s generally conceeded that EJB 2.1 is a failed container model (hence the complete redesign for 3.0), and 3.0 is bringing in an IOC container and AOP functionality that in terms of functionality is for the most part not even at the level offered by Spring 1.0, but ultimately, if people choose to use the EJB 3 container they’ll be able to get value from Spring even there… And they’ll be able to get scalable apps

Some more comments on this in Call Me Pedantic – What Exactly IS Scalability? and What Is Clustering About – An answer to Spring is not d
esigned for scalability.

A couple of years ago, I used Groovy a decent amount for database ETL (Extraction, Transformation, and Loading) work with an ongoing project. This weekend I had occasion to do more of the same sort of work and see how the Groovy experience has changed…

Basically in the project two years ago, we versioned the DB schema along with the source code. So for every milestone and regular release of the product, there was an Ant-driven Groovy script which would suck in the data in the old format, slice and dice it a bit, and write it back out (usually updating the schema appropriately in the process). (I also used scripts done in Java and Spring+iBatis when that made more sense).

Using Groovy in that old project was overall a positive experience, but I have to say that it was incredibly frustrating w/respect to error reporting. There were a number of bugs in the language parser, along with ambiguities in the language. This was combined with useless error messages. The net result was that it was incredibly easy to make an innocent syntax error and get back a completely useless error message. It was also pretty easy to type what should have been perfectly legal constructs and get back a non-informative error.

This weekend I needed to make a script which would go into the database for the Spring Framework support forums, now running on vBulletin, look for out-of-date (bad) phpBB-format links to other posts (we used to run phpBB), and then do some queries to match those up to the proper new posts in vBulletin, to output to a file. Using Groovy for this task was a really pleasant experience. The SQL support is still there, with closures usable to handle iterating over results. Built-in regex support makes string matching and parameter extration trivial, and now, a syntax error generally gives a much clearer error message.

So I’ll definitely be using Groovy again for future DB data slicing and dicing. It’s really quick to whip out this kind of code in it. If you’ve never thought of using Groovy for ETL type work, give it a go. Of course it’s also pretty nice language for any general Java scripting at this point.

I’m here in North Miami for the Spring Experience 2005, which kicked off last night with a dinner followed by a keynote talk, during which Spring 2.0 M1 was announced. The room was packed, at around 270+ people. It was incredibly gratifying to look around at that room full of Spring enthusiasts and think about how far Spring has come in so little time.

All core Spring developers have been here since Sunday, and it’s been an intense 3 days of meetings and preparations for the conference and the new release. I remember during one session in which Rod Johnson, Rob Harrop, Juergen Hoeller and Adrian Colyer were all sitting at a little table intensely hacking on the same (AOP & XML config) code to get it ready you could almost feel the heat coming off that area. It was all worth it though as the Spring 2.0 featureset, announced during the keynote, is incredibly compelling.

Some more coverage here:

www.springframework.org
Craig Walls
Matt Raible
James Halberg

Tomorrow night, Nov. 16th, I’ll be speaking on Spring at the NYJavaSIG. Since there’s never actually been a talk on Spring there (hard to believe), I’ll be giving a general overview of all that Spring offers, but trying to focus on the areas of most interest to this crowd.

I’ll actually be in NY from tomorrow afternoon until Thursday noon, and may have a bit of free time in that period. If anybody wishes to get together to talk Spring during that time period, just get in touch we me at colins (at) interface21 (dot) com.

Spring 1.2.6 was released yesterday. Thanks to Juergen and Rob for the coding heroics over the last while to get this out.

At this time CVS HEAD is now dedicated to Spring 1.3 development, and over the course of this week, we’ll move already prepared 1.3 features from the sandbox over to the main sources. Starting soon, the nightly snapshots will be 1.3 RC1 previews, already containing 1.3 features.

You can expect some very exciting 1.3 line enhancements to be shown at The Spring Experience in North Miami 3 weeks from now. The Spring Experience is going to be a blast, a 3-day conference in sunny Florida devoted to nothing but Spring, with all the well-known names in the Spring world in attendance as speakers, and hundreds of other Spring users there to talk to.

I’m really pleased to announced that I’ve checked in the initial code into Spring Web Flow’s CVS, for seamlessly integrating with JSF.

The integration code, which was developed in collaboration with Craig McClanahan and Keith Donald, is still somewhat preliminary and needs some polish and tweaking before final release as part of Web Flow 1.0. That said, all the major pieces are there, including the use of Web Flow as the (very powerful) navigation handler for JSF apps, and transparent handling of flow and request scopes. JSF components may bind to flow scope backing objects just as easily as to any of the existing JSF scopes (request, session, app).

The fact that Web Flow has made it straightforward to implement rich and usable integrations with Spring MVC, Struts, and JSF (with more frameworks to come!) is pretty impressive. It’s a real testament to the fact that rich feature set aside, Web Flow has from the beginning been designed with the additional goal of integrating with multiple frameworks, while not compromising on the idea of a rich and viable usage model. in each environment, and prooves that there is absolutely no excuse for tying a web flow type of product to one particular lower level web UI framework vs another.

Anybody that wishes to look at or play around with the code may get at it in the Web Flow CVS. I caution people that there are still going to be a number of changes or additions in the next couple of weeks. There is currently no complete sample app, only a variation of an older version of the sellitem sample with a few pages converted. By the time of final release as part of Web Flow 1.0RC1, there should be a full sample optimized for JSF.