We Keep Coding

migrating a whole application from simple Java to Spring MVC

I have one simple application running on simple Java code.
There is one server which takes data from client and just prints it back.
Now i want to move this application to Spring MVC so that my server will be running 24*7 and any client can be instantiated from web.
So what are the changes i will need to do ??
if required can explain in detail and also post code.

Start by getting the Spring Tool Suite and use that for your IDE. It's been a great help, since it comes with project templates, like MVC, that you can basically just plug your existing code into (assuming your code is already written in a way that can be used by other applications).
Once you have a basic MVC project, you can slowly add in your own code.
For more complete examples of Spring MVC form applications, the Spring Security project has a number of good samples. The important parts for you will be the methods inside the controllers that deal with form input, and you can ignore the security stuff for your application.

Drools with Struts

We want to integrate DROOLS with my current web Application which is based on struts 2. Is there a sample Application which could be used as reference?
Generally we are seeing all application use Spring+ Drools.
Also later on can it be possible to integrate Guvnor for a GUI of the rules created?

Yes it is possible. Drools is not tier specific, you can plug it into you Java application however you see fit. As a general rule you would incorporate it into your service tier, where all the heavy lifting is done.
Drools needs very little configuration (in many scenarios it needs none at all). Simply drop the applicable JAR files into your library folder and reference them in your classpath.
I actually built a prototype application for a client using Yahoo UI, Struts and Drools. It works like a charm (can't share the source unfortunately). To wit, you are definitely not tied to Spring.
As far as your second question, note that using Guvnor to manage rules and accessing those rules from your app logic are two totally separate things. The Guvnor governance application is bundled as a web app that you deploy on a server. Once deployed it provides a very nice interface that you can use for managing a rules repository. To use those managed rules in your application you need to include the appropriate JAR files in your application and do some configuration.
I would recommend standing up a simple application first that simple executes some rules in an embedded DRL, before attempting anything more complex like integrating with Guvnor.

Considering moving from Java/Spring MVC to Grails

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:
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?
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?
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?
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?
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.

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.
Yes. You might even be interested in the CXF plugin, although I can't vouch for it:
http://grails.org/plugin/cxf
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.
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 :)
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.

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.

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.

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.

Web Development In Java Using Netbeans

I am trying to implement a web application(university project) in java using the following Frameworks
Spring Dependency Injection
Spring AOP (Logging and Transaction Management)
Spring DAO
JDBC or HIBERNATE
Spring MVC
Log4J
I create a new Web Application in Netbeans and it gives me a bunch of Files and folders by default.
Could anyone explain me what are the files ?
Where shall i put the code for the data access layer and business Logic?
Or where can i found a basic tutorial to get started(with data access layer, business layer and possibly code example)?
Thanks

One area in which NetBeans is very good is the online documentation and tutorials so leverage them:
Introduction to the Spring Framework
Developing a Spring Framework MVC application step-by-step using NetBeans and GlassFish
Using Hibernate in a Web Application
etc etc

That is a ton of Java frameworks for a Web Dev course at a university. My advice would be to start small, because you don't need all of those libraries to get a working web application.
As you found, Netbeans is doing a lot of work for you that you really need to know to be effective. Do a simple JSP or Java Servlet tutorial to get something up and running quickly from scratch on a lightweight app server like Jetty or Tomcat.
Also, please take a look at what Model View Controller architecture is prior to diving into Hibernate or SpringMVC. This is a critical step!

It would be good to list the files that you got, but I think I can guess:
WEB-INF/classes is where your compiled .java code will go. Everything should be in packages, so the directory and package structures should match. Your Spring XML and Hibernate .hbm.xml configuration files will go here as well, because that directory is automatically in the CLASSPATH of your web context.
WEB-INF/lib is where your 3rd party .jar files go. All the Spring and Hibernate JARs, plus all their dependencies, belong here.
The WEB-INF/web.xml is where you'll map in the Spring front controller/dispatcher servlet, the context loader listener, etc.
I don't know what others you got. If you list others, I'll try to explain.

Here is Netbeans web application + hibernate tutorial.
http://netbeans.org/kb/docs/web/hibernate-webapp.html
code for business and data access would go under
your project name/Source Packages/

Thanks for your input, Drew.
I'm working on a Capstone project and we are thinking about using Netbeans for our Web-based project but were unsure about how difficult it would be to make the Web Based application in a relatively short amount of time. The application is for a College Testing Center and the application will track testing information and data for testing personnel and instructors at our college. I was going to try and follow a few tutorials here on the Netbeans site.
Thanks for your time.
PHP and HTML5 Learning Trail with Netbeans..
Here's a video as well.
Youtube Simple Web App instruction video.

appfuse vs roo - what would you use

Appfuse vs. Roo, what would you use and why?
What are the sweet spots of each.

As per the answer I gave to TheServerSide thread on this issue...:
AppFuse aims to provide a single initial scaffold of your new project. This is similar to Maven archetypes or Eclipse's "new project" features in that you run them once at the start of a new project and then you maintain the scaffolded code going forward. The scaffold system has no further involvement in your project once you've run it once.
Roo, on the other hand, provides a round-trip aware active code generator for your long-term usage on a given project. As such Roo offers value both at initial creation time as well as whenever you are modifying the project going forward.
In practical terms this means as you evolve your project, Roo will automatically maintain certain files. To take a simple example, when you add (or remove) a field, Roo will update the toString, getters/setters, JSP pages etc for you automatically. It also offers commands so you can add new capabilities later. So if you need to add security six months after you created the project, you just "security setup". Or if you need to send emails, you just "http://static.springsource.org/spring-roo/reference/html/command-index.html#command-index-email-sender-setup". There are similar commands for many other capability areas well, such as Spring Web Flow, JUnit, Selenium, common JPA providers etc. You just defer the decision as long as you like, and Roo will only add those capabilities at the time you ask for them (and it will also automatically use those new capabilities in your project).
There are many other differences as well. Roo allows extension via user-developed add-ons, it offers a highly usable shell, it allows you to incrementally build a new project and add features only when required, it extensively supports the latest versions of the major Spring technologies, it comes with a SpringSource-developed (and therefore endorsed) application architecture and so on.
A read of the Roo Reference Guide's Introduction Chapter or simply completing the ten minute test project will illustrate they are very different in approach.

My notes on AppFuse and Roo:
AppFuse
Is a fully working template application/project.
Traditional DAO <-> Service <-> Controller architecture
Easy to get started with maven archetypes
Great documentation and tutorials
Not really up to date. Spring 3 final is soon to be released and AppFuse is based on 2.5 (?)
Spring Roo
Spring Roo on the other hand is a tool that speeds up development by using code generation.
Getting started with a new, fully configured project takes 1 minute
Creates rich domain objects where CRUD are weaved into the domain objects using AOP instead of traditional DAOs/services
Hard to grasp if you are new to Spring
Documentation is not that good yet
Really cool! I.e. add Spring Security to your project with just one line of code!

Telosys (a lightweight code generator) is also a good alternative. See
http://www.telosys.org/
It produces very clean code (without adherence like ApectJ)
and the templates are customizable
There's a stack of templates designed to generate Spring MVC web apps (and many others to generate code for other kinds of frameworks).

for me Appfuse but it is not up to date, but the spring roo using aspectj and there are parts of code you should not touch and I do not like that.

Spring Roo
Pros.
1.
Customizable : You add and remove diffrent framework and addon as per your requirement.
Database Reverse Enginnering : Create CRUD applications if you have database schema ready.
Strong Spring community support.
NOSQL MongoDB support
Can create required add-ons.
Cons :
Require in depth knowledge of Aspect oriented and Spring stack.
Require little more time to learn spring roo as compared appfuse.
Appfuse:
Pros:
Good one to start small and mid-size enterprise application with
struts, JSF and Spring
Complete open source code.
Enough documentation.
Twitter-bootstrap ready.
Cons:
Customize application but not like Spring roo.

For starters, roo looks more over engineered, with code generation, use of aspect oriented programming and more.

Appfuse doesn't seem to be maintained anymore seeming that the last version was released on May, 2008.
Roo it's right now a little bleeding edge, because of the use of the still-unreleased version 3 of Spring Framework, but that will change, and that version brings a lot of interesting changes to the table.
It also upsells you on more of the Spring technologies portfolio, such as STS and tcServer, and makes it dead easy to use Spring Security and Spring WebFlow.

I am going with ROO.
I am already using
Spring
Spring ORM/JDBC
Spring MVC
Spring Remoting
STS (Tool-suite)
So my preference is SpringSource products, AS I am already familiar with API style, documentation, conventions of SpringSource and even their coding practices once I extended/implemented security-framework's code.. ;-)
so, my advice is go with the tool/framework which is more natural to you..
Cheers,

AppFuse -> change to SpringFuse
I more prefer use SpringFuse

The question is some years old and in the meanwhile there are new productivity tools I want to point out:
Generjee. Generjee is a full-online tool. You define online your requirements and the (optional) data model. Then you get the generated code as a download.
The generated code is independent from generjee. The tool is useful for starting development projects from an integrated full-stack code base.
generjee will generate for you:
JPA code according to your data model
JSF code to create, read, edit, filter, sort and export data
user management, registration and login
your defined user roles and specific access permissions for this roles
I18N support
file upload support
Forge. To describe it in some words, it is "like Roo". But Forge is not as strong based on Spring and AspectJ as Roo.

AppFuse has integration with Tapestry, Wicket and other Web frameworks which Roo does not - yet

The AppFuse project was shut down in April 2016. Its founder, Matt Raible, recommends using JHipster as an alternative.