Dave Newton wrote:
--- Rubens <[EMAIL PROTECTED]> wrote:
I need to make a decision whether to use Struts vs Struts2.
Even a year ago I would have used S2 over S1; AFAIC there's absolutely no
question whatsoever.
S2 is being used in production apps; I have two running now, will have two
more Q1, and know personally of several others, some in some pretty
mission-critical application spaces.
The issues I've had have been pretty easy to work around so far, although
there haven't been many show-stoppers.
d.
I agree with Dave. S2 has been exceptionally robust. I find the core
framework is more productive and even more pleasurable (!) to work with
compared to S1. The framework itself has never missed a beat for us
other than allowing a couple of security vulnerabilities sneak in via
OGNL. If you value your developers give them an opportunity to play
with S2.
The issues we do encounter have always related to specific tag libraries
(eg. dojo integration) and these have never been insurmountable. I now
take the view that its better to learn client-side libraries properly
rather than hope a struts2 tag can do everything for you. eg. <em>trying
to use dojo in a large webapp without genuinely understanding it is
bound to cause problems</em>. Interaction between other EL's and OGNL
has been annoying but I'd rather have OGNL than not. The source of S2
is readable and reasonably well documented (javadoc) and the community
is helpful.
S2 does still suffer a little from being a moving target, particular
whether to develop against the 2.0 or 2.1 baselines. The 2.0.x
increments have been relatively smooth to follow (except 2.0.11 which
was a pain). 2.1 includes some great improvements but they haven't
settled down completely for me to commit migrating 2.0 applications to
it. I do use 2.1 for new applications and once-again my only issues are
with specific plugins.
With respect to performance S2 has been adequate for us. I have no
evidence but the framework must be significantly slower than S1 though.
However, for us, the framework has been a negligible contributor to the
overall time to process requests.
In terms of evolution I'm confident to commit to S2 it on the basis it
will still be around in several years. I anticipate some of the tag
libraries will become stale but it's difficult to fault the architecture
of the framework itself. For example, the new rest plugin that delivers
a response type (html, json, xml, etc) based on the type requested (all
from the same model) demonstrates S2 has a promising future in SOA
apps. My own work is likely to head in that direction and stop using
server-side tag libraries altogether and S2 is still a strong
candidate. The integration of JRuby and Groovy with S2 are also very
promising developments.
I do have a minor concern that the future of S2 rests solely on the
interest of a few key developers, but that's probably the case with any
open source project. I think there's enough evidence that as people
drop-off others take up the slack, but it would be sooo good if someone
was simply paid or motivated to get releases out. As the dev's are
volunteers they generally tinker around the leading edge but few have
the time or inclination to think about pushing forward with the software
engineering processes (thanks Ted!). I imagine S1 has the same issue or
worse.
Finally, in terms of education, there's some good books out now and
there's a lot of sites providing tutorials (that reminds me, I'm going
to order Ian's book today[1]). However, I don't know of any
professional training courses yet and there's far fewer developers
already knowledgeable on S2 than S1. Good luck advertising a job for an
experienced S2 developer, whereas almost everyone trained in Java has
some familiarity with S1. That has to be an important consideration for
any new project..
I probably would not use S2 where the scale is so huge that I'd be
treading into uncharted waters, and where Java 1.4 or below is
mandatory. In the latter case I'd also charge the client more money due
to the loss of productivity ;-)
Hope that helps,
Jeromy Evans
[1] A good book:
http://opensource.atlassian.com/confluence/oss/display/BOOKS/ISBN-1590599039
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
