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.
Related
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.
I have an application currently running based on servlets (app server glassfish). External applications make an HTTP call to that servlet and get response once successfully achieved what its designed for.
I need now to shift the whole application to JSF2.0 as it needs a front end and sticking to servlet/jsp is not an option.
My questions are:
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
The way how you described the old application sounds much like a web service.
JSF is a component based MVC framework, not a web service framework. So JSF is basically the wrong tool for the job. If you want to continue with the standard Java EE stack, look at JAX-WS (SOAP) or JAX-RS (RESTful) instead. The latter is "the" standard web service framework these days.
See also:
Servlet vs RESTful
What's the recommended way to achieve the scenario of external applications getting things done through http calls in my JSF2.0 web app (that is currently I am achieving with servlets)
Like BalusC said, JSF is not exactly what you need and is not designed for what you intend to use it for, webservices are. That being said, you could achieve your goals using JSF if developing an effective web service is not in the cards for you ,either because of a lack of technical expertise on your team or the time factor or other technical constraints require you to serve your customers via a webapp (I honestly can't think of any but hey, you never know)
That being said, I'm assuming you already know your way around JSF2: take a look at this answer to a question somewhat similar to yours. Ultimately, since you're in the Java EE 5-6 stack, I'd strongly suggest you begin work on developing webservices (for basic requirements,they're fairly straightforward to develop). You can download a tutorial here or use oracle's tutorial
I need to maintain some counters in Application scope; Would you advise me to keep using servlets in my jsf app too and are the application scoped beans callable in servlets?
Unless you give us your specific use case, there are very few and far between reasons maintain a servlet within a JSF app. Yes, application,session and request scoped beans are accessible from within a servlet. They're simply stored as objects within the scopes they're named for, application scoped beans within the applicationScope, session scoped beans within the session and request scoped beans within the request.
You may use your JSF webapp to serve low level http requests, but it's a square peg in a round hole chief.
We are in the phase of evaluating some of the frameworks for portlet development. As of now I know of below 3 options. I would like to know your experiences with them and others
Struts 2
Spring Portlet MVC
Liferay 6.x MVC Framework
Please try to share Pros/Cons in following areas along with what you think is important
Speed of development
Maintenance
Ease of development with Geo Distributed teams
Please suggest any other frameworks which can be used as alternative with some pros/cons
From my point of view, using MVCPortlet and JSPs without Spring-mvc or Struts is suitable enough only for a simple portlet. I would definitely try at least a sample portlet to see how it works if developers haven't done portlets.
The only advantage of using Struts is that the Portal itself is heavily using it because spring-portlet-mvc is relatively new. So that you can learn a lot from variety of examples. Otherwise the technology afaik is dying (regarding portlet development) and if you haven't been working with Struts, the better option for you would be go for spring-portlet. I've been using spring-portlet for more than a year, and I must say that I was amazed how well integrated it is into portlet container and what features are implemented there. You can do practically everything as with spring-mvc (servlet spec), except for some minor support that I found redundant anyway.
Speed of development
an experience developer that knows spring-mvc can create a robust application with only a few spring controllers.
Maintenance
The amount of source code is significantly lesser with spring then struts. Spring-portlet has implemented 268 JSR, so that it saves couple of workarounds.
Ease of development with Geo Distributed teams
I sense you are going for something bigger, so that ask developers about their experience with Spring and Struts and make your choice. Anyway, Liferay is a pretty robust portal solution and to "learn" it and find a way to use it properly is more important issue than how to develop portlets.
Also be interested in developers knowledge of Javascript. If they don't know JS much or you don't have front-end developers, I would probably give a shot to Vaadin or GWT portlets. However Liferay has a very good client-side support and you'll see that a lot of things can be done on client-side in Liferay. JSP tag libraries provides a significant amount of dynamic behavior and Alloy JS framework that is built on top of YUI provides you with a nice environment and it is not hard to use.
EDIT: The comparison of Struts vs. Spring is regarding portlet specification, where (my opinion) struts support is an old Volkswagen and spring is Bentley continental gt :-)
ALSO: The key tool for Liferay portlet development is so called ServiceBuilder, which is a code generator, that generates a significant part of your persistence layer, remote service layer based on domain model and metadata. If you choose to use it, your portlet is automatically Spring based. And I'd recommend to use it, because once you try it, you won't let it go. For instance, to create Ajax calls from client-side to remote services is a question of 2 minutes to set it up and be able to call them and even get the return value. Hibernate setup is fully optimized and ready to use after you run servicebuilder. And much, much more.
It's Really depend on your requirements, since liferay MVCPortlet are just simple sub-classes of the javax.portlet.GenericPortlet, i dont think it's a fair comparison between web framework such as Strut 2 or Spring MVC.
I suggest using Spring MVC or Struts 2 for 168 & 268 JSR portlet if you want cross portlet-container portability or if you have more complex presentation requirements, you should find a list of the pro and cons of the two framework everywhere .
If you requirement are very simple then go with liferay MVCPortlet or even the JSPPortlet.
I have used 2) and 3) but not 1) - I'm not a fan of Struts.
Spring MVC gives you the power of Spring and plugs seamlessly into a Spring back-end as well as allowing the ability to wire to the Liferay Spring services. Provided you use MVC correctly and separate Controller concerns into separate Action classes then this is an extremely scalable and flexible choice and works well when coupled with Liferay.
Liferay's MVCPortlet provides much less in terms of flexibility but when used properly it is still highly scalable and a very useful choice. It also ties in to the Liferay IDE/Liferay Development Studio which provides benefits during development. If you have access to the Liferay Developer training then there is extensive coverage on Day 2.
Overall Spring has the greater benefits but also comes with the larger learning curve and greater risk of doing things incorrectly and hits you harder when done badly. Liferay's MVCPortlets done badly end up looking like vanilla portlets and as such is the lesser evil. Personally I use MVCPortlets for small tasks and Spring MVC for the larger ones.
In both cases 'doing it well' involves correct use of the framwork and annotations.
Liferay also supports Vaardin and have released the new Mail Portlet using it. I haven't used Vaardin but certainly plan on it and have heard good things so far.
From the ease-of-development point, I think the Vaadin is one of the best. The new Liferay IDE 1.2 already includes the Vaadin support making it very easy to start with it.
The same goes for application maintenance and APIs. With Vaadin the application code is simply Java code and that makes it easy to divide the work, and maintain the existing code (OOP benefits).
Already a good number of "add-ons" for Vaadin that demonstrate how the Java code can be "componentized" and development split across the organization(s).
Only downside comes from the fact that the Vaadin libraries are shared with all the Vaadin- portlets in a portal, which means they should use the same Vaadin version to keep the deployment easier.
Anyway, I'd say quite good match for your needs.
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
What are some of the advantages in adding Spring into a Flex / AIR application? And When would you recommend using Spring?
If you're writing a Flex app with a Java backend, you'll want to use BlazeDS to handle remoting and/or messaging between the client and server. Spring has support for integrating with BlazeDS and making Blaze a little easier to setup and configure. It's also pretty easy to set up BlazeDS on its own, so if you don't want to learn Spring then you should not be afraid to use BlazeDS by itself.
The bulk of what Spring provides is specific to the Java layer but it will help you write better Java applications. In particular it provides a clean way for wiring up application components, simplifies data access using Hibernate and/or JDBC, makes it easy to do aspect-oriented programming and also has a pretty nice security framework (Spring Security). There's a ton that Spring can do and I recommend using Spring for pretty much any Java backend.
Flex is addressing what happens in the UI. You are likely to need some server-side logic to provide the data for the UI. Writing robust, performant, secure server-side logic from scratch is not trivial. Frameworks such as Spring, EJB 3, etc. really do help with that. The learning curve for modern frameworks is not too steep, getting started is barely more that a few extra "annotations" to the code you knew you wanted to write.
Well worth investigating.
The sum total of learning Flex + Spring + also some DB admin is still quite a lot. You may need to keep your ambitions under control, don't try to fly before you are walking comfortably.
Good luck.