Yet Another 2GX Wrap-up

Finally after more than a year of waiting and nagging, the second 2GX conference was held in New Orleans last week. It was almost as good as the first one. Well, in some ways it was better but in other ways... well, we'll get to that in a bit. But first, I wanted to say how great it was to see so many people from the Groovy community. It is so cool to be able to put real faces to so many on-line friends. I know conference people always say that "the attendees are what really makes the conference great", but as a speaker and part-time staff member at this conference, I can say that it's really true. The questions during the sessions and the discussions between sessions and at meals were the best part of the whole thing. Even better than the Rod Johnson bobble-head dolls. :-)

Speaking of staff, I also want to tip my hat (if I had one) to the guys that pulled it all off. Jay Zimmerman did as good of a job with the 500+ person event as he does with the NoFluffJustStuff conferences and his two volunteers (and one sales guy :), and my co-workers, Erik Weibust, Todd Crone, and Paul Luttrell were tireless in their efforts to keep things running smoothly. It was great working with you guys!

One thing I want to highlight here was how excited I was to see some relative new comers speaking at 2GX. These guys aren't new to Groovy or Grails, but I think this was the first conference appearance for each of them and they were awesome! Matt Taylor, Hamlet D'arcy, Scott Vlaminck (the 'n' is silent), and Burt Beckwith (actually I'm not sure if Burt has spoken at other conferences, so forgive me if I'm wrong)

Matt spoke on Grails UI, the YUI based Grails plugin that he developed and maintains as well as his experiences using Grails "in the wild". I caught his GrailsUI talk and was very impressed, along with the rest of the room who all gave him the coveted "green cards".

I didn't catch any of Hamlet's sessions but from what I heard from other attendees and on Twitter, he was a hit! He gave four presentations altogether: OSGi and Groovy, Functional Groovy, Compiler Metaprogramming with AST transformations, and Legacy Code and Groovy. Rumor has it that he even had Venkat Subramaniam impressed.

Scott Vlaminck, from Refactr, gave talks on Metaprogramming in Groovy and Grails, and AOP in Grails. Again, I wasn't able to catch any of these talks in person, but the feedback was quite good and in fact I happened to be in the room next to one of Scott's talks and the speaker was almost drowned out by the applause!

Burt also gave four presentations. He spoke on Spring Security in Grails, GORM performance, UI performance, and Clustering Grails apps. I only caught the GORM performance talk, but it was one of my favorites. I am already putting things I learned there to use in my day job.

Of course the usual awesome Groovy/Grails/Griffon speakers were there and they were terrific as usual, but you've already heard about them and many others have or will blog about the cool Griffon sessions, or the Grails internals, or the power of Grails plugins, or the DSLs and Groovy testing magic, etc. So I wanted to take a moment to congratulate these guys on a job well done. I look forward to seeing them present at future events.

Now, as to why I don't think this 2GX was quite as good as the first one. The full name of the conference is a clue: SpringOne 2GX. SpringOne is a good conference, but 2GX is a great conference! (or a GR8 conference :) So, when combined we ended up with a more than good but not quite great conference. Spring technology is cool. Much of it (though not all) is behind some of the power of Grails. And I do very much appreciate the support that SpringSource is giving to Groovy and Grails, but I think they just gave a bit of a "corporate feel" to the conference.

I don't want to end on a downer though. There were some distinct benefits of having the two events combined. One was that SpringOne had some very good content and some exceptional speakers to add to the mix. Another is that more than a few Spring users got to glimpse the goodness of Groovy, Grails and Griffon for the first time. The oohs and ahhs were music to my ears! It serves as a reminder to just be patient and hang in there... it's only a matter of time until they'll be holding the Groovy, Grails, Griffon and Spring conference!

10 Reasons to attend SpringOne 2GX

I was going to come up with one of those clever top 10 lists but when I went to the SpringOne/2GX home page, I saw 10 great reasons to attend staring me in the face.



The early bird discount ends Friday, September 18th, but even at full price this event is less expensive than JavaOne and will contain way more good technical content. Check out the rest of the speakers and the awesome session list at http://springone2gx.com

If you're interested in Groovy, Grails, Griffon, (or related technologies) or if you use Spring in any of it's myriad forms, or, for that matter, if you use Java, you won't want to miss this conference!

See you there!

Congratulations to SpringSource!

It looks like SpringSource has their answer to JBoss Seam, and what an answer it is!  There are all kinds of aspects and angles to SpringSource's recently announced acquisition of G2One, the company behind Groovy and Grails, but this one struck me right off the bat.  

While Groovy will give new energy to the entire Spring portfolio, Grails, specifically, will help round out their competitive position vis a vis RedHat.  In recent demos at our Java User Group and at JavaOne, it appears that RedHat is using Seam to draw people into their whole platform.  And until now, SpringSource hasn't had a direct answer to that.   Not only will they have a framework that competes with Seam, but they will have one that blows it out of the water!  Don't get me wrong, Seam is heading in the right direction and with the eventual advent of JSF 2.0 it will get even better, but it is no where near as productive, effective or awesome as Grails.

Over the next several days, we will probably be hearing a lot about what this acquisition means to the future of Groovy and Grails.  I think, overall, it will be a major positive in that regard.  But, I think the real winner is SpringSource.   Congratulations to Rod Johnson and the gang for once again jumping ahead of the curve!

Grails and EJB 3 Session Beans

A while back I was working on a Grails project that needed to integrate with an EJB2 application via session beans. So, when my current project had a similar need I thought 'piece of cake!'. As it happens it was a piece of cake that wasn't that easy to get at.

The problem came about because we were working with EJB3 this time. I had heard that it should work the same but it doesn't. I eventually found that it is still extremely easy to do (this is Grails we're talking about after all) it's just different.

For starters the Spring class that we used to connect to an EJB2 session bean, SimpleRemoteStatelessSessionProxyFactoryBean (I wonder if there is a TinyURL! for class names) was not working with EJB3. Several people on the forums said that it should, but our application did not believe them. It turns out that there is a Spring class that does work with EJB3 and it even has a shorter name! The JndiObjectFactoryBean is a general purpose Factory for looking up JNDI objects and making them available to other beans. The JndiObjectFactoryBean will even use the JndiTemplate that I had setup before, though I'll show it again so you don't have to hunt it down.

So now we should be in business. Except that it didn't work. When using the SimpleRemoteStatelessSessionProxyFactoryBean we could just use the Session Bean's simple interface name, which was also its JNDI name. That was not working with the JndiObjectFactoryBean. This critter wanted a fully qualified, certified and USDA approved JNDI name. The bummer here is that this is vendor specific. So the rest of this will work for BEAORACLE WebLogic but it might be completely different for your app server.

First we have to make sure that the EJB3 session bean has the mappedName attribute in the @Stateless annotation. (In our case ...mappedName="CoverageSession") That makes up the first part of the JNDI name. Then we add a # symbol and top it off with the fully qualified name of the Remote Interface. So we ended up with something like this for our JNDI name: CoverageSession#org.blah.app.ejb.session.ICoverageSessionRemote Once we gave it that mouthful it was happy.

Here I'll show a slightly modified version of our resources.groovy file:

beans = {
ejbJndi(org.springframework.jndi.JndiTemplate){
environment = [
  "java.naming.factory.initial" : "weblogic.jndi.WLInitialContextFactory",
  "java.naming.provider.url" : "t3://some.enterprise.server:7001"
  "java.naming.security.principal" : "dave",
  "java.naming.security.credentials" : "1234" ]}

coverageSession(org.springframework.jndi.JndiObjectFactoryBean){
jndiName = "CoverageSession#org.blah.app.ejb.session.ICoverageSessionRemote"
jndiTemplate = ref("ejbJndi")
}
}

Now we can inject the session bean into a Grails Service and we can call its methods to retrieve and save EJB3 entities from that portion of the application that was written before we began using Grails and it all just works and I'm happy!

I'm still hoping to be able to convert the entire application to Grails before we go production but in case we can't the ability to integrate Grails with all of our existing Java technologies is a big help.