Original Source

Following on yesterday’s Mastering Grails: Grails and Legacy Databases by Scott Davis, Dave Klein writes about his latest experience with EJB2/EJB3 and Grails. I turns out that Dave had previously worked with EJB2 and Grails and everything was peachy, so to speak (given that EJB2 was involved). Switching to an EJB3 based project and Grails afterwards shouldn’t be so difficult right? well there was a vendor related gotcha involved. In Dave’s words:

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) [Editor: no such thing yet bu you can at least create aliases on imports with Groovy] 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.

So there you have it. Grails is EJB friendly, be it by allowing JPA annotated domain classes or Session Beans as services. It may be true that EJB/JPA integration in Grails is without some corner cases, just remember what is proposed in the roadmap for version 1.1.

Tags: Dave Klein, EJB, Grails

Original Source

Dave Klein writes an update of his current project with Grails in the real world. As it happens with many J2EE projects this one had derailed from a healthy schedule and is nearing a final unmovable dead-line (sounds familiar?). To add insult to injury it relies on JSF/EJB, so you can bet there are thousands of configuration files and minor setbacks communicating the whole set of components. Being quite the jovial and enthusiast guy Dave is [Editor’s note: I have the pleasure of meeting Dave in previous occasions] he quickly started to turn around the project inch by inch with the aid of Grails and his team.

Dave writes

Everyone in software development knows what a death march is but not as many are familiar with a forlorn hope. The term comes from the time when wars were fought over fortresses or walled cities. Cannons were used to make a breach in the walls big enough to send troops into. Needless to say, the first troops to go into those breaches did not fare well. So, the first unit to be sent in became known as a forlorn hope. It was often a volunteer unit with the promise of fame, glory and military advancement for those that survived.

I’ve read and heard about death march software projects before but I had never experienced one until recently. About a month ago I was put in charge of a 2 1/2 year JSF/EJB project that had 8 months left and was less than half done. (By the way, that’s my excuse for not blogging in a while. It’s not as good as Glen Smith’s excuse but it’s all I’ve got) At first this was quite disheartening. I assessed the situation and made it clear that there was no way that we could meet the deadline but was told to just “do the best we could”. So, I marched on…

Then, as I dug into the project more, I discovered that there were major pieces of the application that were isolated enough that they could be done in a different environment without impacting the overall system. Grails to the rescue. We are now using Grails for most of the remaining development and gaining momentum quickly. Two of the four of us on this team have Grails experience but the other two are coming up to speed very quickly and, I might add, enjoying their jobs more than they have for some time. One of the pleasant side effects of using Groovy and Grails is increased job satisfaction and motivation.

Though it looks that the team will not be able to make the deadline (miracles can only happen so often) it still good to know that they are making great progress turning a barely alive project into a forlon hope. We also hope Dave is able to share some war stories from this endeavor.

Tags: Dave Klein, Grails