We Keep Coding

What are the prerequisite for Spring Roo

I have got my hands dirty in Spring Roo, I have managed to do the persistence set up for Oracle Database. Although I have gone through the Roo documentation
but it not enough for me to understand the working of this framework.
I'm not aware of Spring-MVC ,Spring-Web Flow and AspectJ rather I have knowledge of frameworks such Struts, Tapestry and GWT. Could this be a hindrances in learning Spring Roo.
Please advice as I'm running out of patience of hacking the generated code by Spring Roo. Is it good idea for me to jump in a Spring Roo project?

The Spring Roo is more than a code generator. If you make changes in your Entities, it will change the codes automatically. More like a stateful code generator. First you need to find out the commands available in Spring Roo to configure a project.
You can configure which database you want to use, which orm you want to use, whether you want to use unit-tests or which view technology you want to use. Give the commands and Roo takes care of it. You don't need to worry about which libraries to download, how to make pom file for Maven.
The configurations you got using Spring Roo is quite a standard one. I used it in the previous projects. The code generated is not optimal, for example , you can use generic daos instead of Roo generated DAO if you consider the generated codes are verbose.
Another example says, in Flex, you can use Roo to generate configurations for the communication between Flex client and J2EE server. For my case, I use parsley and observer patterns for flex client instead of the codes generated by Spring Roo. But by looking at the codes what the Roo-Flex team wrote taught me quite a lot of things too. The same things goes for GWT and Spring MVC.
So what am I saying is that as the programmers, we need not only to code we also need to read what the other wrote too . I strongly believe that it is a good way to learn and share best practices. You might get some boilerpate codes, but if you know how to apply design patterns or can enhance on them, those codes will become the gems.
Learning curve ? Not at all. The commands are as simple as DOS commands.

Spring ROO is just a command line interface for generating a lot of the boiler plate code you usually need to write to get things done in java projects.
If you want to add GWT into your project, just type "gwt setup" after you've created your models and you have full-on GWT support in your project.
The default view being generated in Roo uses Apache tiles, similar to Struts, Tapestry and JSF.
If you want to use web flow, just type in "web flow" and it'll be integrated for you, for struts support, you'll need a plugin, I've seen a couple of them floating around the web, haven't tested any of them; same goes for tapestry, you can either use a tapestry plugin or do the integration by hand.
AspectJ in the context of Roo generated scaffold is used to hide all the boilerplate code that makes code look like spaghetti, you can move code out of the aspectJ generated files into your own java files and modify them if you need to.
As for the hacking, it takes a lot of patience and time to fully understand where you should change stuff and where you shouldn't, all I can say is, happy hacking :-)

springroo is based on many technologies, but all what springroo does is to help you to generate scaffolding code using lots of addons you can install
at least it's my view of this framework after three days of learning it

How to modularize a JSF/Facelets/Spring application with OSGi?

I'm working with very large JSF/Facelets applications which use Spring for DI/bean management.
My applications have modular structure and I'm currently looking for approaches to standardize the modularization.
My goal is to compose a web application from a number of modules (possibly depending on each other). Each module may contain the following:
Classes;
Static resources (images, CSS, scripts);
Facelet templates;
Managed beans - Spring application contexts, with request, session and application-scoped beans (alternative is JSF managed beans);
Servlet API stuff - servlets, filters, listeners (this is optional).
What I'd like to avoid (almost at all costs) is the need to copy or extract module resources (like Facelets templates) to the WAR or to extend the web.xml for module's servlets, filters, etc. It must be enough to add the module (JAR, bundle, artifact, ...) to the web application (WEB-INF/lib, bundles, plugins, ...) to extend the web application with this module.
Currently I solve this task with a custom modularization solution which is heavily based on using classpath resources:
Special resources servlet serves static resources from classpath resources (JARs).
Special Facelets resource resolver allows loading Facelet templates from classpath resources.
Spring loads application contexts via the pattern classpath*:com/acme/foo/module/applicationContext.xml - this loads application contexts defined in module JARs.
Finally, a pair of delegating servlets and filters delegate request processing to the servlets and filters configured in Spring application contexts from modules.
Last days I read a lot about OSGi and I was considering, how (and if) I could use OSGi as a standardized modularization approach. I was thinking about how individual tasks could be solved with OSGi:
Static resources - OSGi bundles which want to export static resources register a ResourceLoader instances with the bundle context. A central ResourceServlet uses these resource loaders to load resources from bundles.
Facelet templates - similar to above, a central ResourceResolver uses services registered by bundles.
Managed beans - I have no idea how to use an expression like #{myBean.property} if myBean is defined in one of the bundles.
Servlet API stuff - use something like WebExtender/Pax Web to register servlets, filters and so on.
My questions are:
Am I inventing a bicycle here? Are there standard solutions for that? I've found a mentioning of Spring Slices but could not find much documentation about it.
Do you think OSGi is the right technology for the described task?
Is my sketch of OSGI application more or less correct?
How should managed beans (especially request/session scope) be handled?
I'd be generally grateful for your comments.

What you're aiming to do sounds doable, with a few caveats:
The View Layer: First, your view layer sounds a little overstuffed. There are other ways to modularize JSF components by using custom components that will avoid the headaches involved with trying to create something as dramatic as late-binding managed beans.
The Modules Themselves: Second, your modules don't seem particularly modular. Your first bullet-list makes it sound as if you're trying to create interoperable web apps, rather than modules per se. My idea of a module is that each component has a well-defined, and more or less discrete, purpose. Like how ex underlies vi. If you're going down the OSGi route, then we should define modular like this: Modular, for the sake of this discussion, means that components are hot-swappable -- that is, they can be added and removed without breaking the app.
Dependencies: I'm a little concerned by your description of the modules as "possibly depending on each other." You probably (I hope) already know this, but your dependencies ought to form a directed acyclic graph. Once you introduce a circular dependency, you're asking for a world of hurt in terms of the app's eventual maintainability. One of the biggest weaknesses of OSGi is that it doesn't prevent circular dependencies, so it's up to you to enforce this. Otherwise your dependencies will grow like kudzu and gradually choke the rest of your system's ecosystem.
Servlets: Fuhgeddaboudit. You can't late-bind servlets into a web app, not until the Servlet 3.0 spec is in production (as Pascal pointed out). To launch a separate utility servlet, you'll need to put it into its own app.
OK, so much for the caveats. Let's think about how this might work:
You've defined your own JSF module to do... what, exactly? Let's give it a defined, fairly trivial purpose: a login screen. So you create your login screen, late-bind it using OSGi into your app and... then what? How does the app know the login functionality is there, if you haven't defined it in your .jspx page? How does the app know to navigate to something it can't know is there?
There are ways to get around this using conditional includes and the like (e.g., <c:if #{loginBean.notEmpty}>), but, like you said, things get a little hairy when your managed loginBean exists in another module that may not have even been introduced to the app yet. In fact, you'll get a servlet exception unless that loginBean exists. So what do you do?
You define an API in one of your modules. All the managed beans that you intend to share between modules must be specified as interfaces in this API layer. And all your modules must have default implementations of any of these interfaces that they intend to use. And this API must be shared between all interoperable modules. Then you can use OSGi and Spring to wire together the specified beans with their implementation.
I need to take a moment to point out that this is not how I would approach this problem. Not at all. Given something like as simple as a login page, or even as complicated as a stock chart, I'd personally prefer to create a custom JSF component. But if the requirement is "I want my managed beans to be modular (i.e., hot-swappable, etc)," this is the only way I know to make it work. And I'm not even entirely sure it will work. This email exchange suggests that it's a problem that JSF developers have only just started to work on.
I normally consider managed beans to be part of the view layer, and as such I use them only for view logic, and delegate everything else to the service layer. Making managed beans late-binding is, to my mind, promoting them out of the view layer and into the business logic. There's a reason why all those tutorials are so focused on services: because most of the time you want to consider what it would take for your app to run "headless," and how easy it would be to "skin" your view if, for instance, you wanted it to run, with all its functionality, on an Android phone.
But it sounds like a lot of what you're working with is itself view logic -- for instance, the need to swap in a different view template. OSGi/Spring should be able to help, but you'll need something in your app to choose between available implementations: pretty much what OSGi's Service Registry was built to do.
That leaves static resources. You can modularize these, but remember, you'll need to define an interface to retrieve these resources, and you'll need to provide a default implementation so your app doesn't choke if they're absent. If i18n is a consideration, this could be a good way to go. If you wanted to be really adventurous, then you could push your static resources into JNDI. That would make them completely hot-swappable, and save you the pain of trying to resolve which implementation to use programmatically, but there are some downsides: any failed lookup will cause your app to throw a NamingException. And it's overkill. JNDI is normally used in web apps for app configuration.
As for your remaining questions:
Am I inventing a bicycle here? Are there standard solutions for that?
You are, a little. I've seen apps that do this kind of thing, but you seem to have stumbled into a fairly unique set of requirements.
Do you think OSGi is the right technology for the described task?
If you need the modules to be hot-swappable, then your choices are OSGi and the lighter-weight ServiceLocator interface.
Is my sketch of OSGI application more or less correct?
I can't really tell without knowing more about where your component boundaries are. At the moment, it sounds like you may be pushing OSGi to do more than it is capable of doing.
But don't take my word for it. I found other reading material in these places.
And since you ask about Spring Slices, this should be enough to get you started. You'll need a Git client, and it looks like you'll be training yourself on the app by looking through the source code. And it's very early prototype code.

I am facing the same problems in my current project. In my opinion, OSGi is the best and cleanest solution in terms of standards and future support, but currently you may hit some problems if you try using it in a web application:
there is no well integrated solution between a Web Container and the OSGi platform yet.
OSGi may be too much for a custom build web application that is just searching for a simple modularized architecture. I would consider OSGi if my project needs to support third party extensions that are not 100% under our control, if the project needs hot redeployments, strict access rules between plugins, etc.
A custom solution based on class loaders and resource filters seems very appropriate for me.
As an example you can study the Hudson source code or Java Plug-in Framework (JPF) Project(http://jpf.sourceforge.net/).
As about extending the web.xml, we may be lucky with the Servlet 3.0 specification(http://today.java.net/pub/a/today/2008/10/14/introduction-to-servlet-3.html#pluggability-and-extensibility).

The "web module deployment descriptor fragment" (aka web-fragment.xml) introduced by the Servlet 3.0 specification would be nice here. The specification defines it as:
A web fragment is a logical
partitioning of the web app in such a
way that the frameworks being used
within the web app can define all the
artifacts without asking devlopers to
edit or add information in the
web.xml.
Java EE 6 is maybe not an option for you right now though. Still, it would to be the standardized solution.

Enterprise OSGi is a fairly new domain so dont think you will get a solution that directly satisfies your need. That said one of the things I found missing from Equinox (osgi engine behind eclipse and hence one with largest user base!) is a consistent configuration / DI service. In my project recently we had some similar needs and ended building a simple configuration osgi service.
One of the problems which will be inherent to modular applications would be around DI, as the module visibility could prevent class access in some cases. We got around this using a registered-buddy policy, which is not too ideal but works.
Other than configuration, you can take a look at the recently released Equinox book for guidance on using OSGi as base for creating modular applications. The examples may be specific to Equinox, but the principles would work with any OSGi framework. Link - http://equinoxosgi.org/

You should look into Spring DM Server (it's being transitioned to Eclipse Virgo but that's not been released yet). There's a lot of good things in the recent OSGi enterprise spec which has also just been released.
Some of the Spring DM tutorials will help, I'd imagine. But yes, it's possible to have both resources and classes loaded from outside the web bundle using standard modularity. In that, it's a good fit.
As for the session context - it gets handled as you would expect in a session. However, you might run into problems with sharing that session between web bundles to the extent that in not sure if it's even possible.
You could also look to have a single web bundle and then use e.g. the Eclipse extension registry to extend the capabilities of you web app.

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.

How to integrate spring with GWT?

If I understand correctly, it's more efficient to use spring as a mediator for object persistence than using ibatis directly.
There seem to be a lot of libraries which ease spring integration by implementing a dispatcher for gwt rpc calls.
Would you recommend gwtrpc-spring or gwt-widgets?

I've used gwt-widgets with both 1.5 and 1.6, and it works. Once you get the initial configuration done, all is fine.
I can't say anything about gwtrpc-spring, but still gwt-widgets seems to be the more mature project, with a larger community.

How does spring framework assist in application development?

Am a bit confused here! how does spring framework assist in general development of an application? I use django framework and i can quickly explain to a layman how all parts fit together(Django, Python, templates, packages etc) to produce an excellent web application, but when i look at spring i get a bit lost! Am looking answers but not limited to the following;
Can someone please tell me how they have used spring to produce applications?
Can someone please point to me some real world applications done in spring ( iread somewhere linkedin.com is done with spring!
Can someone please tell me how this pieces come together ( Strut, javascript, glassfish/jboss, apache, etc and ofcourse spring) to produce an application?
How many separate pieces of software do you need to produce an application using spring?
How easy is it to produce application using spring framework?
I need the gory details :)
Gath

There are a number of Spring projects, but the initial Spring (POJO) project came about because of the perceived difficulties of working with J2EE. You'll find a number of projects on the SpringSource website that have grown out of this, but rather than being lumped into one framework they've taken a more modular approach. For all the products they produce see:
http://www.springsource.org/projects
Q. Can someone please tell me how they have used spring to produce applications?
Spring provides a number of features, but the most oft used one is that of dependency injection. This allows you to wire together components (e.g. Javabeans) by declaring the relationships in XML/Annotations. The Spring container then reads this information and constructs the bean hierarchy at runtime. A standard way to describe the beans in XML is the Application Context.
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html
Q. Can someone please point to me some real world applications done in spring ( iread somewhere linkedin.com is done with spring!
There are lots of applications built using Spring. I'm not sure of big commercial projects, but I expect there to be many.
Q. Can someone please tell me how this pieces come together ( Strut, javascript, glassfish/jboss, apache, etc and of course spring) to produce an application?
Spring is normally integrated with other frameworks, there are various hooks into these frameworks and you need to look at each one separately in order to understand what they are all about. Struts and Spring framework integration can be found here:
http://www.ibm.com/developerworks/web/library/j-sr2.html
With Glasshfish/JBoss it's more about how you configure your application in relation to Spring rather than the application server. See this:
http://static.springframework.org/spring/docs/2.5.x/reference/web-integration.html
Q. How many separate pieces of software do you need to produce an application using spring?
e.g. A web application would consist of Spring MVC + Spring Backend. A desktop application - Java Swing + Spring backend. In terms of the Spring framework itself (configured with XML) it would involve:
Create your standard JavaBean classes (for services/DTO's/DAO's)
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
public ExampleBean(
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
this.beanOne = anotherBean;
this.beanTwo = yetAnotherBean;
this.i = i;
}
}
Declaring beans within your application context file
Integrate Spring with your web application/application via web.xml etc...
These are taken from the Spring docs btw... see:
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html
Q. How easy is it to produce application using spring framework?
Very easy, but again dependent on what you're building. If you're just using the Spring POJO framework to build a service and integration tier then it's fairly simple. If you have to build a web application layer, then it's a little more complicated (not hugely at all) to understand the internals.
Hope that helps...

Can someone please tell me how they have used spring to produce applications?
Put the Spring JARs in your CLASSPATH, follow the Spring idiom (e.g., interfaces to delineate layers), and use it to glue your code together.
Can someone please point to me some real world applications done in spring ( iread somewhere linkedin.com is done with spring!
Here's one. Running in production now for three years and counting.
Can someone please tell me how this pieces come together ( Strut, javascript, glassfish/jboss, apache, etc and ofcourse spring) to produce an application?
Struts is one choice for web tier; JavaScript is something you can use to make your client dynamic; Glassfish/JBOSS/WebLogic/WebSphere/Tomcat/Spring DM are all app server choices for deploying your Spring app; Apache is an HTTP web server; Spring and your code go on the app server.
How many separate pieces of software do you need to produce an application using spring?
You need an app server and probably a database, a browser, your code and Spring.
How easy is it to produce application using spring framework?
How good a programmer are you? Depends on your knowledge.
Spring certainly made my life easier once I understood it.

Spring is a pretty large framework, it's going to be hard for anyone to summarize everything here. I think the biggest plus for using Spring is its dependency-injection support. It can be used in any type of application, and provides a ton of framework features and utilities. If you are really interested, I'd recommend starting with the docs on springsource.org:
http://www.springsource.org/documentation
There are a lot of tutorials out on the web too. To fully appreciate it, you should try writing a few example apps to get the feel for it, and see what's available.

Just to add another dimension - if you are interested in building java web apps, and have no constraints (like legacy code to integrate with/update), then take a look at grails. its the best-est web framework to write web apps in. Of course, it uses spring internally too, but its fairly abstracted away from you. In fact, i'd liken it to django.

You can start with this http://static.springframework.org/docs/Spring-MVC-step-by-step/. This will provide the basic framework for you and then spring is huge so depending upon what you need you can explore spring and use it.
This has worked for me.

If you're talking about Struts and JavaScript at the same time, it means that you don't know what you're talking about, for Web Development in general.
What is what?
- You have frameworks in Java such as Spring, Struts, etc. which help you build Java based Web applications. Those Java Frameworks integrate generally Web with ORM tools, and other technologies.
- You have Servlet Containers such as Tomcat, Jetty, etc on which you can run classic Java Web Applications. J2EE containers such as JBoss, Glassfish embed a servlet Container such as Tomcat and provide a J2EE container and sometimes other tools, to deploy Java Enterprise applications.
Choosing a Framework
Choosing a Framework depends on how you feel about it and how it fits your needs. For example why are you using Django instead of TurboGears? Some people will tell you that Django sucks while TurboGears rocks, etc.
Whatever you do it's your call, read at the documentation and pick one application server and one or many frameworks to build your application.