There are a lot of reasons to love working at Interface21, but by far the best has to be working with the leaders of the industry. For example, one of Spring 2.0’s major focus points has been on improving AOP support. We’ve added a new configuration namespace, the AspectJ pointcut language and support for @AspectJ aspects. But this leaves a big question; what is the preferred way of writing Aspects in Spring 2.0? Since I’m an I21 employee, I have the luck of getting the answer straight from the horse’s mouth.
Over the last month Jay Zimmerman and I have been working hard planning The Spring Experience 2006 (TSE). Creating a first-class technical conference is no easy task–it takes hour upon hours to arrive at the perfect mix of speakers and content.
I am proud to say we are now ready to roll with an unprecedented event. Check it out:
- 55 ninety-minute sessions across 5 tracks over 3-full days, all at a five-star beach resort.
- Exclusive premium technical content on Spring 2.0. Half of the sessions are led by core Spring developers who apply the latest Spring capabilities inside and out. This includes Rod Johnson, Juergen Hoeller, Adrian Colyer, Rob Harrop, Colin Sampaleanu, Ben Alex, Arjen Poutsma, Erwin Vervaet, and yours truly.
- Cutting edge sessions from leading Java software innovators. This includes Jeff McCaffer, lead of the Eclipse RCP and Equinox projects; Guilluame LaForge, Groovy project lead; Eamonn McManus, JMX Lead; Patrick Linskey, BEA Kodo JPA lead, and Mike Keith, lead of the Java Persistence Architecture (JPA).
- Real-world insight from renown industry experts. This includes Eric Evans, author of the timeless book Domain-Driven Design, Luke Hohmann, business of software expert and author of Beyond Software Architecture; Ramnivas Laddad, Interface21 Principal and author of AspectJ in Action; Venkat Subramanium, author of Practices of an Agile Developer, Floyd Marinescu, creator of InfoQ.com, solution architects Mark Richards (IBM) and Jim Clark (Oracle), and Mike Stenhouse, usability expert and author at Content With Style.
- Privileged access to synced-audio slideshows for all sessions following the show, so you don’t miss a beat.
- Full-course breakfast, lunch, and dinner included with registration.
- “Meet the Gurus” user BOFs. A great opportunity for Spring users to interact with Spring project leads.
- Two kick ass parties, one Friday night, and a Saturday afternoon party on the beach complete with a Spring users vs. developers volleyball game.
- Cool conference schwag. And lots of it. Registered experiencers’ receive an all access conference pass, a custom (and very cool) TSE laptop bag, a custom-designed notebook binder, a limited-edition TSE 2006 shirt, and even an official TSE 2006 beach towel. You’ll have chances to win an iPod and XBox 360.
- Diversity. Whether you are a hard core enterprise developer, a web application developer, or a leading software architect, this conference has something for you. Last year’s show brought 250 people from 20 countries. This year we expect 500 attendees from over 25. It’s going to be a lot of fun, and a great learning and networking opportunity.
Spring 2.0 is coming and I for one am excited. I can still remember the first time that I heard about all of the new features that would be in the release at last year’s The Spring Experience. The asynchronous JMS message reception and the AOP integration with AspectJ excited me the most (a bit of drooling involved actually), but even then there were many other improvements and the list has only grown since.
Alas, I know that most of you aren’t middle-tier nerds like me, so what are you excited about? The new XML dialects and XSD support? The improved JSP taglib? How about that <tx:annotation-driven />? Maybe you love that Groovy support instead.
As Interface21 grows as a global company one thing has become more and more clear to me everyday:
we really have some damn talented, highly motivated leaders who have a lot to say on both business and technology.
Here you will gain insight into what’s going on at i21, from what we’re working on, to what problems we’re solving, to where we’re going, to what we’ve learned along the way. You’ll see a lot of diversity, as our company is doing a lot of things, from leading the development of the Spring Framework and the Spring family of products to expanding operations in five major international markets.
The motivation behind this blog entry is to provide a simple step-by-step guide for getting started with JPA in a standalone environment with the Spring Framework. While the JPA specification originated as the persistence mechanism for EJB 3.0, it was fortunately recognized that any such mechanism should in fact be able to persist simple POJOs. Therefore, with a handful of JARs in your classpath and a few Spring-configured beans, you can begin experimenting with JPA code within your favorite IDE. I will be using Glassfish JPA - which is the reference implementation and is based upon Oracle's TopLink ORM framework.
I just got finished with my Spring 2.0: New and Noteworthy talk at Atlanta DevCon 2006. Let me be the first to say that the conference was great. The site and organizers were all top notch. I’d like to give a special shout-out to Burr Sutter for putting on one heck of a conference. You know that things are going well when the conference center doesn’t have a wireless network but you can get the one from the cafe next door. That’s good karma! The JUG members were all very knowledgeable (even the ones that didn’t know about Spring) and asked great questions. I fielded questions about EJB 3, JPA, ESB, Spring learning curves, Java 5, and Spring Web Flow; every one a great question.
In a project that I used to work on we had a system that would receive messages from a device and make decisions on whether that information would be passed to the user. There were multiple decision levels and one of the problems we always found ourselves asking was if a message was being lost on it’s way through the system.
Before we moved to Spring, it was nearly impossible to tell the answer to that question. Attempts were made to use logging, but the sheer volume of messages that decisions were made on made it tedious at best. Other attempts were made using debuggers but a combination of the volume and the timing changes led to only intermittent success.
Recently I was working on a project that had a Swing client communicating via RMI to a service layer. The service layer was marked with transactions and everything seemed to work fine. However everytime we’d get an exception at the Hibernate DAO layer, Spring would turn the exception into a runtime exception and it would get propagated all the way up the stack and across the RMI connection as a RemoteException. Whenever the exception was deserialized there would be an exception on the client (separate from the RemoteException.The decision was taken to simply introduce an aspect. Any exception that subclassed ServiceAccessException would be let through to the client while anything else would be converted to a FilteredServiceAccessException (a subclass of ServiceAccessException) and then be thrown. This led to some loss in content, so we made sure to log the original exception on the server where it could be useful and let the client show a generic dialog so the user knew generally what had happened.
With the release of Spring 1.1 the Spring community was given it’s first taste of JMS support. This support included exception translation, message conversion, and a template class much like JdbcTemplate. This support also took care of domain unification between the JMS 1.0.2 and 1.1 specs. The centerpieces of this support are the JmsTemplate class and it’s JMS 1.0.2 counterpart JmsTemplate102.
This support was a great improvement over using the raw JMS APIs to do enterprise messaging. However it did have a shortcoming; the JmsTemplate only supported synchronous reception of messages using the JmsTemplate.receive() methods. This behavior worked well for many people but the vast majority of users of ended up rolling their own implementations of an asynchronous consumer. In short, they wanted what EJB 2 called Message Driven Beans.