Spring MVC (xml config nightmare?) vs spring roo? - spring-mvc

I am just delving into the spring mvc (or spring roo), from what i have read it appears that spring MVC can be a nightmare to configure. I have to configure XML files, is this the web.xml file??? Or something different?
Is it still a nightmare or has it been improved?
Is there no editor for these XML files? I am using eclipse IDE
Spring roo apparently does spring mvc without XML config worries.
I would love anyone to explain the differences..
Thanks in advance

First Spring MVC is not a nightmare to configure, you just have to know what you are doing.
For that I would suggest you to download Spring IDE, which have a lot of XML editors that make you life easier if you are not experienced with Spring XMLs.
Basicly you have to configure 2 things
Web.xml ( this one is not because of spring it's Java EE, but you
need to include some spring MVC configs in it )
applicationContext.xml( this is where you define what you want from Spring )
servlet-context.xml ( this is also from spring MVC and have some servlet definitions as well as some routing ones)
one you get to know them you will find it easy to configure and very flexible.
One thing to notice Spring and Spring MVC are different things, I advise you to learn both of them.
Also Spring Roo is a code generator, for Cruds, simple things and setup projects it's great but if you need to build a reasonable big app that will need support it's always easier to create everything youself because it's easier to support when you know the code, so use it with care.

I'd add that Spring XML configuration can be as simple as a few lines, with the bulk of work done via annotations. It may not always be preferable to do it that way, but it's an option. Configuration can be divided between mechanisms when it makes sense to do so.
You might want to spend some time with the Spring documentation, at least regarding the components you're using. If you think configuring it is a nightmare, wait until you have to diagnose a problem brought about by magic based on convention without understanding how the underlying framework(s) work.

Related

Modernizing Struts 1.x Application

I would like to modernize my Struts 1.x application. There are quite a number of articles which advocate migration of codes, instead of rewriting the entire system.
I would like to seek the advice of someone who has successfully modernize legacy applications.
My current system is using struts 1.x and JDBC prepared statements as the data access layer.
I am looking forward to improve the legacy application with the following objectives:
Web Pages should be coded with Responsive Web Design in mind.
Replace struts 1.x with Spring MVC
I am looking to breaking up the modernization into the following phases:
Phase 1 - Change all jsp pages to HTML 5 and CSS 3
Phase 2 - Change all DAO classes to Spring JDBC Template or Spring JPA
and transactions managed by Spring
Phase 3 - Ultimately, replace Struts 1.x Action Forms, Actions with Spring MVC
Before I start the changes, I would like to find out if it is possible for:
Struts 1.x with HTML 5 and CSS 3? I am looking at replacing all struts 1.x html taglibs with HTML 5 and JSTL/EL.
Running Struts 1.x with Spring 3/4? Is it possible to run non-spring managed pojo with Spring beans?
What should I take note of and how/what are the best practices to handle this modernization process? The code base is about 500k of HTML/JSP codes and 3 million Java codes.
It's been a while since I last worked with Struts 1.x, but I see no problem replacing at least most of the Struts tags with JSTL/EL. You should be able to paint HTML5 with Struts 1.x JSPs. I remember working using little or no Struts tags, only JSTL/EL, but this was before HTML5.
You can invoke Spring Context from any Struts ActionForm or, essentially any class within your webapp. You'll probably have to do it manually though and not with annotations, something like this:
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
With all this said, I can see you're intending to do a serious update of your app, therefore I must ask, are you positive about keeping Struts 1.x? If you want to ditch Struts tags, use Spring 3/4 and HTML 5, why not dispense with Struts entirely and migrate your app to Spring MVC? It's very easy to use, powerful and, needless to say, it integrates perfectly with the Spring components implementing your business logic, persistence, etc.
Cheers.
(Not an answer, informational.)
There's no reason you can't have an S1 app running alongside Spring MVC. It's a reasonable way to migrate piece-by-piece instead of a longer project that does a complete replacement.
Older Spring has direct support for Struts 1. Depending on your timeframe I might consider using the older Spring until you're further along.
Replacing S1 tags with pure HTML/CSS will be a pain because the S1 tags render other stuff besides just the input fields (e.g., labels, error messages, etc.) It's totally doable, especially if you write your own custom tags.
jQuery v. (AngularJS | React | similar) Switching to a full-on client-side app is a big lift, especially if your back-end isn't already designed that way. I wouldn't do that, but you could get a start on it by putting business logic in its own place and using that from the web layer. Then...
... you start to consume API calls on the client side using jQ or other client-side framework injected into the existing pages. Only then would I start considering going full SPA.
The bottom line is you have a fairly large app. Rather than converting the entire thing I would consider removing functionality from the mainline app and break it up into sub-applications, each of which could use whatever tech stack seems reasonable.
I've done a lot of project like this as a consultant: it's a lot of busywork that requires a wide range of knowledge and skills, and it's difficult to get right.

spring roo frontend twitter-bootstrap integration

I want to develop a pretty standard webproject with all basic functionalities such as landingpage, user registration, login and so on.
Since I'm familiar with Java and Spring, I set up the a project with Spring Roo including DBRE from an MySql database, MVC and Spring security.
Right now I'm wondering how to go on with the UI. I would like integrate a template from twitter-bootstrap and I already downloaded a working example project (no apache tiles structure). I'm not very familiar with Apache tiles and frontend design in general so my question is, what would be the best way to integrate it and bypass the standard CRUD design?
Is it only necessary to design a new default-layout and reuse existing .jspx files? Also is it possible to take the existing bootstrap.jsp template which uses sitemesh from the bootstrap-example as a new template and reuse existing .jspx files?
Reuse is important since there are still entities which will change in future.
Appreciate any help!
I haven't personally used twitter-bootstrap, but I am fairly familiar with the Spring Roo structure.
My first bit of advice would be to just simply not use their UI stuff. Nothing says you have to generated your Controllers with scafolding, which takes the scafolded classes and auto-generates the CRUD methods and UI peices for you. In fact, in my last 4 projects, I did all the UI coding myself (I still used Tiles w/JSPs, and let Roo make all the relavent tiles configs and resource bundles). You can ALWAYS generate a plan Controller and use Roo for everything except the View pieces.
I don't see why you couldn't use the bootstrap.jsp you speak of. The Tiles implementation is done using the TilesViewResolver, I believe, which should be configured in the application_context.xml (or whatever Roo calls the context XML file). Just replace the TileViewResolver setup with something else. I would suggest reading up on Chapter 17.5 Resolving Views in the Spring Reference guide. I think for JSPs you want to use InternalResourceViewResolver.

Are interceptors in Struts 2 the same as interceptors in Java Spring 3?

I am new to Web Development. I am learning Java Spring. I found a good online tutorial for interceptors in Struts 2. My question is, are interceptors in Struts 2 the same as interceptors in Java Spring? If not, what are the differences? If they are different, what are the advantages/disadvantages of using one over the other?
I would suggest that this is not a differentiator in choosing between Spring MVC ( if that's what you mean by Java Spring ) and Struts2. The interceptors in both frameworks play the same architecural role by isolating cross cutting concerns from your core business logic classes.
At least in Struts 2, it's fairly uncommon to code against the interceptor api; <5% of your total development time. This would suggest that you would only really care about the differences in the interceptor api's if you had some particular use case that you felt would be solved by interceptors, and then this use case could help you evaluate the two api's.
If you don't have such a use case, which seems likely if you are new to web app development, I recommend not putting to much into this topic; either framework will most likely server you well. Though there could be other valid reasons for choosing one or the other.

spring surf vs classic spring mvc in Alfresco

We are interested in deploy functionality inside Alfresco.
I have noticed that the newest versions of Alfresco Share are based on Spring Surf.
So we have ruled out WebScripts as an option. Are them old fashioned?
Before start with Spring Surf and in order to be practical: what about extend Alfresco with our own controllers and JSP views?
I’m not familiar with WebScripts or Spring Surf. It could be so interesting to debate the advantages/disadvantages of using these technologies.
I’ll start with some points related to our team which is used to Java programming.
CLASSIC SPRING MVC / JSP VIEW
Advantages
- We are familiar with these techlonogies
- Template hot deployment is possible with JSP. Ok. It’s true that JSP aren’t templates, but they will be our view.
SPRING SURF
Advantages
- Lack of the necessity to know Java programming. Ok but we can program in Java
Disadvantages
- We have to learn a new technology.
- Springsource has it in incubation status. Perhaps we’re going to learn a new technology that won’t achieve success.
- Is there any project adopting this technology apart from Alfresco?
Thanks in advance. Best regards
ATV
Tackling one of the sub-questions: Alfresco WebScripts are built on top of Spring Surf! A Webscript is an implementation of org.springframework.extensions.webscripts.WebScript
With WebScripts, you also have the choice of writing your controller in either Java or JavaScript, which I don't believe SpringMVC offers.
Hopefully someone else can advise you on the rest.
A big disadvantege of SpringSurf is that you need a webscript, usually with a javascript acting as a controller and the javascript API is much less powerfull than Foundation Services API. Of course, you can write a Java backed webscript to gain access to the foundation API, but this is extra work.
An advantage of SpringSurf is that the look & feel usually appeals more to end users due to the old fashioned look of JSF based UI's comparing to the javascript libraries like http://script.aculo.us/ .

compare spring mvc 3 and struts 2

Just about to start a java EE project.(Biz requirement is under change still.)
For the web tier, we looked at various java web frameworks and eliminated component-based ones such as JSF, Wicket. Now it comes to spring mvc 3 or struts 2.
Googled it and found little useful info. Can anyone talk about their pros and cons? Thanks.
I took over a Struts 2 + Guice web app that used the REST plugin to do convention over configuration. It was very easy to work on at first but I ran into a couple of hurdles that were either difficult or impossible to overcome.
One of these was that I needed to have internal dot/period characters in the path of the URI and Struts 2 + REST did not allow this, as it would interpret the dot to indicate a file extension and try to marshall to the appropriate view (e.g. like catching .xml and .json).
So I ended up rewriting the webapp in Spring 3 and was able to fix all those issues I couldn't handle in Struts 2. I've been much happier with Spring 3 and found it just as fast to code in as Struts 2. I've stuck with annotation based configuration as much as possible and tried to use the JSR versions where ever possible (330 #Inject and 303 #Valid, etc), so that if I decide to get rid of Spring I am not stuck with custom Spring annotations.
My vote is Spring 3.
In this other stackoverflow question you have a lot of answers comparing struts and Spring. Though many of them don't mention explicitly the version 3 of Spring the comparison would be similar to the version 2.5.
As many of them say, I'd prefer Spring. It makes things easier when you use annotations. One fact I don't like in Struts 2 in comparison with Spring-mvc is that you have to add getters and setters for every property you want to get in the actions. I think Spring is cleaner in this way.
#Javi
You have various options in Struts2 to avoid these getter and setter one of them id ModelDriven interceptor
Well my vote is for Struts2 since i am working on it from so long but this does not mean Spring MVC is bad i have worked on it also and its equally good..
Choice is all yours and it depends what word you like most Spring or Struts

Resources