Advocating for Grails over Seam in an EJB3 landscape

[Edderd]

I'm on a project where we are considering which web framework to use for a system that has a nascent EJB3 persistance landscape in development. Tomorrow (July 1) we will have a discussion about which is the best framework for our project.

Seam is the competing framework and no surprise, there are strongly held opinions, some more valid than others. Interestingly there is no one at our shop with any real Seam experience, but it is non the less favored by some anyway.

The main issue seems to be that there is a EJB3 persistance model being developed and the argument is that Grails will have to circumvent the EJB3 technology while Seam is designed around EJB3, and JPA.

I have alot of Grails experience, but all of it greenfield db development. No legacy mapping, and no EJB3. I wonder how much of an issue this is in reality. Trust me, I'm scrambling to learn all I can asap.

I see that there is some coverage in DGG chapter 17 "Legacy Integration with Hibernate":EJB 3 Compliant Mapping and I plan on looking into this to diffuse that argument, hopefully. Can anyone point me to any other resources for this kind of issue?

So, is the EJB3 deal breaker in favor of Seam?

Also, it may be argued that Grails does not have mature JPA support? Can anyone speak to this issue?

Also, what other points can there made to argue for Grails over Seam in this instance?
 

[Bob Brown-3]

I used Seam (1.x) a while back...I found that some if its features (like
@DataModel/@DataModelSelection) were interesting but came up short in
practise...essentially, as soon as one stepped outside its prescribed limits
(such as trying to do master-detail stuff), it  was like not having anything
there at all: you had to go back to doing everything by hand. I ended up
saying "so what exactly did Seam contribute?"

I didn't really see 'outjection' as useful...plain spring-style DI is more
useful, practically speaking...and outjection doesn't appear in the WebBeans
'standard'.

This has a few more comments:

http://gusiev.com/2009/05/jboss-seam-usage-makes-the-application-code-crazy/

I REALLY like what they are trying to do, but Seam didn't 'click; with me.

Also: not uniquely Seam, but JSF/facelets and therefore relevant...I have
been bitten by this:

http://wiki.java.net/bin/view/Projects/FaceletsFAQ#I_m_getting_Duplicate_ID_
Errors

PAINFUL!

It hit so hard that we had to throw away the whole view layer (80%
complete): The UI design had tabs where each tab came from a different URL.
JSF/Facelets got so messed up that we couldn't continue...there was just NO
WAY to prevent duplicate Ids from being allocated and throwing up errors. I
won't be voluntarily using JSF in a hurry again, I can tell you!

Note that there is no fix to this issue...effectively: if it bites you,
you're dead.

Again: I like the idea, but the implementation didn't cut it.

HTH.

BOB

> -----Original Message-----
> From: Ed Young [mailto:ejy@...]
> Sent: Wednesday, 1 July 2009 5:50 AM
> To: user@...
> Subject: [grails-user] Advocating for Grails over Seam in an EJB3
> landscape
>
> I'm on a project where we are considering which web framework to use
> for a system that has a nascent EJB3 persistance landscape in
> development. Tomorrow (July 1) we will have a discussion about which is
> the best framework for our project.
>
> Seam is the competing framework and no surprise, there are strongly
> held opinions, some more valid than others. Interestingly there is no
> one at our shop with any real Seam experience, but it is non the less
> favored by some anyway.
>
> The main issue seems to be that there is a EJB3 persistance model being
> developed and the argument is that Grails will have to circumvent the
> EJB3 technology while Seam is designed around EJB3, and JPA.
>
> I have alot of Grails experience, but all of it greenfield db
> development. No legacy mapping, and no EJB3. I wonder how much of an
> issue this is in reality. Trust me, I'm scrambling to learn all I can
> asap.
>
> I see that there is some coverage in DGG chapter 17 "Legacy Integration
> with Hibernate":EJB 3 Compliant Mapping and I plan on looking into this
> to diffuse that argument, hopefully. Can anyone point me to any other
> resources for this kind of issue?
>
> So, is the EJB3 deal breaker in favor of Seam?
>
> Also, it may be argued that Grails does not have mature JPA support?
> Can anyone speak to this issue?
>
> Also, what other points can there made to argue for Grails over Seam in
> this instance?
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[T. Gullo]

Prototype a small part of the application using each technology. Then compare the advantages and disadvantages of each.

Edderd wrote:

I'm on a project where we are considering which web framework to use for a
system that has a nascent EJB3 persistance landscape in development.
Tomorrow (July 1) we will have a discussion about which is the best
framework for our project.

Seam is the competing framework and no surprise, there are strongly held
opinions, some more valid than others. Interestingly there is no one at our
shop with any real Seam experience, but it is non the less favored by some
anyway.

The main issue seems to be that there is a EJB3 persistance model being
developed and the argument is that Grails will have to circumvent the EJB3
technology while Seam is designed around EJB3, and JPA.

I have alot of Grails experience, but all of it greenfield db development.
No legacy mapping, and no EJB3. I wonder how much of an issue this is in
reality. Trust me, I'm scrambling to learn all I can asap.

I see that there is some coverage in DGG chapter 17 "Legacy Integration with
Hibernate":EJB 3 Compliant Mapping and I plan on looking into this to
diffuse that argument, hopefully. Can anyone point me to any other resources
for this kind of issue?

*So, is the EJB3 deal breaker in favor of Seam?*

Also, it may be argued that Grails does not have mature JPA support? Can
anyone speak to this issue?

Also, what other points can there made to argue for Grails over Seam in this
instance?

[Lloyd Meinholz-2]

Even if you do have an existing schema, it's not too hard to use GORM DSL to map the schema to a grails application. You can see an example of that in a blog entry I wrote: <http://blog.javabilities.com/2009/06/access-legacy-database-using-gorm-dsl.html>. I can't speak to using JPA though, this is just using GORM DSL to map to a legacy database.

Lloyd

On Tue, Jun 30, 2009 at 3:50 PM, Ed Young <ejy@...> wrote:

I'm on a project where we are considering which web framework to use for a system that has a nascent EJB3 persistance landscape in development. Tomorrow (July 1) we will have a discussion about which is the best framework for our project.

Seam is the competing framework and no surprise, there are strongly held opinions, some more valid than others. Interestingly there is no one at our shop with any real Seam experience, but it is non the less favored by some anyway.

The main issue seems to be that there is a EJB3 persistance model being developed and the argument is that Grails will have to circumvent the EJB3 technology while Seam is designed around EJB3, and JPA.

I have alot of Grails experience, but all of it greenfield db development. No legacy mapping, and no EJB3. I wonder how much of an issue this is in reality. Trust me, I'm scrambling to learn all I can asap.

I see that there is some coverage in DGG chapter 17 "Legacy Integration with Hibernate":EJB 3 Compliant Mapping and I plan on looking into this to diffuse that argument, hopefully. Can anyone point me to any other resources for this kind of issue?

So, is the EJB3 deal breaker in favor of Seam?

Also, it may be argued that Grails does not have mature JPA support? Can anyone speak to this issue?

Also, what other points can there made to argue for Grails over Seam in this instance?
 

[Helmut Denk]

Edderd wrote:

I see that there is some coverage in DGG chapter 17 "Legacy Integration with
Hibernate":EJB 3 Compliant Mapping and I plan on looking into this to
diffuse that argument, hopefully. Can anyone point me to any other resources
for this kind of issue?

'Grails in Action' chapter 13. There was also a 2-Part Article "Dealing
with the Legacy Database from Hell" in GroovyMag Feb + March 2009.

Edderd wrote:

Also, what other points can there made to argue for Grails over Seam in this
instance?

It may help to look at the Stack of Technologies as o whole ...
and also to consider vision-, policy- and license-aspects:

http://blog.springsource.com/author/rodj/

(of course rod is biased, but his arguments are quite good IMO)

[Edderd]

That's a great blog post and I appreciate your help.

I'm glad you mentioned Grails In Action and I can't believe I didn't reference it in my original post, since I was a MEAP subscriber from the beginning, and provided tons of feedback to Glen and Peter.

It's a great book and I highly recommend it!

Sorry guys!

On Tue, Jun 30, 2009 at 5:08 PM, Lloyd Meinholz <meinholz@...> wrote:

Even if you do have an existing schema, it's not too hard to use GORM DSL to map the schema to a grails application. You can see an example of that in a blog entry I wrote: <http://blog.javabilities.com/2009/06/access-legacy-database-using-gorm-dsl.html>. I can't speak to using JPA though, this is just using GORM DSL to map to a legacy database.

Lloyd

On Tue, Jun 30, 2009 at 3:50 PM, Ed Young <ejy@...> wrote:

I'm on a project where we are considering which web framework to use for a system that has a nascent EJB3 persistance landscape in development. Tomorrow (July 1) we will have a discussion about which is the best framework for our project.

Seam is the competing framework and no surprise, there are strongly held opinions, some more valid than others. Interestingly there is no one at our shop with any real Seam experience, but it is non the less favored by some anyway.

The main issue seems to be that there is a EJB3 persistance model being developed and the argument is that Grails will have to circumvent the EJB3 technology while Seam is designed around EJB3, and JPA.

I have alot of Grails experience, but all of it greenfield db development. No legacy mapping, and no EJB3. I wonder how much of an issue this is in reality. Trust me, I'm scrambling to learn all I can asap.

I see that there is some coverage in DGG chapter 17 "Legacy Integration with Hibernate":EJB 3 Compliant Mapping and I plan on looking into this to diffuse that argument, hopefully. Can anyone point me to any other resources for this kind of issue?

So, is the EJB3 deal breaker in favor of Seam?

Also, it may be argued that Grails does not have mature JPA support? Can anyone speak to this issue?

Also, what other points can there made to argue for Grails over Seam in this instance?
 

--
- Ed

[Lloyd Meinholz-2]

Glad the blog post was helpful. I'm going to have a follow on in a couple of days that completes the rest of the tables. I'm thinking of creating a project on kenai (yes I love netbeans) so people can download the project easily or figure out how to make my subversion repository open for public read. I was a MEAP subscriber too, but didn't provide too much helpful feedback (but I love the book too).

I really think if you know the database schema, you can probably knock off one moderately complex table every 15 minutes once you get the hang of the gorm dsl. Granted that isn't as fast as reverse engineering a database with hibernate tools, but you get all the gorm/grails flexibility that you wouldn't get with a vanilla Java/hibernate or Seam project.

Lloyd

On Wed, Jul 1, 2009 at 10:02 AM, Ed Young <ejy@...> wrote:

That's a great blog post and I appreciate your help.

I'm glad you mentioned Grails In Action and I can't believe I didn't reference it in my original post, since I was a MEAP subscriber from the beginning, and provided tons of feedback to Glen and Peter.

It's a great book and I highly recommend it!

Sorry guys!

On Tue, Jun 30, 2009 at 5:08 PM, Lloyd Meinholz <meinholz@...> wrote:

Even if you do have an existing schema, it's not too hard to use GORM DSL to map the schema to a grails application. You can see an example of that in a blog entry I wrote: <http://blog.javabilities.com/2009/06/access-legacy-database-using-gorm-dsl.html>. I can't speak to using JPA though, this is just using GORM DSL to map to a legacy database.

Lloyd

On Tue, Jun 30, 2009 at 3:50 PM, Ed Young <ejy@...> wrote:

I'm on a project where we are considering which web framework to use for a system that has a nascent EJB3 persistance landscape in development. Tomorrow (July 1) we will have a discussion about which is the best framework for our project.

Seam is the competing framework and no surprise, there are strongly held opinions, some more valid than others. Interestingly there is no one at our shop with any real Seam experience, but it is non the less favored by some anyway.

The main issue seems to be that there is a EJB3 persistance model being developed and the argument is that Grails will have to circumvent the EJB3 technology while Seam is designed around EJB3, and JPA.

I have alot of Grails experience, but all of it greenfield db development. No legacy mapping, and no EJB3. I wonder how much of an issue this is in reality. Trust me, I'm scrambling to learn all I can asap.

I see that there is some coverage in DGG chapter 17 "Legacy Integration with Hibernate":EJB 3 Compliant Mapping and I plan on looking into this to diffuse that argument, hopefully. Can anyone point me to any other resources for this kind of issue?

So, is the EJB3 deal breaker in favor of Seam?

Also, it may be argued that Grails does not have mature JPA support? Can anyone speak to this issue?

Also, what other points can there made to argue for Grails over Seam in this instance?
 

--
- Ed

[Bob Brown-3]

[snipped]

> of the gorm dsl. Granted that isn't as fast as reverse engineering a
> database with hibernate tools, but you get all the gorm/grails
> flexibility that you wouldn't get with a vanilla Java/hibernate or Seam
> project.

But for that there is grag:

http://grag.sourceforge.net/

"GRAG1.0 is a free domain object generator for the Grails framework
(http://grails.org).

You can use The GRails Application Generator (GRAG) to get started with
Grails using an existing database. It will generate Grails domain objects
including constraints and relations. After generating the domain objects,
you can continue using Grails with all it's power."

Don't know how active the project is, but it has worked OK for me in the
past.

Cheers,

BOB


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Henning Sprang-3]

On Wed, Jul 1, 2009 at 12:40 AM, Tom_G<springmethods@...> wrote:
>
> Prototype a small part of the application using each technology. Then compare
> the advantages and disadvantages of each.

I like that one - especially in terms of doing things that are
actually the best for the project's success :)

Some measures to check for:

* tool support - do all major IDE's or at least all in use in your
company support the framework?
* learning curve - as well as for getting started a simple project as
for doing more advanced things?

(you could actually find answers on these when doing as Tom suggested)

* Are there well working (security) update processes?
* community support - partly also in the first category  - you could
count members on a mailing list, numbers of messages, numbers of
actually answered questions or requests for help (and really think
about what each of these would mean)
* proven production use - are there recognizeable examples of people
using the framework - preferably with similar requirements and
environment as you have?
* long term development chances - will the framework be supported for
the lifetime of your applications?

And then some...

These could be hard to measure, I think, but interesting aspects - I'm
not even sure, which of the two contenders would win there.

G'night,
Henning

--
Henning Sprang
http://www.sprang.de

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email