Per the release notes page, "You are strongly advised to resolve all
Struts 1.1 deprecations before moving " to the newest release., and
"Alternatives should be available for all decprecated[sic] constructs."
However, I am having some problems trying to determine my alternatives for
some of the key utilities, i.e. the RequestUtils to TagUtils and
ActionErrors to ActionMessages.
IMHO, the move from RequestUtils to TagUtils is a good one.
However, there is a problem with the notion of fixing the deprecations--the
1.1 release does not contain org.apache.struts.taglib.TagUtils that the
deprecation points to! This means that our custom taglibs that compile
against struts.jar in order to get the utility classes cannot be patched
without a complete 1.2 update--which forces ALL the apps to update as well,
since the tags will otherwise end up with an UnsatisfiedLinkException at
runtime. This is obviously unacceptable, so we have a few options, none of
which are really great...
1) Keep binary versions of our own libraries in each app.
2) Create branches in each app and library in order to satisfy automated
builds that like everything to have matching branch names (and for good
reason).
3) Code around the deprecations, duplicating some of the struts utility code
for the likes of RequestUtils.message
# 1 means that new taglib builds or bug fixes are not automatically applied
to the app.
# 2 means our "current" development for some apps is on a branch, while
others have their "current" development on the HEAD stream, which is odd.
# 3 ... ick.
As for the ActionErrors change, I also think this is a wise choice.
The fact that the ActionForm validate() api still returns an
ActionErrors object is a known problem and hopefully a dead horse on the dev
list. =)
However, if validation or messages are created anywhere else in a
struts 1.1 application for use by tags such as html:errors, there are
problems. I can easily create and fill ActionErrors objects in an action
and store them in the appropriate request location to make them available to
the html:errors tag. I can even change these over to ActionMessages
objects, seemingly without pain. However, if I do this, the html:errors tag
blows up with a ClassCastException (running under struts 1.1) so a) apps
can't be tested or verified with the modified code prior to migration b) new
apps are still being written with ActionErrors even though it is known to be
deprecated. This, again, leads to a few options...
1) Keep binary versions of our own libraries in each app.
2) Create branches in each app and library in order to satisfy automated
builds that like everything to have matching branch names (and for good
reason).
3) Code around the deprecations, duplicating some of the struts html tags
# 1 means that new taglib builds or bug fixes are not automatically applied
to the app.
# 2 means our "current" development for some apps is on a branch, while
others have their "current" development on the HEAD stream, which is odd.
# 3 ... ick.
If anyone has any other options, please let me know. Otherwise, for
those of you on the committers list, please consider the following...
Option #4: Request an incremental/patch release on 1.1 that includes
a) the new TagUtils class
b) an html:errors tag that will handle either ActionErrors or
ActionMessages.
a) Doesn't completely avoid all issues, but it won't break any existing 1.1
code and allows a smoother migration.
b) Looking at the source, the current 1.2 version of the tag should work
fine as ActionErrors extends ActionMessages etc.
Thanks,
--David
David Hibbs, ACS
Staff Programmer / Analyst
American National Insurance Company
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
