Matthew Keller

I like Eclipse.  I didn't like Netbeans when I tried it many years ago.  Is it still around? Intellij seems to be popular but not free I believe.

Good information Tim. Thanks.

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.

You can do xml mappings in Spring MVC like was done in Struts.  However, its better to use their annotation based URL to controller method mapping.  Here is an example code snippet.

@Controller public class Demo { @RequestMapping("/welcome") public ModelAndView welcome() {    return new ModelAndView("demo/welcome"); } @RequestMapping("/test1")        public ModelAndView test1() {        return new ModelAndView("demo/test1_go");    } @RequestMapping("/slowtest1")        public ModelAndView slowtest1() throws InterruptedException { Thread.sleep(10000);        return new ModelAndView("demo/test1_go");    }

jsp's and actually JEE architecture have a handfull of scopes that you can send attributes to

page scope - lives as long as the jsp is being rendered
request scope - lives as long as the request
session scope - lives as long as the user's session is active
application scope - global area that all sessions can access

The usual jsp pattern is to put a formbean into your session scope and write to it from your java.  In struts you would write the java in your action class.  In Spring MVC you would write this in your controller method.  Both of these places are really just framework flavors of controller servletts.

The next step in the pattern is to send the thread onto a jsp (also a servlett) using a mapping.  The jsp can access the formbean and display your data using a jstl tag.  I love jstl because it is so damn simple.
Look for tags like c:out, c:foreach, c:if to do things in your jsp with jstl.  Here is a reference.  Jstl also has a $ shorthand, but you have to be careful not to confuse that with jquery's $ shorthand

https://www.javatpoint.com/jstl

Great points Cornelia.

Matthew Keller wrote:The employees that maintain hardware will go work for the Cloud company now.  I'd assume the number of machines to maintain will either stay the same or grow world wide.  The systems admins will just administer the machines through the Cloud companies interface now and still work for the same company.  The application developers will also still work for the same company.  So, it seems that the only people that necessarily have to change their place of employment are the hardware experts.  I'd assume there are economies of scale at these larger data centers so there will probably be a need for fewer hardware people but I think they will get paid more.

To add a little more detail to my previous post.  I work for a large hotel company and I'd say we are half way into the cloud at the moment, so I'm not just imagining what happens, I'm describing exactly what I see.  Our system admins are very busy because they are still doing all the same things they did with our in house data center.  For example, instead of configuring firewalls and opening ports on an F5, they are doing the same thing on AWS Route 53 and setting up things like Bastions (jump boxes), security groups, etc.  You still have to configure all your own custom security and servers, you just do it the Amazon way.  In fact we even have to SSH into the Amazon EC2's and configure software.  You can start out with a nice cloud native image but you still have to set up your own software.  Of course you can make AMI's and only do it "once" and build your Elastic Group from there, but there is still plenty of work to do.  The really exciting thing is that now there is even more to "play with" like leveraging Cloud Front to cache your content all over the world.  I think a system administrators job has gotten more interesting with all this technology rather than being lost.

We still develop lots of code in house.  SAAS works great for HR systems like Workday but every business I have ever worked for has plenty of custom stuff they always need written.  The devops code needs to be continally maintained, and updated as well.  I wish every automated deployment only involved copying a war file to a server but a lot of our systems are more complicated than that.  We could probably keep a person busy full time writing nothing but Chef and Ansible.  Also, QA people can no longer just be manual testers.  They have to be developers in their own right because we have them write Selenium scripts in java.  I see application development continually growing.  In fact, we are having a lot of trouble finding java developers at the moment.  I'm becoming burned out on interviews because the recruiters can't seem to send us anyone qualified lately.  Demand is way ahead of supply.

No doubt that the hardware guys that maintain the racks, the power backup system, the fire supression system, all the stuff in the data room will need to change jobs when this switch over is complete.  Even if economies of scale mean that Amazon will only need half of those employees per customer, I still think the growth of the cloud industry will out race the supply of hardware guys.  The better the cloud gets, the more people will find uses for it, and the more servers will be needed.  That is why I don't think the hardware people will be losing their jobs either.  They will just become more centralized.  Probably a lot more will be living out in the country near the large data centers, and enjoying cheaper housing.

The employees that maintain hardware will go work for the Cloud company now.  I'd assume the number of machines to maintain will either stay the same or grow world wide.  The systems admins will just administer the machines through the Cloud companies interface now and still work for the same company.  The application developers will also still work for the same company.  So, it seems that the only people that necessarily have to change their place of employment are the hardware experts.  I'd assume there are economies of scale at these larger data centers so there will probably be a need for fewer hardware people but I think they will get paid more.

assuming you already have a handle to the child object

/parent::WebResource_activities

I am having trouble telling if you are receiving this json on the server or in the browser.  In the browser you can use eval() to turn the json into an object, then access it by using dot and array notation.

By the way.  Going to Spring Boot or containers, or the cloud in general is a totally different topic.  My answer to that is "yes do it".

Your welcome Pankaj.  Both json and jsp have to be rendered server side.  For example:

json

{"person": {"firstName": "John"}}

html/jsp

<div class="inputRows">
   <div class="inputLabel">First Name :</div><input type="text" name="firstName" value="John"/>
</div>

The first name in both these cases has to be pulled out of a java value object and rendered into the json or into the input, on the server.  Json's are lighter rendering but they are still rendered on the server.

Now with an angular implementation the html has been previously sent to the browser and cached before the json arrives.  So, the incoming json data is unpacked from the json object and dynamically written using javascript to the "html" which is now in the form of a DOM object in the page.

So, to make a long story short, the Angular paradigm caches all the HTML layout in the browser, without any data and the data is sent later.  Whereas in the jsp paradigm the layout it sent with the data.

Will this mean that less information is sent on average with the use of json.  Yes, it will.  Will the difference be so big that it noticibly affects your user's experience or your application's ability to scale.  My experience is that no it won't, especially if you write your JSP application as a SPA.  A SPA only delivers changes on the screen, unlike full page refresh, so its way more efficient than old school full page refresh JSP.  Above you can see a realistic example of the message size using the two paradigms and its not much.

So, you might ask yourself.  Why would I want to give up any of that performance improvement given to me by using the json model?

1) Speed of development.  As you can see above you still need to render json on the server and you as a developer will need to write that code.  You could use a library to unmashal your java objects but then you will end up sending huge jsons and only use a couple fields from them.  It is preferable to unpack your VO into jsons yourself.  This is the same amount of work as rendering your data straight into markup.  However, when you do jsp you are more or less done at this point.  Not so with json.  You now need to write code that "binds/unpacks" the json on the client side.  In the Angular world it looks almost exactly like jsp.  So, now you are rendering json on the server and also writing "jsp's" to run on the client.  Twice the work.

2) Complication.  Keeping your jsons and your html lined up is complicated and error prone.  It is also abstract.  Angular is more complex than good ol jsp and therefore far less intuitive.

3) Layout control.  In order to avoid writing a whole lot of complex packing unpacking javascript on your own you will most certainly leverage angular widgets to do a lot of this heavy lifting for you.  Since these widgets are sewing together your jsons and your layout, you now have much less control over you html, css, and everything else.  This might be all fine and good if you are happy with an average to crappy looking UI.  However, I have worked with Web Designer wizards and those guys want to control every div, every class, and every aspect of the layout.  They hate it when a framework is doing what it feels on the client side and making their lives difficult.  On the other hand when you deliver straight up HTML you give them full control of everything, then you as a web developer only concern yourself with tags that throw dynamic content into the layout and leave the rest of the layout to an expert.

4) Jquery libraries.  Great things have been done with jquery but these libraries do not work well unless the DOM is stable.  For example, jquery drag drop is super powerful but it won't work well if angular is pulling the rug out from under its feet while its trying to do its own thing.  Go google "using jquery drag drop with angular" if you want some examples.  So, there has been a drag drop written for Angular now, but is that what you really want?  You want to have everything you write have to be angular aware now and to work side by side with angular to make sure that the javascript code does not fight for control of the DOM?  What happens when there is an Angular upgrade and they redefine some kind of notification queue or the way an event is attached.  I'd rather have a stable DOM in a known state that I can then layer stand alone js utilities on.

I think that covers it.

It depends on your application.  If your application has lots of screens then I generally stick with the classic MVC pattern.  However, I definitely prefer the SPA design pattern with classic MVC over full page refresh because FPR forces you to constantly persist user input to the server user session between data collection pages until you finally persist to the database.  This can create a real spiders web of controller mappings, which doesn't proliferate near as much with a SPA.  An Angular pattern works best with a simple application containing few screens but lots of chatty back and forth of a few items.  The json data binding model of Angular becomes a real headache when you have lots of screens with lots of variety.  It's a pain to maintain for developers and I've seen it get really sphagetti-ish.

You may hear that Angular is better overall because of its use of stateless service REST calls to pull down data.  However, a web server hosting classic MVC can easily be made to be a pipeline node leading to all the different service calls anyway.  Even when used with Angular, I prefer the architecture of this pipeline model because its impractical to authenticate  a browser against multiple servers and doing so creates a single origin violation anyways.  So, most developers trying to talk to services through Angular hit a proxy server that servers as a pipeline to the services.

So, in the end, a classic MVC vs Angular discussion isn't actually a debate about the ability to support services and micro services.  Both architectures can leverage services just as effectively.  It is actually a debate about where you think its easier to maintain your layout, on the browser or on a web server.  It's not about performance either.  Anyone that tells you an Angular app significantly outperforms a JSP app because the layout is not as heavy as the json is living in the early 2000s.  The improvements in CSS have made it possible to make the HTML very thin (example, no reason to round corners with images anymore), and network speeds are such that a 2k json object and a 10k html page with data in it are so close in performance that your users won't feel the difference.  Furthermore, Angular's heavy js framework can perform poorly on the browser side for large pages when grinding through large json arrays especially when building tables.

I see everyone dropping Angular where I work.  It seems that React is the golden child these days.  I honestly do not have enough experience with React yet to accurately compare it.  However, I think a well written SPA is still a great way to write an application, and jsp is so darn intuitive it is hard to beat for felixibility, development efficiency and control.

I'm sure there are some devoted Angular specialists that are eager to chime in here.

Retrieve the DOM object and call .click() on it.  Here is some example code.  Sometimes you might have issues with how the event is propagated, but try this first and see how it works.

https://www.w3schools.com/jsref/met_html_click.asp

Here is some info on propagation

https://www.sitepoint.com/event-bubbling-javascript/

Q: What view technology can be used with the Spring framework besides JSP?
A:  JSP if you want to return HTML.  Jackon for REST JSON (restful services).  There are also libraries for XML, but I am unfamiliar with them.

Q: Does the Spring framework allow the use of making calls to stored procedures through MyBatis?
A: You can use raw JDBC or use the connection pool of your container (example JNDI) to call stored procs.  They are just database calls.  I have no experience with MyBatis.  I do recommend avoiding Hibernate because it abstracts database transactions in what in my opinion is a bad way.  If you like to bring your database down because of unreleased connections use Hibernate, ha ha.

Q: Which servers can Spring applications be deployed on? Can they be deployed on Resin or WebSphere?
Any J2EE container.  WebSphere and Weblogic would be overkill because you don't need EJB's if you have Spring.  Tomcat and derivatives like Jboss are good.  I really like Tomcat.  It's solid and simple.  If you don't need anything more then that is my choice.  My favorite fully stacked J2EE container is Weblogic.  WebSphere is the worst J2EE container I have dealt with, especially since it doesn't support autodeploy by simple class file update in an expanded jar.  Websphere is supposedly integrated with Irad, but they both seem to be really unstable when used together for development.

Your primary key needs to be generated by the database, not in java.  That way you will have no issues with records being added by threads in race conditions.  There are two ways that I know of.

autoincrement:

Many databases have an autoincrement type field for this purpose.  Inserting the record in the table will result in the field being populated with the next available number.  Usually, you can return a handle from the insert statement that gives you immediate access to your new id.

https://www.w3schools.com/sql/sql_autoincrement.asp

sequences:

I have experience with Oracle and in it you use a sequence object.  You select from the sequence to get the next number in this case.  Here are some links for more info.

https://docs.oracle.com/cd/B28359_01/server.111/b28310/views002.htm#ADMIN11792