At this point I'd have to say I have no plans to migrate any apps... the
shop I'm in is pretty conservative, as evidenced by the fact that we're
still on 1.2.4 (although I snuck a 1.3 into QA a few weeks ago).
I think it was Ted who said he thinks most people don't migrate apps
upward in terms of Struts versions... my experience would echo that,
both in my own shop and in others that I communicate with people in. I
think this is one place to be careful: if you are a Struts committer/PMC
member, etc., you have something of a vested interest in using newer
versions in terms of testing and validating your own work. From what
I've seen, I don't think this is very wide-spread outside that core
group of engineers. I'm sure it *does* happen, but I don't think it's
all that frequent, unless there is some big feature or fix someone
specifically needs of course.... I am of the belief that most people
don't upgrade an apps' version of Struts very often... *probably*
infrequently enough that compatibility with SAF2 doesn't have to be a
top priority, or perhaps much of a priority at all.
Especially now that it's been clearly stated that 1.3.x will continue to
develop to some extent, I've largely changed my opinion from what it was
a few months ago... where I used to think SAF1->SAF2 compatibility was
very important, I don't really think that any more. In fact, I think a
"clean break", so to speak, might better serve everyone, both those that
just use Struts and those that are working to maintain it (and those
that do both of course!!)
In my mind, the whole thing could be boiled down to education rather
than code... for instance, I wasn't aware that there was an analogy to a
default action, Ted educated me on that. We have a Wiki page that I
started that I actually think, in a more grand form probably, would do
the tricknicely... it would basically just be a catalog of things in
SAF1 and how to do something analogous in SAF2. I think if we all
pitched in and built that up, answered as many of those types of
questions before-hand as we can, I actually don't think we have to worry
about a migration path at all. Sure, still bring forward the features
that everyone likes, that's completely reasonable, but beyond that I
think there may not be too much point in thinking about migration and
compatibility at all.
I've come to this position after a lot of time either thinking the
opposite, or being on the fence, so it's not an opinion I state lightly :)
Frank
Don Brown wrote:
Technically, that isn't correct - PlugIn's are initialized once per
module, which may or may not be once per application.
As for upgrading, I think converting a PlugIn to a context listener
would be pretty easy, so what I'm thinking would be better targets of
our work would be letting people use complex pieces like ActionForms
or JSP pages.
Are you planning to upgrade any legacy applications to Struts Action
2, and if so, what could we do to help?
Don
On 6/12/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
All of those things fire per-request though, a plugin fires only at app
startup (and of course if ActionServlet is restarted by the container,
but I think that's pretty rare). I think plugins are a different use
case entirely, aren't they?
I suppose we could recommend people use ContextListeners instead, which
I've come to prefer frankly, but if we're talking about
upgrading/compatibility, that's maybe not the best answer.
Frank
Ted Husted wrote:
> On 6/12/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
>> * Plug-ins... does SAF2 have an analogy for the Struts plug-in
>> mechanism? If not, this should be looked at (it doesn't strike me as
>> too tough if it has to be developed).
>
> Depending on the use case, you'd either use an interceptor, dependency
> injection, or an actual filter.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
