views:

330

answers:

4

I'm currently using Java & Spring (MVC) to create a webapp, and I'm considering moving to Grails. I'd appreciate feedback/insight on the following:

  1. I have multiple application contexts in the current Java/Spring webapp that I load through the web.xml ContextLoaderListener; is it possible to have multiple application contexts in Grails? If, yes, how?

  2. This webapp extensively uses a CXF restful web service and the current Java/Spring webapp uses the bundled CXF HTTP client. Can I continue to use the (Java) CXF HTTP Client in Grails?

  3. I implemented Spring Security using a custom implementation of UserDetails and UserDetailsService, can I re-use these implementations in Grails "as is" or must I re-implement them?

  4. There is an instance where I've relied on Spring's jdbc template (rather than the available ORM) and an additional data source I defined in app context, can I re-use this in Grails?

  5. I plan on using Maven as the project management tool; are there any issues of using Maven with Grails where there is a combination of groovy and java?

Edit: I'm considering moving to Grails to make the development of the web component of the webapp "faster," a la Ruby-on-Rails. Also, I'm considering Grails rather than say Ruby-on-Rails, because I want to continue to use the JVM and I've dabbled with Grails in the past and it was fairly easy to pick-up and use.

A: 

You can do all these things in grails. It supports all existing Java classes and spring configurations (grails is built ontop of spring mvc)

However, I really wouldn't recommend moving the whole application to grails. You can perhaps move only the web layer, if you have web developers that are not java experts.

The service layer, the data access, etc, better remain pure Java. That is, only your web controllers - the components that gather the user input, handle http requests and sessions, should use grails. The rest - the stateless service classes and your domain model would better be Java. That's my opinion, but I have already some experience with grails, and static typing in the service layer will save you much trouble.

Bozho
@Bozho: could you further explain what you mean by: "The service layer, the data access, etc, better remain pure Java." Are you suggesting that I use Spring/JPA/Hibernate directly rather than GORM?
MDS
yes. see updated.
Bozho
I disagree. GORM (along with the plugin architecture) is the most powerful part of Grails, so if you don't take advantage of that, you might as well just do pure Java.
Jean Barmash
@Jean Barmash that's personal preference. I myself would never write in a dynamic language, if I don't have to (for example forced by project), but it depends.
Bozho
+3  A: 
  1. Probably. Grails uses a sub-class of Spring's ContextLoaderListener class which it configures in the web.xml file. I can answer more precisely if you let me know how you do it with Spring MVC.

  2. Yes. You might even be interested in the CXF plugin, although I can't vouch for it:

    http://grails.org/plugin/cxf

  3. You should be able to use them as-is. However, you might want to check whether this is easily done with the Spring Security plugin. I believe it is, but you'll be able to get a definitive answer from Burt Beckwith, the author of the plugin.

  4. Yes. You can also get hold of the Hibernate session factory to do raw Hibernate stuff. GORM can also work with multiple data sources:

    http://grails.org/plugin/datasources

    Another Burt Beckwith one :)

  5. It depends on what you mean by "a combination of Groovy and Java". You can build Grails projects with Maven, but the integration isn't entirely smooth. If you have Java and Groovy in your Grails project, then that's taken care of automatically.

In response to Bozho, I use standard Grails services + GORM and wouldn't do it any other way. Note that if you use Java for services and the domain model, you won't have automatic reloading of services. You also lose the benefits of expressiveness and conciseness that Groovy bring.

If you want, you can use static types in Grails services to make it easier for your IDE to provide code completion. It can also give you hints on properties and methods it doesn't recognise (which would corresponding to Java compilation errors). That said, even if you use static types, Groovy can't do type checks at compilation time. You'll only find out about them at runtime.

Peter Ledbrook
The Spring Security core plugin is very customizable, see Chapter 7 at http://burtbeckwith.github.com/grails-spring-security-core/docs/manual/ - and you can always use Spring Security directly without a plugin just like in a regular Spring app.In addition to the Datasources plugin (which re-points some of your domain classes to another database), you can also create a second DataSource in resources.groovy and access it with groovy.sql.Sql or JdbcTemplate.
Burt Beckwith
@Peter: Thanks for the detailed response, it was very helpful.Btw, I'm loading the multiple contexts by specifiying them in the contextConfigLocation param, i.e. "classpath:applicationContext.xml"@Burt: Thanks for the heads-up on the security options; I wasn't aware the plugin was that customizable or that I could use Spring Security directly.
MDS
A: 

2) Yes you can use CXF as is. There is a nice layer on top of CXF called GroovyWS. I have only used it for consuming SOAP services, but maybe it has something for REST as well. It's really easy to use. For consuming REST services I have used HTTP Builder

4) Yes. You can continue to use e.g. spring config for configuring the datasource, or any other way you do it today. Multiple datasources is no problem.

5) I have recently tried using Grails (1.2.1) with Maven. It works, but there has been some issues with both Maven and Grails trying to do dependency management. The documentation is maybe the worst part. I haven't tried upgrading to 1.3 yet because of some major Maven-related JIRAs, but 1.3.2 is right around the corner, and those issues have now been resolved :) There will also be a 1.3.2 maven archetype. Looking forward to that. "Deployment and resolution of plugins from Maven repositories" is one of the new features of Grails 1.3, so things are probably better. Roadmap for 1.3.2 says release today, but there are 8 issues left at time speaking, so my guess would be tomorrow, the Grails releases are usually on time. If you can wait for that, you will probably save yourself some trouble.

rlovtang
@rlovtang: Thanks for letting me know about GroovyWS and HTTP Builder; both seem very useful and I'll have to look into both further.
MDS
A: 

If you are looking for rapid application development but aren't otherwise particularly enthused about groovy, you should look into spring-roo. It offers the same kind of RAD functionality, but builds a completely standard java + ORM + spring-mvc app (which has no actual dependencies (runtime or compile) on roo). It's definitely not as mature as grails, but you may find that it better suits your existing experience with statically typed java code and existing ORM, etc. I've only done a couple of small pet projects in roo, but I've been very impressed so far, particularly with how easy it is to customize the generated code and move back and forth between written and generated code. The initial tutorial is very rapid and quite revealing.