Coming from a J2EE dev background, I love the idea of Grails....all the benefits of using enterprise Java (Spring, Hibernate, etc. ), but with the simplicity of Rails (scaffolding, convention over configuration, Groovy scripting, etc.). My company is considering rolling out a new enterprise scale web application built on top of Grails. I heard there were some problems with stability and defects in earlier releases of the platform. However, I haven't seem many complaints since becoming part of Springsource.
I am curious if anyone has any opinions or experience in using Grails for large scale web apps. Is it stable? Reliable? Any gotchas I should look out for? Any other observations? Thanks!
Short Answer
Yes
Longer Answer
Stability and reliability of the core has improved considerably since 1.0. It seems that each new release introduces a few bugs, but workarounds/fixes tend to emerge pretty quickly
In terms of performance, Grails has always been adequate (for my purposes). Given that Grails is really a Groovy DSL for Spring MVC and Hibernate, and most of Grails is actually written in Java, it would be surprising if Grails' performance was substantially different from a Java web framework like Spring MVC.
The situation is very different when it comes to Grails plugins. Most of these are maintained by the community rather than the Grails team and are much more likely to be abandoned, or fail to keep up with newer versions of Grails. The officially supported plugins (e.g. Spring Security) are of course an exception to this statement.
For some previous discussion on this topic take a look at
Is Grails worth it? (from late 2008)
Is Grails (now) worth it? (from 2010)
I'd say yes, as long Grails 2.0+. With Grails 3.0 which is based on Spring Boot, you can improve developer productivity a lot more.
This Pivotal article justifies it.
http://blog.pivotal.io/pivotal/case-studies/netflix-amazon-asgard-groovy-grails-elastically-scaling-apps-for-40-million-internet-tv-viewers
Related
I've been using Spring for about a year, and I'm comfortable enough using it, but I've avoided jumping under the hood for the most part.
I'm tasked with upgrading a large, mission critical enterprise application, from Spring 3.0.x to Spring 4.1.x.
What are the best practices for making a large, inevitably finicky and complex change like this? (Anything above and beyond 'throw in the jar files and see what happens' and 'read the documentation here: http://spring.io/' would be very helpful)
The system:
Java 6 - jax-b/-p/-ws/, Apache Commons,
Spring 3.0.5 - the usuals (core, context, beans etc), MVC, AOP, ORM, JDBC, Acegi
Hibernate 3.5
Tomcat 6
0 unit tests or automated testing of any kind.
Maven dependency management and build automation.
Half controllers using annotations for request response mapping, half using simpleFormController pattern, half autowired, half hooked up with xml.
Hundreds of views, scores of controllers.
Steps I've taken so far:
Prepared a (mostly automated) regression testing script (so that I can ensure I haven't broken anything)
I've started reading through the 'upgrade guides' one at a time, "upgrading to 3.1", "upgrading to 3.2" and making notes on things that sound familiar, but I think I'd need to have a much deeper grasp of our system, and spring in general, before I could be confident of this as an exhaustive approach. This just generally feels like a haphazard approach, which is not what I want for such a complex change.
My questions:
What steps/procedures are considered 'best practice' in these for a job like this?
Does anything jump out at you as a 'gotcha' for a job like this?
Obviously, there won't be "standard" set of recommended practices because every migration/upgrade is different. Here're my thoughts:
Requirements, requirements, requirements
Regression testing script is great start. If there is a complete documentation of the features/functionality, then your "success criteria" for migration is straightforward.
If the documentation is incomplete/non-existent, then double and triple check to make sure that all 'requirements' are captured with your tests. Might be a good idea to create documentation too. And have the product manager/supervisor sign off on it. You'll be surprised at how many 'hidden' requirements exist even in simple systems. There is a big risk of underestimating the effort needed for migration without comprehensive requirement.
It is extremely critical to set the right expectations in terms of timelines. Perhaps an agile approach with biweekly demos of how much progress you've made will help keep everyone on the same page.
Spring projects have evolved a lot. Budget for learning time.
This could be a big gotcha. Spring projects and Java development have evolved a lot since Spring 3.x. Big changes include:
Java 8 features
JavaConfig (as opposed to xml configuration)
Acegi is now Spring Security
Spring projects typically use Spring Boot
Switch from Maven to Gradle for building projects
Full CI using Jenkins (or other CI tools)
Unit and integration testing have moved on to using annotations (and mock frameworks)
Well, it is not easy to answer you question since there are many things to be taken into account.
First of all I can suggest you to use the Migrating from earlier versions of the Spring Framework guide that's coming directly from the 'source'.
I would especially draw you attention to the 'Enforced minimum dependency versions' section that recommends you the minimum version level of some wide used libraries.
Obviously in the moment you insert these new versions they're bringing with them some transitive dependencies that might generate conflicts.
Take also a look to the dependency updates section.
Also remember to correctly define the scope of the dependencies in your pom files, since many of them could be provided by the infrastructure you're using (i.e. Tomcat).
I think you will be required to move to Java 7 or 8 and also Tomcat should be updated to version 7 or better 8.
Moreover try to automate as much as you can your building and testing environment with maven along with adopting a CI environment like Jenkins (or Hudson if you prefer the product).
It is also very important to perform unit testing of every single little method/piece of code, since it will make integration tests easier.
You should also become familiar with Spring 4.x new features and try to exploit them especially those regarding testing improvements.
A little resume of new features is the following:
Removed Deprecated Packages and Methods
Java 8 Support
Java EE 6 and 7 become the baseline
Groovy Bean Definition DSL
Core Container Improvements
General Web Improvements
WebSocket, SockJS, and STOMP Messaging
Testing Improvements with extreme use of annotations
Take also a look to Spring MVC Test Tutorial by Petri Kainulainen that can give you a lot of informations about testing.
You have to have answer to the following before you proceed.
Is the need to upgrade is only the libraries and runtime for some sort of dependencies ?
OR
You really want to get the most out of Spring 4.x ?
Once you decide this you can take proper course. Those regression scripts you have created will help in both the scenarios. If you can think of some crude throwaway utility that will hit every public api with some valid input and capture the output and be able t compare this in the both worlds that may help but it may not be applicable in your situation.
So if you want to get the benefit of the Spring 4.x I would suggest you focus on productivity aspects and create an inventory of these things.
You may redesign the whole app in Spring 4 as if it is a new application.
Once you can envision the future state. The next problem reduces to going from Point A to Point B i.e. a matter of best migration path.
From Migrating from Spring 3 to Spring 4, you would probably get some help from the Spring project's
Spring Integration 3.0 to 4.0 Migration Guide on Github.
Hope it helped!
I was considering using the Play! framework on Google App Engine for a simple to medium complexity web application.
It looks like I am limited to Play 1.x. The GAE module 1.6.0 is supporting GAE SDK 1.6.0 and when installing it says it supports Play 1.2.4. The Siena module 2.0.6 says it supports Play 1.2.3.
I feel like the whole setup I am thinking about is completely outdated and the components are not active at all. Is that the case? This will be a production web application that will be used by hundreds of thousands, I can't afford any integration issues or bugs that won't be fixed by updating the framework or the modules just because there are no new releases. I feel very limited with this setup.
I can't change GAE as the platform but I can choose any other framework with better support, the only reason I was thinking about Play is because it seems flexible, easy to learn, fast to develop and not bloated. I don't have the time to spent/waste on understanding and configuring frameworks like Spring or similar.
So, am I right thinking this is a bad choice? And if yes, what would you recommend for a Java developer on GAE?
If you are willing to consider Groovy, how about Gaelyk?
I'm looking for good java MVC web application development kit (or framework), with servlet engine, database persistence layer and viewer layer included and ready to go? One example is TDK (Turbine Development Kit), but it's kinda outdated, and their M.E.T.A. is very hard to work with (it uses maven 1.0).
Thanks,
David
There's AppFuse and Roo if you're looking for "make it go".
If you're not dead-set on Java, there's Grails (and JRuby on Rails).
Give a shot to AppFuse. It will leverage either Struts 2 or Spring MVC for you, with a nice persistence layer.
There are many good 'stacks' that you could use, some of which have already been mentioned.
They all have their own strengths & weaknesses, and you really need to select a stack that best fits your requirements.
The Spring/Roo, AppFuse & Seam are all great, but they do come with a certain amount of... errm... bloat.
You may find that picking and mixing technologies actually provides you with a lighter weight and more performant solution, so long as the technologies you choose integrate relatively seamlessly.
If you're looking to package a full execution environment including the servlet engine as part of your application, Jetty is a good choice, and you can easily integrate it into a Maven build environment.
You may also want to investigate using HyperSQL for your database, which will allow you to prototype using an SQL compliant database without having to worry about installing a full database manager such as MySQL or PostgreSQL.
I last installed Spring a few years ago and back then it was just some jars I had to add. Now after I googled for Spring, it brought me to SpringSource, a division of VMWare.
It took me through a whole installation process for the SpringSource Tool Suite and it looks cool, but is also bulky.
What are people doing for a robust and lightweight Java MVC framework these days?
Well, Spring MVC is a robust and lightweight Java MVC framework these days ;-)
One "problem", though: it uses Spring itself (of course), which has gotten much bigger over the years. What was once just a dependency injection framework, today is almost a complete Java EE replacement. Meaning: if you want Java EE without a true application server, then use Spring. And that boils down to using Tomcat with Spring in most cases.
So, the true answer is: you can still use Spring without much hassle, but use only what you need, if you really need it. Spring originates from 2003, when Java EE was a real pain in the neck, but nowadays Java EE has gotten more and more simple, almost to the point that it's preferred over Spring, especially EE 6.
Springsource Tools isn't needed for using Spring, but it is recommended for efficient Spring usage. If you stick with XML configuration, lack of tools assistance will hamper you in the long run.
My little rant is over, so I hope I helped you at least a bit.
Springsource Tool Suite is their customized distribution of Eclipse, and no you don't technically need it. You still only need the jar files, which can be found here.
You don't need SpringSource Tool Suite.
Spring is still the most popular lightweight Java MVC framework.
Spring is splitted into different modules (projects) to avoid big dependencies if you don't need them.
List of projects from springsource
spring-framework-3.1.0.M1.zip is 25.6 MB and can be found here
Have fun!
I need support in order to speed up development process. I received a request to start developing a website with java technology. I usually develop in C# - ADO for Entities - ASP.NET MVC - MSSQL server - Visual Studio. Best of these choices were:
- C# Intellisense.
- ORM.
- Complete Security Management of Users, Roles.
- Separation of Concerns into MVC.
I was wondering if any can help me to determine best Java MVC Framework - DB - IDE based on these premises, Start a project with:
- Integrated security for users, roles
- MVC
To shed more light, to replicate same functionalities I can have each time I start a website using C# ASP.NET MVC 2 project. example http://nerddinnerbook.s3.amazonaws.com/Images/image020.png
First, let's discuss IDE, ORM, and security, and DB: In my opinion, the best Java IDE is IntelliJ IDEA. It's from the same folks who have developed Resharper for Visual Studio. It has the most powerful editor of all Java IDEs and has built-in support for many popular Java frameworks.
ORM: The most powerful ORM library in Java is Hibernate. Hibernate itself is an implementation of Java Persistence API (JPA) standard. EclipseLink is another implementation of JPA, but Hibernate is a better option IMO.
Security: Spring Security is probably the most powerful security (authentication and authorization) framework available in the Java world.
DB: If you are comfortable with SQL Server, then keep on using that. However don't use Microsoft's JDBC drivers. Instead use a driver from DataDirect: http://web.datadirect.com/products/jdbc/index.html. If you don't want to use SQL Server, MySQL is a great FOSS choice and Oracle, DB2, etc. are other options.
For the Web framework, there are several options:
Option 1: If you want a RAD style framework, choose Grails. Grails is similar to Ruby on Rails but uses JVM and a Java-like but dynamic language named Groovy. Grails' ORM API is called GORM, which is built on top of Hibernate, but is much easier to use. Grails also uses Spring Security for managing security.
Option 2: If you want an enterprise-grade framework, choose JBoss Seam + JavaServer Faces. JSF is a component-based MVC framework, and there are plenty of great JSF libraries available for use: RichFaces, OpenFaces, etc. Seam integrates JSF with EJB and together they make a great enterprise framework. However it has a steep learning curve.
Option 3: Use Spring + SpringMVC + JPA.
Option 4: Use Struts 2 .
Final remarks: If you are looking for an easy-to-learn MVC + ORM framework, use Struts 2 + JPA. If you are looking for a RAD and easy-to-use MVC + ORM framework, use Grails. If you are looking for a robust and enterprise-grade (but not-easy-to-learn) framework, use JBoss Seam.
Not only Spring MVC but the whole Spring eco system will get you up and running with the least surprises. You can also download the Spring Tool Suite (a preconfigured eclipse version tailored for Spring) to get an integrated development environmanet which knows about all spring stuff.
But Spring - Spring MVC - Hibernate - Spring Security and STS seems to cover your needs and will provide a sound basis to do the project without too many bad surprises. This leaves you to focus on the customer and the jump to Java.
Afterward you might consider different options in the Java space, as there are plenty of other frameworks available with their strong points. But in the short run it is better to limit the number of moving parts
The standard, most common framework/orm setup is spring/hibernate. Both of these tools have unfortunately been grown to ridiculous extremes over the years, so they may seem daunting in size, but a simple setup with each is much easier than it may seem from looking at all of the options on their respective sites.
Best suggestion would be to follow a step-by-step to get a basic spring/hibernate setup going and just expand off of that. At one point I had a prototype project like this I'd use to generate a "starter-set" to bootstrap projects.
BTW, I'd also suggest a simple ant build script. Some people may suggest maven, but it's enormous and very (imo overly) complex, and you're going to have enough new tools to wrap your head around to want to avoid having to learn another large command set.
Welcome to the Java world. The best thing (and in some cases also the worst thing) about the Java domain is that you can create your own stack based on your requirements. You're not necessarily bound to a single vendor as is commonly the case in the .NET domain.
Since it seems you're in a greenfield situation you can:
Adopt the webdevelopment stack of a large commercial vendor like Sun/Oracle (JSF/EJB3 + NetBeans/JDeveloper + Glassfish/Weblogic + MySQL/Oracle) or IBM
Adopt the webdevelopment stack of a smaller open source vendor like JBoss, SpringSource.
Take a look at JBoss Seam and SpringSource Grails and Roo (the latter two are based on the frequently mentioned Spring/Hibernate frameworks)
Mix and match your own stack based on the above and your requirements. Although this requires deep knowledge of the various technologies, frameworks, tools available.
You have lots of options as you can see. Now since your interested in a productivity focused stack - and I suspect an opensource one - and you have no legacy I recommend either Grails or Roo. In which Roo is probably the most accessible one since you don't have to learn Groovy. If you don't like the generation tooling I advice you the stick to the Spring stack and just adopt Spring/JPA/etc.
As for IDE, the only Java IDEs worth their salt IMHO are Eclipse and Netbeans, especially since both of them are free. Use Eclipse for extensibility and ease-of-use, use Netbeans if you need to rapidly develop a GUI.