I'm new to grails. I'd like to give it a whirl by implementing a new feature or two into an existing Java EE application. The current Java EE app is a fairly standard Spring MVC/Hibernate app running on Tomcat. Looking through the documentation, it looks like I should be able to leverage all of the current business logic that's written in Java.
I've only been able to find tutorials on creating new grails applications. Does anyone know of a tutorial for integrating with an existing Java EE app? If not a tutorial, any recommendations or suggestions on where to start?
Whether or not those features go live would depend on my experience with Grails and if I think it's worthwhile using it going forward. The goal would to either:
Decide Grails isn't for me (and not deploy grails).
Decide it is for me, and all future development on this app would be in Grails with a full eventual port over.
I'm afraid I don't know of any such tutorials, but my immediate thought would be that porting an application while also combined with learning Grails could be a big uphill.
I haven't done this sort of thing before, so these are just musings on how I might approach doing this..
Since GSPs are not analogous to JSPs and since Controllers in Java are statically typed, whereas Grails controllers have magic methods wired onto them, I would probably want to re-write those again in Grails from scratch since their transferability isn't obvious - the logic should transfer but the boilerplate of the old code isn't altogether necessary for the most part.
Maybe take a simple story/feature, keep the existing Services it uses and get them wired in via Spring in Grails. Then try making one for one copies of what you have in Java with corresponding Controller/GSP and Domains. That should give you some feel of what stuff you need to get off the ground for the port.
Your biggest struggle, from people who I have heard of doing this, might well be trying to re-use your existing hibernate stuff in Grails.
Just my tuppence, not so much a whole answer...
Insert Grails into an Spring app is not easily achievable, you can try to insert the old Spring app into a Grails app, and continue from that point.
Here you've some info 'bout using the hibernate mappings and java classes.
You also have to have to add the beans of the Sprint app to the Grails app. You can insert them into the ApplicationContext directly or use the resources.xml or resources.groovy.
It depends on how you've written the Java EE app. You cannot drop it into the Grails runtime and expect it to work with no tweaking, especially the 'controller' part of your app (since grails uses its own conventions for that). The UI, if its jsp, may be a bit better, since you can probably rename them to gsp, and have it work. tag libs works straight away, and normal java classes work straight away obviously. Hibernate objects may need tweaking - though i suppose it may just be easier to redo those using grails.
-my 2cents
Related
I have a small Java web application built and I'd like to convert this to a Grails web application. My Java web application consists of Servlets, entity and hibernate for the database, and plain old java objects classes. So What's the best way of going about doing this?
I agree with Joshua for the most part. I have helped prototyped moving a java web service to Grails. I would first start with understanding the roles of the classes inside Grails (Domain classes, Controllers, Services, Filters, and CommandObject) and mapping on a whiteboard what does those roles in your current application. With hibernate as the database layer, that should be easy to port, and many service like classes can be moved over as-is. The tear up is going to come at the controller level, so make sure you think that through carefully.
You might think about refactoring your code in the Java space first if your current application does not separate responsibilities well. The cleaner your code, the more you can re-use as Grails services.
Starting with an empty Grails project I would begin by using your existing POJOs and creating Domain classes in the Grails project. From there I would then begin to model the behavior of the Servlets into Grails controllers, services, and filters. Finally I would finish with cleaning up the views and applying the styles.
That's how I would approach converting it.
For my organization I am evaluating RICH technologies for our next projects.
We are currently using grails 2.1.0 and very happy with that, especially with groovy and gorm and we would like to stay with that. The idea is to extend grails with some RICH framework/library. Currently I am evaluating: grails plugin for ZK, grails plugin for Vaadin, knockoutjs, angular.js, ember.js.
I already received a feedback from my colleagues who worked with ZK (no grails) and their conclusion was: cool, but forget performances, ZK goes to the server every time you do something at client side.
My question is: is this also true with Vaadin (plugin for Grails) ? How does it react with heavy single page applications? and what about Bambi? can this be an option?
On paper grails + Vaadin is what we need: we want to write groovy/java, not xml and surely not javascript. Is this the right choice?
I know my question is very generic, but I am just at the beginning of the evaluation...
Thank you for your attention!
Vaadin works perfectly with Groovy and Grails. You can get services (actually spring beans) by using Grails.get() method and do localization via Grails.i18n() method. Because all the code is going to be written in Groovy, not Java, it will become less heavy (less lines of code and so on...).
Vaadin doesn't go with ever user action on server. You can influence that by setting setImmediate(false) on whatever component.
When you make complex application in Vaadin, you need to be careful how many components you put on the page. If you expect that there will be thousands of components on single page, then browser renderer will have performance issues with handling it (of course speed of rendering depends on your computer hardware). More hints is here.
I recommend - try to build UI in Vaadin and fake database. Then see the performance and then switch to the real database. Usually people blame Vaadin but the problem is elsewhere e.g. in database, indexing, loading to many items at once...
If you don't want to play with JavaScript, then I suppose knockoutjs, angular.js, ember.js are out of the game.
You need to find out, whether the Vaadin components are what you need. I really suggest to try it out and make Proof of Concept in Vaadin. If not, Vaadin 7 simplifies integration with JavaScript! So, you can easily integrate Vaadin server code with whatever JavaScript library (e.g. highcharts and so on...).
You will need to get your containers lazily loaded (check this)
I think you should start with Vaadin 7 (here is a tutorial)
There will be more performance optimalisations in Vaadin 7 (in versions 7.0.1 or 7.0.2)
I am fairly new to Grails and I have a requirement that I don't know how to implement.
I need to make a process that will be running along the side with Grails application and making remote calls, process received data and writing it to DB so that Grails application can make use of it.
So far I figured that I need to leverage domain controllers, but I am not sure how to make a separate process that is constantly running in the background and updating DB.
Is it possible? Can I get references or code examples.
Thank you.
Your best bet is Quartz via the http://grails.org/plugin/quartz or http://grails.org/plugin/quartz2 plugins. I've used the quartz plugin and the Job classes you create are artifacts (like controllers, services, etc.) so they support dependency injection. Services are the best place to do transactional database work, so inject one or more services into your Job classes to handle database work.
The quartz2 plugin is newer so you may have more luck using it in current versions of Grails, but it might not have all of the features of the older plugin.
I'm building a new SAAS application and was looking for some advice on the most appropriate framework to use. I realize that no single framework will likely be able to do all this, but I thought I'd ask the community and try to find one that solves the hardest problems.
Requirements
Single code source. (each customer will have either a subdomain, or a distinct domain, but everyone should be running off the same code base and same servers)
Should be able to update the programming source once and have all the tenants pick it up
Session information should either be kept in a cached store, or just in cookies (no shared state)
Multi-tenant database functionality built in. (Based on the domain used to reach the application, the framework should automatically use the database connection information assigned to that domain)
Each customer/domain may have their own template for the web pages. Templates need to be assignable on a per-customer basis and kept outside the application code
Security and rapid prototyping is more important than speed
There will be a lot of CRUD type screens, so simple built in functionality for this is desired
I have pretty lengthy Java and PHP experience, but would only consider PHP as a last resort for this. My Scala, Python and Ruby experience is a bit rustier, but I would not mind coming up to speed if they offer a significant advantage. I've looked at the Play! Framework and like it (fulfills #1, #2,#6 very well), but the multi-tenant aspects are not very strong. I've done several projects using Grails and it handles everything except #3 and #5, and can be hacked to do the rest.
I would say that the third point is rather independent of grails/play/whatever in general. If you need a shared cache there is a multitude of providers for this and there are plugins for most of them in Grails.
The multi-tenancy in grails is pretty mature and much less intrusive than the solution from the blogpost in Sebastiens answer. Whether or not you use single tenancy (multiple databases) or multi tenancy is more or less transparent to your code and most of the headaches are abstracted away. Do be aware that you need to do some smart indexing (like including the tenant id in a multi column index etc) to not get very sad speeds when your data starts to grow.
As for externalized views, you can either slap them in the database or symlink them into your webapp and just keep them in separate numbered folders. Then from the tenant plugin, you can use TenantUtils.getCurrentTenant() and simply render from the appropiate folder "/" + (tenantID ?: "default") + "/whatever/view/path". This way, layouts etc can be shared across tenants if you so please and you simply put tenant specific stuff in the tenant specific folders.
You can probably do this in play too, or , but I don't see anything hindering you from doing this just fine in Grails.
My $0.02 on this question.
Actually Play! fits well to what you'r looking for.
Read this post:
http://www.lunatech-research.com/archives/2011/03/04/play-framework-writing-multitenancy-application-hibernate-filters
It works great. You can even make this filter work so that you can expose the crud module to customers and they'll only get their own data...
For very large applications, sharding seems not supported yet (no hibernate shards handled yet i think).
There's a multidb plugin to work with multiple db, but it seems not working very well yet...
I've heard that Grails' Multi-Tenant plugin offers some good tooling for several different methods of multi-tenancy.
"Each customer/domain may have their own template for the web pages.
Templates need to be assignable on a per-customer basis and kept
outside the application code"
I assume you mean they each have their own layout/skin. There are several techniques to execute this:
You could manually assign layouts based on tenant. <meta name="layout" content="${tenantName}/main" />
Write your own tenancy aware LayoutDecoratorMapper and override the default GrailsLayoutDecoratorMapper in sitemesh.xml
Figure out how to override and enhance Some internal tools dynamically resolve views(per tenant) or resources (GrailsViewResolver, GrailsConventionGroovyPageLocator, GrailsResourceLoader, etc.)
In PHP you can use Innomatic Platform for building multi-tenant (isolated databases) applications:
http://www.innomatic.org
If I know Rails, what new ideas/patterns would I learn if I looked at Grails?
I have no intention to move to Grails and no need for a Java stack, but if there are neat ideas I could learn from Grails I'd like to learn them.
Grails has taken totally different direction. It is very hard to compare Grails and Rails.
Grails is not framework. It is stack of frameworks. You can find all the features you find in plain Spring, Hibernate, Quartz, Compass, Sitemesh frameworks. So at the end you get all the best from all these frameworks with convention-over-configuration.
However, I really want to mention about very interesting idea introduced in Grails about modulizing the application into plugins. Plugin in Grails is minimized independent project. Separating application logics into plugins allows to share your code to community and keep application in separate modules which results in easier testing and easier development.
Grails has at least two patterns I'm aware of that I believe do not exist in Rails:
Command objects (and auto binding request params to them)
Conversation based request handling using web flows