Re: Struts 1 migrate to Struts 2 question

[Dave Newton]

>
> The effort required to upgrade and test a large application to Struts
> version 2 looks very large.  The effort to upgrade and test the entire
> application in a single release looks undoable.
>

Agreed.


> 1)  Are there any software tools that can be used to speed up the time
> to update JSPs, page validation, tag library calls, Action classes, etc to
> reduce development, improve code quality, and reduce testing time?
>

None that I'm aware of.


> 2)  Can a single application use both Struts 1 and Struts 2 at the
> same time?
>

Yes.


> a.   Would it be feasible to use Struts 2 for any new pages and
> upgrade to Struts 2 for any pages being changed for other reasons?
>

Yes.


> 3)  We do an application release every 6 weeks or so.  We can't do
> this in one release unless we find or develop a tool to help us convert
> pages to Struts 2.  We are considering upgrading 100 pages per release to
> Struts 2.  Has anyone done something like this successfully?  What are best
> practices and lessons learned?
>

That strikes me as a fairly aggressive timeline, obviously it depends on
the pages and functionality.

There are zero similarities between S1 and S2. If your S1 app was
well-architected the effort will be confined to the view and controller
layers, at least, but even that is non-trivial.

4)  Test effort.  With all of the code changes required it seems that
> developers could miss things.
>

If you have no integration tests, then yes, this will be fraught with
potential issues. Again, a well-architected S1 app is in less danger since
the important business logic is already isolated and Struts acts only as a
mediation layer between the client (e.g., the browser or API users) and the
business logic.

The ultimate answer(s) really depends on the nature of your app. If the JSP
pages are simple it might be possible to write a small conversion tool that
does a rough translation between tag libraries; beyond that... it'll be
mostly manual labor.

Dave

-- 
e: davelnew...@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton 
b: Bucky Bits 
g: davelnewton 
so: Dave Newton 

Struts 1 migrate to Struts 2 question

[Xu, Hui@DCSS]

We are planning to migrate to Struts 2.3.24.1 from Struts 1.1. Here are our 
questions:


We have large and complex case management application that uses struts and 
struts menu version 1.1.  The application has over 1,000 pages many of which 
contain many data elements.

The effort required to upgrade and test a large application to Struts version 2 
looks very large.  The effort to upgrade and test the entire application in a 
single release looks undoable.

Questions:

1)  Are there any software tools that can be used to speed up the time to 
update JSPs, page validation, tag library calls, Action classes, etc to reduce 
development, improve code quality, and reduce testing time?

2)  Can a single application use both Struts 1 and Struts 2 at the same 
time?

a.   Would it be feasible to use Struts 2 for any new pages and upgrade to 
Struts 2 for any pages being changed for other reasons?

b.  What are considerations for groups of pages would need to be converted 
together (for example shared conversation for page flows)

3)  We do an application release every 6 weeks or so.  We can't do this in 
one release unless we find or develop a tool to help us convert pages to Struts 
2.  We are considering upgrading 100 pages per release to Struts 2.  Has anyone 
done something like this successfully?  What are best practices and lessons 
learned?

4)  Test effort.  With all of the code changes required it seems that 
developers could miss things.

Everything we have seen so far indicates that this will be a huge effort for 
both development and testing.  We are trying to find ways to 
streamline/automate some of this effort.  Any help would be appreciated.



CONFIDENTIALITY NOTICE: This communication with its contents may contain 
confidential and/or legally privileged information. It is solely for the use of 
the intended recipient(s). Unauthorized interception, review, use or disclosure 
is prohibited and may violate applicable laws including the Electronic 
Communications Privacy Act. If you are not the intended recipient, please 
contact the sender and destroy all copies of the communication.