• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Very Large upgrade from Struts 1.2.7 to anything better (looking for opinions)

 
Zach Lucas
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I am extremely new to struts and I am now aware that Struts has not supported anything below version 2.0 for some time now. I am currently tasked with making large changes to an E-Commerce site which is very outdated.
I am debating on whether or not a version upgrade would be worth it/necessary at this stage.

I would like to ask the opinions of whoever has experience with this older version or experience with making such a large jump in versions. What kind of issues would I expect to run into be doing this? I have never upgraded something so outdated...

I currently do not care what version I upgrade to and am talking any recommendation. Even its its upgrading to a different framework altogether.
 
Tim Holloway
Bartender
Posts: 20980
128
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Zach!

A long time ago, I published an article in Java Pro Magazine called "An Introduction to Struts". And worked with Struts version 1 for several years.

But when JavaServer Faces came out, I switched over. Struts was a good idea for its time, but it had some serious warts, and most of them were addressed by JSF. In fact, several of the designers of the JSF spec had originally designed Struts.

I don't claim that JSF is the best solution to your problem. I've never been clear on how well it handles a large number of concurrent user requests. Struts might actually be better for that, in fact - I just have no benchmarks.

But JSF is very good for fill-in-the-form applications, since it has extensive data validation and error reporting facilities and it interfaces smoothly with Inversion-of-Control mechanisms. And best of all, it doesn't demand exclusive ownership of the app. You can migrate from Struts to JSF a page at a time and if particular pages don't perform well, or require abilities that JSF is ill-suited for, such as downloading PDF and spreadsheets, you simply use whatever mechanism works better for that part of the app.

Of course, I'm biased. After all, I've been the JSF forum moderator here on the Ranch for a long time.

And not everyone would agree with me. For example, I think that the current new-and-shiny fad would be something more like loading lots of functions on the front-end using a framework like REACT and having it do the backend work via ReST calls. That scales well, although I'm not sure I'm comfortable with the potential security risks myself.
 
Joe Ess
Bartender
Posts: 9565
12
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Zach Lucas wrote:
I am debating on whether or not a version upgrade would be worth it/necessary at this stage.  



Struts 1.x has known security vulnerabilities.  I cannot stress this enough: upgrading is imperative.  

Zach Lucas wrote:
I would like to ask the opinions of whoever has experience with this older version or experience with making such a large jump in versions. What kind of issues would I expect to run into be doing this? I have never upgraded something so outdated...



We made the switch from Struts 1.x to 2.x in 2013.  The difference between the two are substantial, so it is worthwhile looking at other options, since you'll be doing a lot of work in any case. The good news is that Struts 2 is easier to work with and requires a lot less "coding for the framework" compared to 1.x.  That means less boilerplate code and your applicatino will be easier to maintain going forward.  The bad news is that Struts is still a pretty "primitive" framework compared to more modern options.

Zach Lucas wrote:
I currently do not care what version I upgrade to and am talking any recommendation. Even its its upgrading to a different framework altogether.



Struts 2 would probably be easiest if you know Struts 1 well.  I've never used JSF, but it is very popular.  My team is currently looking at Spring MVC for our new development.  It seems easy to use, but I've run into some issues with Spring in general that make me hesitant to recommend it.  Spring is a collection of around 20 different projects, and getting the dependencies correct when using several (MVC, Data, Security, etc) is a challenge.  Spring Boot is an attempt to resolve that issue by providing a single configuration that "just works".  Of course, if something doesn't "just work", figuring out where in the implicit configuration the issue lurks is not trivial.  
There are a bunch of Java web frameworks, many with unique features that may make them more suitable for your purposes.  My advice would be to see if you have a requirement that is a good match for a particular framework.  If not, look at the most popular frameworks (Spring MVC, JSF), with the thinking that they will be the best supported.  Make a judgement if the level of effort to adapt your current code is worth moving to a new framework. If that isn't true, I'd choose Struts 2.



 
Tim Holloway
Bartender
Posts: 20980
128
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Spring MVC is very popular, although I haven't used it to any significant degree. My impression has been that JSF is much more capable as far as automating the validation of form field values goes. Plus JSF has both core and available extension taglibs that provide very powerful controls, whereas to the best of my knowledge, you have to provide your own front-end controls (possibly REACT or jQuery) for Spring MVC. Incidentally, several of the JSF extension tagsets leverage off jQuery themselves.

Both JSF and Spring MVC work on POJOs. That was one of the main complaints about Struts, in fact - that Struts required user-written components to extend Struts-specific base classes and/or extend Struts-specific interfaces. That makes code re-use harder and may interfere with unit testing. POJOs are easily testable with jUnit and can be recycled in just about any project that works with POJOs. I've had occasion to create off-line support utilities that exploited that capability.
 
Joe Ess
Bartender
Posts: 9565
12
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Spring MVC is very popular, although I haven't used it to any significant degree. My impression has been that JSF is much more capable as far as automating the validation of form field values goes.



Spring leverages the javax.validation library.   I don't know how that compares with JSF's abilities.

Tim Holloway wrote:
Plus JSF has both core and available extension taglibs that provide very powerful controls, whereas to the best of my knowledge, you have to provide your own front-end controls (possibly REACT or jQuery) for Spring MVC. Incidentally, several of the JSF extension tagsets leverage off jQuery themselves.



Spring MVC is view-agnostic, so one can use JSP's, Thymeleaf, Groovy, FreeMarker, Jade, whatever.  I've seen examples using JQuery, but I haven't tried it myself in Spring MVC (we use it extensively with Struts 2).  How about using Spring with JSF?  Madness I say!

Tim Holloway wrote:
That was one of the main complaints about Struts, in fact - that Struts required user-written components to extend Struts-specific base classes and/or extend Struts-specific interfaces.



That was the certainly the case in Struts 1.   Struts 2 permits the use of POJO's for the objects between the framework and the domain classes, however, in practice it is more common to extend a class called ActionSupport to get some helpful defaults.  It's never been an issue for my team, but your mileage may vary.
 
Tim Holloway
Bartender
Posts: 20980
128
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF has built-in GUI validation. In addition, it will honor javax.validation for items where the Controllers touch them. For example, if a JSF backing bean (GUI Model) contains a JPA Entity object (persistence Model), properties on the Entity that are tagged with validators can also be checked.

I have been using JSF with Spring for many years. Primarily Spring Data (both JPA and Neo4J), but also other services, such as scheduling, email, etc. As I said, the JSF integrates its own bean management seamlessly with Spring. To the point that you can code EL expressions that reference JSF backing beans containing Spring objects. A common example being when you want to fetch a JPA Entity object (or graph of objects) and reference properties of those objects in the View Template.

Unlike Spring MVC, JSF has its own native View Definition Language (also known as View Template Language). VDL is in the form of xhtml files, done up in the usual HTML style, but with the addition of tagsets from the core and extension JSF namespaces. For example, <h:html>. Actually, the original design was Write Once/Display Anywhere, so that essentially the same VDL would be able to serve for not only HTML clients, but non-HTML ones as well. When JSF was in its infancy, for example, many mobile devices didn't have the power to support full HTML (much less javascript), so you could employ an alternate plug-in view renderer for other display clients, such as the now-obsolete WML.

In JSF you code the View (template) and Model objects, but not the Controllers. The master Controller for JSF is the FacesServlet. The sub-controllers are integral to their tag libraries. JSF is true MVC. When you display/refresh a View, the JSF controllers automatically populate it with the latest data from the Model. When you submit a form from a view, JSF first validates all the submitted control values and then if and only if all values are valid, then the JSF Controllers will update their corresponding backing bean properties. So you're guaranteed that before a submit / AJAX action can be fired that the backing bean contains valid data from the View.

You can write custom validators and converters for JSF control values as well as listeners that fire when a control's value is being changed in the backing bean.

And, I suppose I should mention for completeness sake, that JSF is a part of the JEE standard and thus actually required to be a built-in component of any full-stack JEE server. Struts has never held that distinction. Spring, of course, defines its own standard. JSF is not, however, part of Tomcat or jetty, as they don't implement the J2EE or JEE full stacks. Not only JSF, but things like EJB as well. Although with the proper libraries, that's no problem. I've done most of my JSF in Tomcat, actually.
 
Zach Lucas
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you both of you for you suggestions. I will look into those options as upgrading is going to be a long term goal. Tim, since i am currently forced to work with it and you use to work with older versions of struts, do you know of any old tutorials laying around? Or perhaps a software I can use to de-compile the current site so I can work on it? Currently the most I can do it over to view the java class and make changes with javascript. But I cant covert them back into Class files to make any meaningful changes. Nor can I see how each class relates to one another by doing it this way.
 
Joe Ess
Bartender
Posts: 9565
12
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You don't have the source code?!?!  I feel bad for you!
You can get to the official Struts documentation by downloading the distribution here.  Unzip it and look under the "docs" directory.  Double-click on index.html and there's the website as it was in 2008.  Click on the "User Guide" to get started.  It's not hard to understand.  Basically there is an XML file that maps URL's to classes called Actions.  It's a design pattern called a Front Controller.
As for decompliing, if you use Eclipse, look at this.  If you don't have Eclipse, this looks promising.
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Zach Lucas wrote:Currently the most I can do it over to view the java class and make changes with javascript. But I cant covert them back into Class files to make any meaningful changes. Nor can I see how each class relates to one another by doing it this way.


When you say "view the java class" what do you mean? Are you opening up a .class file or a .java file? The former are binary files so I don't see that as being very useful. On the other hand, .java files are human readable text files.

You also say "I can't convert them back to Class files" -- what exactly do you mean by that? "Converting" a source file (.java) to a .class file is called compiling. So are you saying you actually have source (.java) files and you want to compile them but are having problems doing so? If so, what kind of problems are you having specifically?
 
Zach Lucas
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We have found a program that can convert the .Class binary file into a java file so we can read it but we have no way of converting it back to be used.

Also we are having a hard time finding how each file interacts with each other.
Example. One files calls the cartRemoveItem.do action but there is no file or method by this name. There are similar ones, such as removeCartItemAction.class but we are not fully sure if this is the controller we are looking for.

Also Thank you Joe Ess. That is very helpful!
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Any .do action is mapped to a controller class and a handler method. You should try to find a file that's named struts-config.xml or similar. That will show you what classes your .do actions are mapped to. These config files are usually found in a /webapp/WEB-INF directory.

Why do you not have the source code for all this???

If you don't have the source code, then I think a rewrite using a more modern framework is an option that you should seriously consider. And lots of characterization testing.
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's some decent documentation:

https://www.mkyong.com/tutorials/struts-tutorials/
https://www.mkyong.com/struts/struts-multiple-configuration-files-example/

A path like cartRemoveItem.do will not have a physical file associated with it with that name. Rather, if you find the struts-config.xml file, you might find something like this:

Line 6 is what the "/cartRemoveItem.do" action maps to. The web.xml file will specify a <servlet-mapping> with a <url-pattern> element that tacks on the ".do" part onto the path value.
 
Matthew Keller
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Going from Struts 1.x to Spring MVC would be the least labor intensive.  The reason being that you are sticking to a newer version of the same paradigm, which is server side rendered html.  You can take the contents of your action classes and simply copy them to controller methods, and you can also bring over your formbeans fairly easily and keep your jsp's intact.  If you used jstl tags in your struts app you might not have to change your jsp's hardly at all.  If you used struts tags then those will have to be refactored.

If you try to make a more radical change like going to a json based fat client like Angular then you would have to chop up all your jsp's and action classes.  Basically a complete rewrite.

My recommendation is that you go to a Spring MVC but change to a SPA (Single Page Application), instead of a full page refresh. This would mean pulling all your header and footer includes out of your jsp's, but still keeping them otherwise intact, and injecting HTML into the main body to navigate/refresh.  This will allow you to throw away all of the complicated back button mappings you need when you do a full page refresh classic MVC paradigm.

Now, this is where I have to write a disclaimer because I work on the WebRocketX team, and it is a framework that completely facilitates a transition from server side MVC with full page refresh to SPA.  It is a javascript framework that standardizes all your innerhtml injection and browser navigation, so that you don't have to write any of that yourself.  So it makes it easy to turn your old struts app or new Spring MVC app, or any other flavor of server side MVC, into a SPA.  So, obviously I am biased.

Regardless of whether you use our stuff, definitely Spring MVC is the best match for a Struts upgrade if you want to minimize your refactoring.

We are actually doing exactly the same thing with a huge old Struts 1.2 app at work right now.  We are moving it to Spring MVC.  This might not sound old school but I actually like Struts.  If your developers didn't make a mess out of it by forwarding action to action, it was really a straight forward and clean way write an MVC.  I'm curious about what all these security flaws I keep hearing about are because everywhere I worked we overroad the requestProcessor anyways, so how hard would it be to fix any known vulnerabilities?  

I don't have good experiences with JSF, but it might be just because I'm not that good at it.  I find it overcomplicated and difficult to debug when things go wrong.  For one thing, they obviscate the javascript onclick calls with hashes so you can't inspect the onclicks in the DOM to see what it is calling.  Also, in JSF the URL is always one page behind where you actually are.  It has a very complicated lifecycle too.  The surprising thing is that one of the main architects of Struts is responsible for JSF.  Did you know that JSF was supposed to be a drag and drop kind of web development environment? But it never really worked out so you end up working on it in text editor.  Anyways, just my opinions though.

I hope this helps.

 
Tim Holloway
Bartender
Posts: 20980
128
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Matthew Keller wrote:  For one thing, they obviscate the javascript onclick calls with hashes so you can't inspect the onclicks in the DOM to see what it is calling.



(obfuscate) Technically, not so. The reason that the generated HTML ids have those hashes and stuff in them is that one JSF element can render as multiple underlying HTML elements. This is especially noteable if you put an ID on a control in a dataTable, where you have multiple rows. Since XML/HTML requires that each and every element's id attribute to have a 100% unique ID, JSF concatenates the container tag IDs and - where applicable - adds a sequence ID (e.g., row number), generating a guaranteed unique ID so that the client's HTML renderer won't get annoyed. And also so Javascript references by ID will be portable and unambiguous.

It is for that reason that I recommend that ALL controls and container elements (such as h:form, h:dataTable, and so forth) be supplied with explicit "id=" attributes. If you don't, then JSF has to synthesize the missing IDs and you don't want that. For one, thing, I don't think there's even a standard for it, although the implementations I've worked with use j_nnn format. For another, what the value of "nnn" will be is not easily computable. And finally, not only is it difficult to compute, it can change without warning. So explicit IDs, and if you're ever confused what the generated ID is, there's always "View Page Source".

Matthew Keller wrote:
Also, in JSF the URL is always one page behind where you actually are.



It's more complicated than that. The URL for a JSF View is actually more of a "handle" than it is an absolute resource locator, so while the general effect is that it lags the view ID on postbacks, it can conceivably do even worse things.

Most of the time, this doesn't matter, since it's really not a good thing when drooling users go in and mess with ongoing URLs in a webapp directly. And what of the case of an SPA where the same basic View is the frame for every page?

But there are times when a "handle" isn't good enough. Obviously you want something better if you need a bookmarkable page URL. And if you are using JEE standard security, the security rules are applied based on the submitted URL, not on the View ID. For such cases, you can navigate using the the "redirect" navigation option and the URL presented will not lag.

Actually, there are 2 major problems I see over and over when people try to use JSF. And of those 2, the worst is that they try do make lots of JSF API calls. JSF is an external framework. It operates primarily via declarations not explicit JSF logic. Or, more briefly, any time you code something that uses a "javax.faces" resource and that resource isn't a data model class/interface (such as SelectItem or DataModel), then there's a very big chance you're doing things wrong. As I said, in JSF, Controllers, Validators, and Converters are mostly pre-supplied and automatically wired in.
 
Matthew Keller
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good information Tim. Thanks.
 
Are you okay? You look a little big. Maybe this tiny ad will help:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!