InfoQ Article: Grails + EJB Domain Models Step-by-Step
As one impressive example of its enterprise integration abilities, Grails let's you quickly and easily build a web application backed by your existing EJB3 entity beans. But, it doesn't stop there. Grails gives your entity beans a hearty shot of steroids, but does so completely dynamically, without altering your EJB source code in any way. Grails Object Relational Mapping (GORM) is built on Hibernate 3 (but will eventually offer support for the Java Persistence API) and uses Groovy's Meta Object Protocol (MOP) to add all sorts of handy dynamic methods to your otherwise-static entity beans. And those methods are not only accessible from Grails and Groovy; your Java code can invoke those methods as well! We suddenly have all the enterprise-level capabilities of JEE/EJB3 and the benefits of RAD web application development!The integration angle is quite important, as reuse of existing investments in Java is a commonly cited problem the Java community has been saying about using Ruby on Rails. Grails brings a RAD framework bound together with our own dynamic language (Groovy) which is part of the Java platform. Integrated stacks RAD stacks with a strong EJB focus is an area of innovation for a number of frameworks wuch as RIFE, Trails, JBoss SEAM (JSF+EJB), but Grails is the only one built around the Groovy dynamic language. Could Grails become the Java community's answer to Ruby on Rails?
Wow EJB is now legacy?
by
j c
And do it with another language. Ouch.
Floyd I cant figure if you think Java has a future or if you think we should all party on the VM like it was (a) 1999 (Corba container).
This is what frustrates me about the Java space right now. Everyone is so rattled by ruby and scripts and trying to wedge Java in a buzz trend that is so far removed from where Java is that its not even worth discussing Java in a "rails" context.
Or discussing rails in an EJB context.
If we have to port rails to the JVM to be happy then maybe we should just use the ruby interpreter and support its toolset and let IBM handle the legacy integration as they are so keen to do.
Its not interesting or all that relevant.
no, you missed the point
by
Floyd Marinescu
Considering strategies like Domain Driven Design, focusing on your domain model in Java and generating the UI around that is an emerging best practice that tools like Grails can enable.
Re: Wow EJB is now legacy?
by
Graeme Rocher
Java has a huge future and it speaks volumes for the strength of the platform that Grails and its underlying frameworks (Spring, Hibernate, SiteMesh, Quartz etc.) exist.
In terms of porting Rails, well yes that is one option, but Rails (as with Ruby's runtime) has a very different object model and idioms for developing web applications. One that its contradictory to existing knowledge about specifications like Servlets, JSP and, indeed, EJB.
Grails is not a port of Rails and in fact is very different in many ways including how it is based on Java frameworks.
Re: no, you missed the point
by
j c
"built on the PL/SQL language" and "fully integrated with Java"
"built on Javascript language" and "fully integrated with Java"
"built on ActiveX" and "fully integrated with Java"
"Built on Flash" and "fully integrated with Java"
I didnt miss the point. The point was accessing EJBs with something other than Java. And if EJB 3 is a big plus in combination with another language then *something* in this picture just went legacy.
And something just went "integration strategy"
Thats how you know what legacy is and isnt.
Integration w/ Legacy Apps versus Developing w/ Complimentary Technologies
by
Jason Rudolph
There's a distinct difference between...
* Using a current technology to integrate with a pre-existing (legacy) application,
versus...
* Using a current technology (like Grails) in concert with another complimentary and current technology (like EJB) to build a new application.
The point was accessing EJBs with something other than Java. And if EJB 3 is a big plus in combination with another language then *something* in this picture just went legacy.
I respectfully disagree. We've long been dependent on another language to make our Java apps work. That language is XML, and XML does not make Java a legacy language. They're complimentary technologies.
If the goal is to build a web user interface for your EJBs (which are, by their very nature, business-tier components), chances are you're going to invoke some other (complimentary) technology for your web tier. Maybe it's just JSP. Maybe it's Struts or Spring MVC or Tapestry or Grails. The use of those complimentary technologies does not make EJB a legacy technology. It's instead a choice of using the most efficient tool for the job at hand. And for many applications, Grails offers the productivity gains to make it a strong contender to be that tool.
Re: Integration w/ Legacy Apps versus Developing w/ Complimentary Technolog
by
j c
What if the smalltalk guys had insisted that Java run in a smalltalk VM? What would people have thought of them? The smalltalk VM was way ahead of Java in the early days.
So now the Java scene wants to steal ruby and rails from the cradle and I say well if Java is so great then let Java solve its own problems without coopting the vibe of the scripting languages.
I think Java is trying to change before anyone acknowledges or speaks aloud of a greater failure of OO or more specifically Java projects to deliver.
Re: Integration w/ Legacy Apps versus Developing w/ Complimentary Technolog
by
Steven Devijver
I think Java is trying to change before
anyone acknowledges or speaks aloud of a greater failure of OO or more
specifically Java projects to deliver.
I read in a magazine a couple of years ago that "the Hummer is the greatest off-road vehicle we ever drove". And "with a Hummer you can get through any terrain except through narrow streets".
Java, Groovy and Ruby are great in many areas but none is great in all areas. Particularly, Java is not so great to write web handlers. Alternatively you could use Ruby and Rails or Grails if you want to reuse Java code. In fact, we've created Grails to augment the Java platform.
You can hate us for doing so and being successful. There's however no need to start a flame war.
relationship management
by
Jeff Payne
bug in employee list?
by
ma pel
I followed up this step-by-step and successfully run 'grails run-app'.
Everything looked great except this case:
I assigned 3 computers to an employee, for example, jane and I got
3 instances of the same 'jane' listed in the browser(IE6.0) when I click on
employeeBean list link. That seems a bug. How can I fix it?
Thanks.
Re: relationship management
by
Graeme Rocher
Re: bug in employee list?
by
Jason Rudolph
There's apparently problem with the dynamic list method, which is used to fetch the list of employees. You can track the problem here: jira.codehaus.org/browse/GRAILS-284
Nice, but...
by
Randall Burt
Re: Nice, but...
by
Pat Osterday
Your comment is exactly what I was thinking! I read the article and there's no mention of an app server or anything like that! Just copying the entity code and using that. While Grails looks cool, we've got a lot invested in the JEE resources. Guess we'll have to see what develops!
Article in pdf format?
by
Fred Janon
having problems to run app with grails 1.0 RC2 & groovy 1.0
by
Michael Brinkmann
I am stuck following your steps in a very early stage ("run-app" directly after "create-app"):
(I am running the grails / groovy-versions mentioned above with JDK 1.6.0_03 on Windows XP SP2)
> grails run-app
Welcome to Grails 1.0-RC2 - grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: C:\Programme\Dev\grails-1.0-RC2
Base Directory: c:\Arbeit\Allgemein\Dev\Projekte\GrailsTest1
Environment set to development
Note: No plugin scripts found
Running script C:\Programme\Dev\grails-1.0-RC2\scripts\RunApp.groovy
groovy.lang.MissingPropertyException: No such property: war for class: java.lang.String
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:48)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:474)
at Config.run(Config.groovy:62)
....
Do you have any hints for me?
Kind regards
Michael
Re: having problems to run app with grails 1.0 RC2 & groovy 1.0
by
Michael Brinkmann
FYI: just fixed the error by changing the line
grails="error"
to
grails.app="error"
in the generated file "grails-app/conf/Config.groovy".
Kind regards
Michael
Issue GRAILS-2042
by
Venky VB
- Venky
Scrollable results?
by
Siddharth Bala Ravi
Thanks for the article - it's awesome.
I was wondering what needs to be done to make the following search scrollable...being very new to grails, i'm having a real hard time figuring it out...
generate-controller failure with Grails 1.0.4
by
Sherry Shen
in ejb3_grails dir
./src/java/com/jasonrudolph/ejb3example/entity/EmployeeBean.java
./src/java/com/jasonrudolph/ejb3example/entity/ComputerBean.java
./grails-app/conf/hibernate/hibernate.cfg.xml
./lib/mysql-connector-java-5.1.6-bin.jar
./grails-app/conf/ApplicationDataSource.groovy
I am not sure about hibernate.cfg.xml location.
At Step 4 - Generate the Scaffolding, I got an error.
% grails generate-controller
.....
No domain class found for name com.jasonroudolph.ejb3example.entity.EmployeeBean.
Please try again and enter a valid domain class name
How to move forward?
Thanks for the help!
Re: Nice, but...
by
Gazi Mushfiqur Rahman
Educational Content
Writing Usable APIs in Practice
Giovanni Asproni May 19, 2013
Concurrency in Clojure
Stuart Halloway May 17, 2013




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think