You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Don Brown <do...@gmail.com> on 2006/06/12 21:16:35 UTC
Poll: What part of a Struts will be the most important to support for migration?
As we approach the topic of migration for Struts Action 1 applications
to Struts Action 2, I want to find out what we should focus on first.
You are able to run both frameworks side-by-side, but for the
developers that want to migrate a Struts 1.x application to Action 2,
what aspect of a Struts Action 1 application is the most important to
support for migration?
1. ActionForms
2. Actions
3. Validator definitions
4. Message resources
5. Struts configuration files
6. HTML tag libraries
7. Other (please explain)
Please let us know your thoughts so we can focus on developing tools
to make migration as easy as possible. Thanks,
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/13/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Just so I'm clear, because I frankly wasn't paying attention previously
> :)... are we favoring this Confluence instance over the Struts Wiki for
> this sort of thing?
As it stands, all of the SAF2 documentation is under Confluence.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to
support for migration?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Tue, June 13, 2006 8:30 am, Ted Husted wrote:
> I also went ahead and moved the Struts Action 2 migration material
> into the SAF2 documentation.
>
> * http://confluence.twdata.org/display/WW/Migration+Guide
Just so I'm clear, because I frankly wasn't paying attention previously
:)... are we favoring this Confluence instance over the Struts Wiki for
this sort of thing? If so I'll create an account because I anticipate
having some more to add to the page you ported over (thanks by the way,
nice to have it all in one spot).
> My suggestion is that any migration guides or tools should be based on
> our own actual experience -- which is the whole idea behind open
> source. We eat our own dog food, and then we pass the bowl. (Yumm!
> Just the thing to read over breakfast!)
Definitely agree, and to that end I have three SAF1-based apps that I
intend to do a migration with shortly... they are outside work apps, so I
have that freedom. They are small enough that they shouldn't be killer,
but also large and complex enough that they should serve as decent tests
and turn some things up.
> -Ted.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>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.
Hmmm, well guides like the one you describe *are* thinking a lot about
migration and compatibility, just not binary "out-of-the-box" backward
compatability. But, since this is a major release, and therefore by
definition a revolution, i think that's OK.
There's another page comparing SAF1 and SAF2 from a high-level here:
* http://confluence.twdata.org/display/WW/Comparing+SAF1+and+SAF2
I also went ahead and moved the Struts Action 2 migration material
into the SAF2 documentation.
* http://confluence.twdata.org/display/WW/Migration+Guide
Meanwhile, we've migrated the MailReader to WW2
* http://svn.apache.org/viewvc/struts/sandbox/trunk/action2/apps/mailreader/src/
and the next step is to move it to the latest SAF2 build. It would
then be interesting to do some 1:1 comparisons of SAF1 and SAF2
idioms. I'd also like to migrate the iBATIS Petstore application,
since many people have used that application as a starting point. It
would also be interesting, but not trivial, to migrate XPlanner and
Roller.
My suggestion is that any migration guides or tools should be based on
our own actual experience -- which is the whole idea behind open
source. We eat our own dog food, and then we pass the bowl. (Yumm!
Just the thing to read over breakfast!)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support
for migration?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <fz...@omnytex.com> 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 <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>> >
>> >
>>
>> --
>> Frank W. Zammetti
>> Founder and Chief Software Architect
>> Omnytex Technologies
>> http://www.omnytex.com
>> AIM: fzammetti
>> Yahoo: fzammetti
>> MSN: fzammetti@hotmail.com
>> Java Web Parts -
>> http://javawebparts.sourceforge.net
>> Supplying the wheel, so you don't have to reinvent it!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support
for migration?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Don Brown wrote:
> Technically, that isn't correct - PlugIn's are initialized once per
> module, which may or may not be once per application.
Yes, good point, once per module, right.
But "may or may not be once per application"? This part I'm not as sure
about. The plugins, if memory serves. are called from init() of
ActionServlet (the call to initModulePlugIns() I think?)... so, they are
subject to loading and unloading of the servlet by the container, and
that can result in them being called more than once, true... Aside from
that possibility though, is there any other way a plugin could be called
more than once per application (and per module) startup? I didn't think so.
Eh, this isn't really all that important in the context of this
discussion anyway... I think the more cogent point is that I don't think
a plugin can be said to be analogous to a filter or interceptor, that's
my feeling anyway, and therefore there needs to be some analogy in SAF2,
whether something new or just a recommendation to use ContextListener
instead (which works just fine for me :) )
> 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.
I think this is probably true... of course, you'd be missing the
referent to ActionServlet and ModuleConfig, but I agree, putting that
aside, the conversion probably isn't a big deal. I think recommending
conversion to ContextListeners is a perfectly reasonable response. That
would avoid entirely the possible double-execution caused by a servlet
reload as well, which is definitely better.
> Are you planning to upgrade any legacy applications to Struts Action
> 2, and if so, what could we do to help?
See my other reply :)
> Don
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Don Brown <do...@gmail.com>.
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 <fz...@omnytex.com> 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 <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support
for migration?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> * Unknown - I'm not seeing the ability to mark an action as mapping to
> unknown paths like you can in SAF1... am I just missing it?
Yes, you can set a default-action in the configuration to use when
nothing else matches.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for m
Posted by Alexandru Popescu <th...@gmail.com>.
Isn't possible to be an issue with XWork dependency? I don't think 2
different versions of XWork can co-exist on the same webapp.... but I
may be wrong.
./alex
--
.w( the_mindstorm )p.
On 6/13/06, Jason Carreira <fo...@opensymphony.com> wrote:
> > Well, it would have made Atlassian's life easier.
> > JIRA is written with
> > WW1 and Confluence is written with WW2, the two
> > versions cannot
> > coexist in the same web application, and they still
> > haven't gotten
> > around to migrating JIRA. When people (like me) run
> > both applications,
> > we need to run them as two separate web apps, instead
> > of two "modules"
> > that can share session.
>
> Not to nitpick, but WW1 and WW2 CAN peacefully coexist, because we changed the package names in the change. At Notiva we converted the app piecemeal from WW1 to WW2 over time, moving over new pieces and migrating anything old that we had to touch. We simply mapped them to different extensions.
>
> I'm not sure why Atlassian didn't switch over. Maybe it just didn't ever make sense. Maybe there was some other issue with common configuration files that we didn't run into at Notiva. But I can tell you that they can run side-by-side, just as WebWork 2.x and Struts 2.x will be able to.
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=34181&messageID=66503#66503
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Ted Husted <te...@gmail.com>.
That's exactly what Struts 2 does with interceptors, and S2 takes it a
step farther by allowing each action to have its own sequence, if you
like.
An important question is whether we want to stick with Chain in the
Struts 1.x series or consider moving to Interceptors for Struts 1.4.
I didn't understand interceptors when we started the Commons Chain
work, but now that I do, it looks like we reinvented the wheel.
-Ted.
On 6/30/06, Phil Zoio <ph...@iogloballtd.com> wrote:
> Joe,
>
> Could Struts 1.3 set up to have a separate chain per module? Suppose you
> wanted to partition your app so that certain parts use one chain
> configuration and other parts use another. In 1.2 you'd use separate
> subclasses of RequestProcessor. With Struts 1.3, ideally you should be
> able to use separate chains. You could for example build a lightweight
> chain to handle parts of the application with specific performance
> requirements, and the standard chain for other parts.
>
> Bearing in mind that a chain is a pretty lightweight object - there will
> only be one instance of each command in memory per chain.
>
> Any module would by default get the basic pre-supplied chain
> configuration. However, you would be able to override this using a
> web.xml entry in the same way that you set up modules.
>
> Phil
>
>
> > Joe Germuska wrote:
> >
> >> At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
> >>
> >>> I can't comment on how people are actually using it, but changing
> >>> the request processor workflow on a per module basis is quite easy
> >>> with Struts 1.2. Assuming that this is something which some people
> >>> are doing, then it would seem to make sense to support this for
> >>> Struts 1.3 as well, at least for the interests of consistency with
> >>> previous versions, especially if the 1.2 request processor has been
> >>> earmarked for deprecation.
> >>
> >>
> >>
> >> Phil:
> >>
> >> Have you looked at what is required to change the workflow in Struts
> >> 1.3 on a per-module basis? Can you point out where you think it's
> >> unnecessarily complicated? Do you have any ideas about how to do it
> >> differently?
> >>
> >> Joe
> >>
> >>
> >>> At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
> >>>
> >>>> Is it possible to have multiple chain configurations for the same
> >>>> Struts 1.3 app. For example, can you configure one module to use
> >>>> tiles and another to not do so?
> >>>
> >>>
> >>>
> >>>
> >>> It is technically possible to change which command is looked up in
> >>> the catalogs and executed to process the request as part of the
> >>> controller-config on per-module basis. However, you'd need to go
> >>> to some greater lengths to define the necessary commands and
> >>> catalogs, because the distributed chain-config.xml in both
> >>> struts-core and struts-tiles use the same catalog name. The idea
> >>> was to minimize the places where a user would need to change
> >>> configurations to use Tiles.
> >>
> >>
> >>
> >>>
> >>> For the specific case you cite, there's really no need to do
> >>> anything special, since if you are using the Tiles request
> >>> processing chain, nothing prevents you from using ActionForwards
> >>> which do not point to tiles paths intermixed with those which do.
> >>> Just use the chain-config packaged in struts-tiles (as indicated at
> >>> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
> >>>
> >>>
> >>> If people end up doing a lot of mixing and matching of chain
> >>> catalogs, we would want to make this easier than it is now, but so
> >>> far we just don't know enough about if or how people are likely to
> >>> want to do this, so it's hard to know how to make it easier.
> >>>
> >>
> >>> Joe
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >
> >>
> >>
> >>
> >
> >
>
>
> iO global limited, Registered in England No. 05269056 Reg. Offices: G10 B83 Columba House, Martlesham Heath, Ipswich, Suffolk. IP5 3RE
>
> This electronic message contains information from iO global limited which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.
>
> This email does not constitute a contract. E&OE
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
HTH, Ted.
* http://www.husted.com/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Phil Zoio <ph...@realsolve.co.uk>.
Joe,
Yes, I seem to pick up this issue every two weeks, and coming back to it
again.
After reading your answers again and delving into the source code, I
think I understand the mechanism pretty well. The problem for me is that
Commons Chain does not seem to have an override capability.
A couple of examples:
- if you want to use Tiles, you need to either a) uncomment the tiles
entry in the default chain config or b) use the replacement tiles chain
config file. IMO, you should be able to add Tiles support by specifying
an additional config file containing only the entries needed to support
tiles. The main config file should be designed to allow entries to be
easily overridden or enhanced. A similar mechanism works very well in
Spring - the way you replace/override existing beans using bean entries
with the same name in a subsequent config file.
- if you want to have different chains per module, you'd seem need a
lot of repeating definitions. I think the result could be pretty
verbose, again because of the apparent absence of an override mechanism.
Also, I do think you would be better off having different sets of chain
instances per module (ie one per ComposableRequestProcessor instance).
The background of all this is that I'm trying to fine tune the way that
Strecks supports Struts 1.3.x (which is now present in Strecks 1.0 beta
3). I'm configuring 1.3 support entirely via chain commands, so it would
make a big difference if this was easy, especially in allowing for
different configurations per module.
The bigger question which is lurking in my mind is whether there is a
real actual (as against hypothetical) benefit to be gained from the 1.3
chain request processor. If the chain was easy to configure, it would be
a no-brainer, but if configuration is not easier, then the advantages
are much less clear.
Phil
Joe Germuska wrote:
> At 9:07 AM +0100 6/30/06, Phil Zoio wrote:
>
>> Joe,
>>
>> Could Struts 1.3 set up to have a separate chain per module?
>
>
>
> Phil: I thought we discussed this two weeks ago. In short, the
> answer is "yes". Looking back at what I wrote, perhaps I gave too
> much detail at the wrong time. Here is the core of it:
>
>>> >>> It is technically possible to change which command is looked up in
>>>
>>>>>> the catalogs and executed to process the request as part of the
>>>>>
>>> >>> controller-config on per-module basis.
>>
>
> For context, Struts uses commons-chain code to instantiate a universe
> of catalogs which contain commands. You'd use the <controller> to
> specify the name of a catalog and the name of a command within that
> catalog which is to be executed to process the request. Therefore,
> you could specify different "bootstrap" commands for each controller
> until you turn blue.
>
> Joe
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:07 AM +0100 6/30/06, Phil Zoio wrote:
>Joe,
>
>Could Struts 1.3 set up to have a separate chain per module?
Phil: I thought we discussed this two weeks ago. In short, the
answer is "yes". Looking back at what I wrote, perhaps I gave too
much detail at the wrong time. Here is the core of it:
>> >>> It is technically possible to change which command is looked up in
>>>>> the catalogs and executed to process the request as part of the
>> >>> controller-config on per-module basis.
For context, Struts uses commons-chain code to instantiate a universe
of catalogs which contain commands. You'd use the <controller> to
specify the name of a catalog and the name of a command within that
catalog which is to be executed to process the request. Therefore,
you could specify different "bootstrap" commands for each controller
until you turn blue.
Joe
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Phil Zoio <ph...@iogloballtd.com>.
Joe,
Could Struts 1.3 set up to have a separate chain per module? Suppose you
wanted to partition your app so that certain parts use one chain
configuration and other parts use another. In 1.2 you'd use separate
subclasses of RequestProcessor. With Struts 1.3, ideally you should be
able to use separate chains. You could for example build a lightweight
chain to handle parts of the application with specific performance
requirements, and the standard chain for other parts.
Bearing in mind that a chain is a pretty lightweight object - there will
only be one instance of each command in memory per chain.
Any module would by default get the basic pre-supplied chain
configuration. However, you would be able to override this using a
web.xml entry in the same way that you set up modules.
Phil
> Joe Germuska wrote:
>
>> At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
>>
>>> I can't comment on how people are actually using it, but changing
>>> the request processor workflow on a per module basis is quite easy
>>> with Struts 1.2. Assuming that this is something which some people
>>> are doing, then it would seem to make sense to support this for
>>> Struts 1.3 as well, at least for the interests of consistency with
>>> previous versions, especially if the 1.2 request processor has been
>>> earmarked for deprecation.
>>
>>
>>
>> Phil:
>>
>> Have you looked at what is required to change the workflow in Struts
>> 1.3 on a per-module basis? Can you point out where you think it's
>> unnecessarily complicated? Do you have any ideas about how to do it
>> differently?
>>
>> Joe
>>
>>
>>> At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
>>>
>>>> Is it possible to have multiple chain configurations for the same
>>>> Struts 1.3 app. For example, can you configure one module to use
>>>> tiles and another to not do so?
>>>
>>>
>>>
>>>
>>> It is technically possible to change which command is looked up in
>>> the catalogs and executed to process the request as part of the
>>> controller-config on per-module basis. However, you'd need to go
>>> to some greater lengths to define the necessary commands and
>>> catalogs, because the distributed chain-config.xml in both
>>> struts-core and struts-tiles use the same catalog name. The idea
>>> was to minimize the places where a user would need to change
>>> configurations to use Tiles.
>>
>>
>>
>>>
>>> For the specific case you cite, there's really no need to do
>>> anything special, since if you are using the Tiles request
>>> processing chain, nothing prevents you from using ActionForwards
>>> which do not point to tiles paths intermixed with those which do.
>>> Just use the chain-config packaged in struts-tiles (as indicated at
>>> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
>>>
>>>
>>> If people end up doing a lot of mixing and matching of chain
>>> catalogs, we would want to make this easier than it is now, but so
>>> far we just don't know enough about if or how people are likely to
>>> want to do this, so it's hard to know how to make it easier.
>>>
>>
>>> Joe
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
>>
>>
>>
>
>
iO global limited, Registered in England No. 05269056 Reg. Offices: G10 B83 Columba House, Martlesham Heath, Ipswich, Suffolk. IP5 3RE
This electronic message contains information from iO global limited which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.
This email does not constitute a contract. E&OE
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Phil Zoio <ph...@realsolve.co.uk>.
Joe Germuska wrote:
> At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
>
>> I can't comment on how people are actually using it, but changing the
>> request processor workflow on a per module basis is quite easy with
>> Struts 1.2. Assuming that this is something which some people are
>> doing, then it would seem to make sense to support this for Struts
>> 1.3 as well, at least for the interests of consistency with previous
>> versions, especially if the 1.2 request processor has been earmarked
>> for deprecation.
>
>
> Phil:
>
> Have you looked at what is required to change the workflow in Struts
> 1.3 on a per-module basis? Can you point out where you think it's
> unnecessarily complicated? Do you have any ideas about how to do it
> differently?
>
> Joe
>
Joe - I haven't yet - I will need to understand the mechanism you are
talking about a bit better. I'm still not very familiar with commons chain.
Phil
>
>
>> Phil
>>
>>
>> Joe Germuska wrote:
>>
>>> At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
>>>
>>>> Is it possible to have multiple chain configurations for the same
>>>> Struts 1.3 app. For example, can you configure one module to use
>>>> tiles and another to not do so?
>>>
>>>
>>>
>>> It is technically possible to change which command is looked up in
>>> the catalogs and executed to process the request as part of the
>>> controller-config on per-module basis. However, you'd need to go
>>> to some greater lengths to define the necessary commands and
>>> catalogs, because the distributed chain-config.xml in both
>>> struts-core and struts-tiles use the same catalog name. The idea
>>> was to minimize the places where a user would need to change
>>> configurations to use Tiles.
>>
>>
>>>
>>> For the specific case you cite, there's really no need to do
>>> anything special, since if you are using the Tiles request
>>> processing chain, nothing prevents you from using ActionForwards
>>> which do not point to tiles paths intermixed with those which do.
>>> Just use the chain-config packaged in struts-tiles (as indicated at
>>> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
>>>
>>>
>>> If people end up doing a lot of mixing and matching of chain
>>> catalogs, we would want to make this easier than it is now, but so
>>> far we just don't know enough about if or how people are likely to
>>> want to do this, so it's hard to know how to make it easier.
>>>
>>
>>> Joe
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:09 PM +0100 6/14/06, Phil Zoio wrote:
>I can't comment on how people are actually using it, but changing
>the request processor workflow on a per module basis is quite easy
>with Struts 1.2. Assuming that this is something which some people
>are doing, then it would seem to make sense to support this for
>Struts 1.3 as well, at least for the interests of consistency with
>previous versions, especially if the 1.2 request processor has been
>earmarked for deprecation.
Phil:
Have you looked at what is required to change the workflow in Struts
1.3 on a per-module basis? Can you point out where you think it's
unnecessarily complicated? Do you have any ideas about how to do it
differently?
Joe
>Phil
>
>
>Joe Germuska wrote:
>
>>At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
>>
>>>Is it possible to have multiple chain configurations for the same
>>>Struts 1.3 app. For example, can you configure one module to use
>>>tiles and another to not do so?
>>
>>
>>It is technically possible to change which command is looked up in
>>the catalogs and executed to process the request as part of the
>>controller-config on per-module basis. However, you'd need to go
>>to some greater lengths to define the necessary commands and
>>catalogs, because the distributed chain-config.xml in both
>>struts-core and struts-tiles use the same catalog name. The idea
>>was to minimize the places where a user would need to change
>>configurations to use Tiles.
>
>>
>>For the specific case you cite, there's really no need to do
>>anything special, since if you are using the Tiles request
>>processing chain, nothing prevents you from using ActionForwards
>>which do not point to tiles paths intermixed with those which do.
>>Just use the chain-config packaged in struts-tiles (as indicated at
>>http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
>>
>>If people end up doing a lot of mixing and matching of chain
>>catalogs, we would want to make this easier than it is now, but so
>>far we just don't know enough about if or how people are likely to
>>want to do this, so it's hard to know how to make it easier.
>>
>
>>Joe
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Phil Zoio <ph...@realsolve.co.uk>.
I can't comment on how people are actually using it, but changing the
request processor workflow on a per module basis is quite easy with
Struts 1.2. Assuming that this is something which some people are doing,
then it would seem to make sense to support this for Struts 1.3 as well,
at least for the interests of consistency with previous versions,
especially if the 1.2 request processor has been earmarked for deprecation.
Phil
Joe Germuska wrote:
> At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
>
>> Is it possible to have multiple chain configurations for the same
>> Struts 1.3 app. For example, can you configure one module to use
>> tiles and another to not do so?
>
>
> It is technically possible to change which command is looked up in the
> catalogs and executed to process the request as part of the
> controller-config on per-module basis. However, you'd need to go to
> some greater lengths to define the necessary commands and catalogs,
> because the distributed chain-config.xml in both struts-core and
> struts-tiles use the same catalog name. The idea was to minimize the
> places where a user would need to change configurations to use Tiles.
>
> For the specific case you cite, there's really no need to do anything
> special, since if you are using the Tiles request processing chain,
> nothing prevents you from using ActionForwards which do not point to
> tiles paths intermixed with those which do. Just use the chain-config
> packaged in struts-tiles (as indicated at
> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
>
>
> If people end up doing a lot of mixing and matching of chain catalogs,
> we would want to make this easier than it is now, but so far we just
> don't know enough about if or how people are likely to want to do
> this, so it's hard to know how to make it easier.
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts 1.3.x: Using multiple chain configurations
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:23 PM +0100 6/13/06, Phil Zoio wrote:
>Is it possible to have multiple chain configurations for the same
>Struts 1.3 app. For example, can you configure one module to use
>tiles and another to not do so?
It is technically possible to change which command is looked up in
the catalogs and executed to process the request as part of the
controller-config on per-module basis. However, you'd need to go to
some greater lengths to define the necessary commands and catalogs,
because the distributed chain-config.xml in both struts-core and
struts-tiles use the same catalog name. The idea was to minimize the
places where a user would need to change configurations to use Tiles.
For the specific case you cite, there's really no need to do anything
special, since if you are using the Tiles request processing chain,
nothing prevents you from using ActionForwards which do not point to
tiles paths intermixed with those which do. Just use the
chain-config packaged in struts-tiles (as indicated at
http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d)
If people end up doing a lot of mixing and matching of chain
catalogs, we would want to make this easier than it is now, but so
far we just don't know enough about if or how people are likely to
want to do this, so it's hard to know how to make it easier.
Joe
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Struts 1.3.x: Using multiple chain configurations
Posted by Phil Zoio <ph...@realsolve.co.uk>.
Is it possible to have multiple chain configurations for the same Struts
1.3 app. For example, can you configure one module to use tiles and
another to not do so?
Regards,
Phil Zoio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to
support for m
Posted by Jason Carreira <fo...@opensymphony.com>.
> Well, it would have made Atlassian's life easier.
> JIRA is written with
> WW1 and Confluence is written with WW2, the two
> versions cannot
> coexist in the same web application, and they still
> haven't gotten
> around to migrating JIRA. When people (like me) run
> both applications,
> we need to run them as two separate web apps, instead
> of two "modules"
> that can share session.
Not to nitpick, but WW1 and WW2 CAN peacefully coexist, because we changed the package names in the change. At Notiva we converted the app piecemeal from WW1 to WW2 over time, moving over new pieces and migrating anything old that we had to touch. We simply mapped them to different extensions.
I'm not sure why Atlassian didn't switch over. Maybe it just didn't ever make sense. Maybe there was some other issue with common configuration files that we didn't run into at Notiva. But I can tell you that they can run side-by-side, just as WebWork 2.x and Struts 2.x will be able to.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=34181&messageID=66503#66503
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Craig McClanahan <cr...@apache.org> wrote:
> Having two frameworks to keep track of instead of one, each with their own
> idiosyncracies and release trains, is not making life better for the
> engineers that have to maintain that kind of a beast.
Well, it would have made Atlassian's life easier. JIRA is written with
WW1 and Confluence is written with WW2, the two versions cannot
coexist in the same web application, and they still haven't gotten
around to migrating JIRA. When people (like me) run both applications,
we need to run them as two separate web apps, instead of two "modules"
that can share session.
If I have a work-in-progress that hasn't shipped, sure I'd be tempted
to migrate it all to the next major release. But, that's OK, because
it's a work-in-progress and it hasn't gone through final acceptance
testing yet. (In some shops, the acceptance test phase can take six
weeks or more.)
If I've already shipped something, and we go from 1.x to 2.x of
*anything*, it's going to mean doing the acceptance tests all over
again. (At least if I like my job!) Not only Struts, but also a
*major* release of any other framework I might use, like Spring or
iBATIS or Java itself. Even if the vendor says "nothing breaks", a
sane engineer folds his or her own parachute.
Albeit, if we need to add some new features, and the two major
versions can coexist, we have the opportunity to do the new features
in the new version, since these features will be tested independantly.
Ditto for significant bugs. If we're reworking something to cure a bug
that's going to go through acceptance testing, then we could rework it
in the new version.
At some point in time, my own application is going to go through a
major release of its own. When that happens, we would consider
bringing over the rest of the application to the new version too. But,
by then, we've done enough work in the new version that we can make an
intelligent estimate of how long it will take, and what sort of
problems we might have.
The important element in this equation is that *we* get to choose what
*we* want to migrate when. It can be everything, or it can be some
things now and some things later, but we get to choose.
My own preference would be to follow Frank's general strategy. We
continue to migrate our own applications, document the correlations,
and then maybe develop some text-processing tools to automate the
mapping.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Craig McClanahan <cr...@apache.org>.
On 6/12/06, Ted Husted <te...@gmail.com> wrote:
>
> And, if we are creating a SAF1 emulator, why not just use SAF1? Let
> SAF1 handles the *.dos, and let SAF2 handle the *.actions.
Having two frameworks to keep track of instead of one, each with their own
idiosyncracies and release trains, is not making life better for the
engineers that have to maintain that kind of a beast.
-Ted.
Craig
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Don Brown <do...@gmail.com>.
>From the start, we have made it a priority to allow Struts Action 1
and 2 applications to exist side-by-side, and in fact, we will
probably end up shipping Struts Action 1 jars to make 2 a
one-stop-shop.
What I'm wondering if there are people that will be wanting to migrate
an existing application, and if so, what can we provide to help that
migration? If no one is, well, then there is the answer :)
Don
On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> You raise a good point... is it possible to run both in the same
> context? I can't think of any reason why not, but then that changes the
> overall concept, doesn't it? If you can do that, is there any reason to
> even think about supporting most SAF1 concepts? (with a few exceptions
> of course, those things that everyone thinks would be nice to have in
> SAF2). It isn't about a migration path then though, that's what I'm
> getting at... I know there had been talk of a compatibility layer a
> while ago... if that is no longer a goal, no problem here, but it would
> seem to me to nullify a lot of discussion, right? :)
>
> Frank
>
> Ted Husted wrote:
> > On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >> * HTML tag libraries - unless I'm mistaken, most, if not all of them,
> >> should work if an ActionForm is emulated and placed in scope... do any
> >> of them use anything else?
> >
> > Yep. One tag or other other uses everything, and everything has to be
> > in the right place. The form tag access the ActionMapping to look up
> > the target action. The tags localize themselves from the message
> > resources. For client-side validation, the tags access the validators
> > too.
> >
> > Of course, if someone wants to create a SAF1 configuration for SAF2,
> > that's certainly do-able. But, I'd be very (happily) urprised if the
> > job could be done piecemeal.
> >
> > And, if we are creating a SAF1 emulator, why not just use SAF1? Let
> > SAF1 handles the *.dos, and let SAF2 handle the *.actions.
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
> Java Web Parts -
> http://javawebparts.sourceforge.net
> Supplying the wheel, so you don't have to reinvent it!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support
for migration?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
You raise a good point... is it possible to run both in the same
context? I can't think of any reason why not, but then that changes the
overall concept, doesn't it? If you can do that, is there any reason to
even think about supporting most SAF1 concepts? (with a few exceptions
of course, those things that everyone thinks would be nice to have in
SAF2). It isn't about a migration path then though, that's what I'm
getting at... I know there had been talk of a compatibility layer a
while ago... if that is no longer a goal, no problem here, but it would
seem to me to nullify a lot of discussion, right? :)
Frank
Ted Husted wrote:
> On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> * HTML tag libraries - unless I'm mistaken, most, if not all of them,
>> should work if an ActionForm is emulated and placed in scope... do any
>> of them use anything else?
>
> Yep. One tag or other other uses everything, and everything has to be
> in the right place. The form tag access the ActionMapping to look up
> the target action. The tags localize themselves from the message
> resources. For client-side validation, the tags access the validators
> too.
>
> Of course, if someone wants to create a SAF1 configuration for SAF2,
> that's certainly do-able. But, I'd be very (happily) urprised if the
> job could be done piecemeal.
>
> And, if we are creating a SAF1 emulator, why not just use SAF1? Let
> SAF1 handles the *.dos, and let SAF2 handle the *.actions.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> * HTML tag libraries - unless I'm mistaken, most, if not all of them,
> should work if an ActionForm is emulated and placed in scope... do any
> of them use anything else?
Yep. One tag or other other uses everything, and everything has to be
in the right place. The form tag access the ActionMapping to look up
the target action. The tags localize themselves from the message
resources. For client-side validation, the tags access the validators
too.
Of course, if someone wants to create a SAF1 configuration for SAF2,
that's certainly do-able. But, I'd be very (happily) urprised if the
job could be done piecemeal.
And, if we are creating a SAF1 emulator, why not just use SAF1? Let
SAF1 handles the *.dos, and let SAF2 handle the *.actions.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support
for migration?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Some random thoughts, all of which could be way wrong :) ...
* ActionForms - What makes an ActionForm different than a SAF2 Action?
The validate() method, and the reset() method, primarily. I propose
creating a StrutsActionFormAware marker interface... when an Action
implements it, reset() and validate() are called by a new Interceptor to
emulate what SAF1 does. It would have to deal with the messages, and
I'm not sure I have the answer for that :)
* Actions - How about more or less directly migrating Action and
renaming it StrutsAction... have the SAF2 default execute() construct
appropriate Struts objects (ActionForm, ActionMapping, etc) and call the
Struts version of execute().... It should be obvious that a lot of these
ideas involve directly porting SAF1 classes over to SAF2, with some
changes to make them work with SAF2... I'd imagine this is along the
lines of the "compatibility layer" that has been talked about previously.
* HTML tag libraries - unless I'm mistaken, most, if not all of them,
should work if an ActionForm is emulated and placed in scope... do any
of them use anything else? Perhaps a new Result that takes a SAF2
Action and copies the properties to an ActionForm for the tags to use?
* Struts configuration files - I assume this refers to converting
struts-config.xml to xwork.xml? If so, I think this is one place that
is rip for a tool. In many regards they are close enough that it won't
be a big problem, but some of the more complex constructs might be an
issue (things like custom ActionMapping's and plug-ins for instance)
* 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).
* Unknown - I'm not seeing the ability to mark an action as mapping to
unknown paths like you can in SAF1... am I just missing it? If not, I
suggest implementing this since it is a commonly used security guard.
Maybe more later, but my Chinese good just got here :)
Frank
Don Brown wrote:
> As we approach the topic of migration for Struts Action 1 applications
> to Struts Action 2, I want to find out what we should focus on first.
> You are able to run both frameworks side-by-side, but for the
> developers that want to migrate a Struts 1.x application to Action 2,
> what aspect of a Struts Action 1 application is the most important to
> support for migration?
>
> 1. ActionForms
> 2. Actions
> 3. Validator definitions
> 4. Message resources
> 5. Struts configuration files
> 6. HTML tag libraries
> 7. Other (please explain)
>
> Please let us know your thoughts so we can focus on developing tools
> to make migration as easy as possible. Thanks,
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Leon Rosenberg <ro...@googlemail.com>.
2.
1.
4.
5.
6.
3.
regards
leon
On 6/12/06, Don Brown <do...@gmail.com> wrote:
> As we approach the topic of migration for Struts Action 1 applications
> to Struts Action 2, I want to find out what we should focus on first.
> You are able to run both frameworks side-by-side, but for the
> developers that want to migrate a Struts 1.x application to Action 2,
> what aspect of a Struts Action 1 application is the most important to
> support for migration?
>
> 1. ActionForms
> 2. Actions
> 3. Validator definitions
> 4. Message resources
> 5. Struts configuration files
> 6. HTML tag libraries
> 7. Other (please explain)
>
> Please let us know your thoughts so we can focus on developing tools
> to make migration as easy as possible. Thanks,
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Dion Gillard <di...@gmail.com>.
On 6/13/06, Ted Husted <te...@gmail.com> wrote:
>
> On 6/12/06, Don Brown <do...@gmail.com> wrote:
> > Please let us know your thoughts so we can focus on developing tools
> > to make migration as easy as possible. Thanks,
>
> My first thought would be how would migrating one part without the
> others would serve any practical purpose?
>
> My second thought would be how often would production-applications
> actually be migrated?
>
> In the field, it seems like that once a Struts application hits
> production, it continues to use the same version. A new application
> might use 1.2, but the old ones continue to plug along on 1.1. If it
> ain't broke, why fix it?
Why support multiple versions of struts code bases in production when you
could use (and support) just one? I know we have apps that are in production
that have 'migrated' from 1.0 though 1.1 to 1.2. I'd rather not support both
sets for a large code base.
-Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris
Re: Poll: What part of a Struts will be the most important to
support for migration?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 5:18 PM -0400 6/12/06, Ted Husted wrote:
>In the field, it seems like that once a Struts application hits
>production, it continues to use the same version. A new application
>might use 1.2, but the old ones continue to plug along on 1.1. If it
>ain't broke, why fix it?
This is definitely not true in my shop. We usually find it very
constraining when going back to an older app and adding new features
if we can't bring the app up to "modern practices."
Our environment may be somewhat unusual, in that our sales people
often sell small enhancements to existing projects, and they often
sell "the same thing" we just implemented in a new app to a client
whose project is 3 years and two versions of Struts old.
Also, we find it pretty cumbersome to mentally switch between what
can and can't be done between different versions of apps (this isn't
only Struts changes, but also catching up with servlet, JSP, and JSTL
evolution.)
Joe
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Dakota Jack <da...@gmail.com>.
The issue was not using the same code base, not a better apple. The issue
was substituting a code base which was foreign to the very conceptual
foundation of Struts, substituting an orange for an apple. But, you
probably knew this.
Struts needs to do a major shift. I think "lip service" is not helpful. I
think that Struts should get uptown.
On 6/12/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> t to upgrade
> the underlying framework to take advantage of new features. If SAF2
> doesn't
> even pay lip service to a migration story (which'd be pretty ironic of the
> lambasting that Shale got over wanting the "Struts" brand :-), then you're
> not giving the existing users much incentive to migrate to SAF2 versus any
> other framework.
>
>
> Craig
>
>
> >
> > > In the field, it seems like that once a Struts application hits
> > > production, it continues to use the same version. A new application
> > > might use 1.2, but the old ones continue to plug along on 1.1. If it
> > > ain't broke, why fix it?
> > >
> > > -Ted.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Craig McClanahan <cr...@apache.org> wrote:
> There are also the cases where an existing app is going to be substantially
> re-implemented, and the natural question will be whether or not to upgrade
> the underlying framework to take advantage of new features. If SAF2 doesn't
> even pay lip service to a migration story (which'd be pretty ironic of the
> lambasting that Shale got over wanting the "Struts" brand :-), then you're
> not giving the existing users much incentive to migrate to SAF2 versus any
> other framework.
:) First, I'm -1 on paying only "lip service" to anything. :)
My own viewpoint is that it's easy for *developers* to migrate to
SAF2. Most of us humans have a much longer life cycle than any given
application, so I see job one as helping developers migrate our
existing skill set.
It's also my direct experience that it is easy to migrate an SAF1
applciation to SAF2 by direct substitution of this SAF1 member with
that SAF2 member. After I migrate another application or two, I could
see creating text-processing tools to help us do the same. (Not unlike
the tools people once wrote to convert HTML forms to SAF1 forms.)
I'm just asking if we're posing the right question. Do we want to
implement SAF1 members in SAF2 applications, or focus on mapping SAF1
members to SAF2 members?
There are some members and features we should bring forward, like
wildcards (already done). I think SAF2 DynaForms would be another
useful feature. But, my thought would be that the members we support
should be supported because they are generally useful, rather than
legacies.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Craig McClanahan <cr...@apache.org>.
On 6/12/06, Don Brown <do...@gmail.com> wrote:
>
> On 6/12/06, Ted Husted <te...@gmail.com> wrote:
> > On 6/12/06, Don Brown <do...@gmail.com> wrote:
> > > Please let us know your thoughts so we can focus on developing tools
> > > to make migration as easy as possible. Thanks,
> >
> > My first thought would be how would migrating one part without the
> > others would serve any practical purpose?
>
> In some cases, I think so. For example, it might be nice to reuse
> validator configurations or custom ActionForms. I'm thinking we could
> support either pretty easily. Struts Actions, on the other hand, are
> more difficult since they depend on ActionForms, but it could probably
> be done with a proxy Action and a bunch of parameters.
>
> > My second thought would be how often would production-applications
> > actually be migrated?
>
> That is a good question and one I'm trying to answer here as well. I
> want to make sure the time spent on migration tools will be productive
> and user's fears of being left behind are mitigated. Personally, I've
> migrated my current Struts application to Action 2, but plan to leave
> the rest alone because, right, if it isn't broken, why fix it.
There are also the cases where an existing app is going to be substantially
re-implemented, and the natural question will be whether or not to upgrade
the underlying framework to take advantage of new features. If SAF2 doesn't
even pay lip service to a migration story (which'd be pretty ironic of the
lambasting that Shale got over wanting the "Struts" brand :-), then you're
not giving the existing users much incentive to migrate to SAF2 versus any
other framework.
Don
Craig
>
> > In the field, it seems like that once a Struts application hits
> > production, it continues to use the same version. A new application
> > might use 1.2, but the old ones continue to plug along on 1.1. If it
> > ain't broke, why fix it?
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Don Brown <do...@gmail.com>.
On 6/12/06, Ted Husted <te...@gmail.com> wrote:
> On 6/12/06, Don Brown <do...@gmail.com> wrote:
> > Please let us know your thoughts so we can focus on developing tools
> > to make migration as easy as possible. Thanks,
>
> My first thought would be how would migrating one part without the
> others would serve any practical purpose?
In some cases, I think so. For example, it might be nice to reuse
validator configurations or custom ActionForms. I'm thinking we could
support either pretty easily. Struts Actions, on the other hand, are
more difficult since they depend on ActionForms, but it could probably
be done with a proxy Action and a bunch of parameters.
> My second thought would be how often would production-applications
> actually be migrated?
That is a good question and one I'm trying to answer here as well. I
want to make sure the time spent on migration tools will be productive
and user's fears of being left behind are mitigated. Personally, I've
migrated my current Struts application to Action 2, but plan to leave
the rest alone because, right, if it isn't broken, why fix it.
Don
>
> In the field, it seems like that once a Struts application hits
> production, it continues to use the same version. A new application
> might use 1.2, but the old ones continue to plug along on 1.1. If it
> ain't broke, why fix it?
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Ted Husted <te...@gmail.com>.
On 6/12/06, Don Brown <do...@gmail.com> wrote:
> Please let us know your thoughts so we can focus on developing tools
> to make migration as easy as possible. Thanks,
My first thought would be how would migrating one part without the
others would serve any practical purpose?
My second thought would be how often would production-applications
actually be migrated?
In the field, it seems like that once a Struts application hits
production, it continues to use the same version. A new application
might use 1.2, but the old ones continue to plug along on 1.1. If it
ain't broke, why fix it?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support for migration?
Posted by Don Brown <do...@gmail.com>.
Ok, good, that is what I am looking for: what part of your Struts app
would you want to not touch if you could help it in a migration?
I agree with Ted that migrating the best of Struts Action 1 is great,
but I think there is also a need to not require an application
migration to change everything all at once.
Any other opinions?
Don
On 6/12/06, netsql <ce...@gmail.com> wrote:
> How little do I have to change my JSP!
>
> .V
>
> > 6. HTML tag libraries
> > 7. Other (please explain)
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Poll: What part of a Struts will be the most important to support
for migration?
Posted by netsql <ce...@gmail.com>.
How little do I have to change my JSP!
.V
> 6. HTML tag libraries
> 7. Other (please explain)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org