On Tue, 23 Nov 2004 09:30:20 -0800, Martin Cooper wrote:
struts-chain is in struts/sandbox/trunk, yes, and it will likely be
moved into struts/core/trunk as part of Struts 1.3. However, since
we instituted a policy of not depending on any other components
that are unreleased, that's not going
Vic wrote:
I think Martin said chain is in trunk.
I would assume that the nighly bulids would then have chain in there,
and that it not be a separate download?
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
repost
I think Martin said chain is in trunk.
I would assume that the nighly bulids would then have chain in there,
and that it not be a separate download?
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
The Struts nightly build contains whatever the result of running ant
clean dist in the struts/core/trunk directory produces. Until now,
that hasn't included Struts Chain, but that's easy to fix.
In the mean time, there is a nightly build of Struts Chain being
produced separately:
I think Martin said chain is in trunk.
I would assume that the nighly bulids would then have chain in
there, and that it not be a separate download?
Chain is not yet in the core, but getting it there is something I'm
interested in working on. It may also be just as well to wait a few
days
On Tue, 23 Nov 2004 09:07:02 -0600, Vic Cekvenich [EMAIL PROTECTED] wrote:
Vic wrote:
I think Martin said chain is in trunk.
Huh? No, I don't think so...
struts-chain is in struts/sandbox/trunk, yes, and it will likely be
moved into struts/core/trunk as part of Struts 1.3. However, since we
Comments inline...
Joe Germuska wrote:
I think Martin said chain is in trunk.
I would assume that the nighly bulids would then have chain in
there, and that it not be a separate download?
Chain is not yet in the core, but getting it there is something I'm
interested in working on. It may also
On Tue, 23 Nov 2004 09:58:11 -0800, Don Brown [EMAIL PROTECTED] wrote:
Sounds good. I would take it a step further, and, if no init parameter,
look for the chain config as /chain-config.xml, making it possible to
provide an intelligent default. We could then, take your idea in #3,
and
The other question here is simply whether to change the behavior of
the class named RequestProcessor (probably copying the current
behavior to a LegacyRequestProcessor) or rather to change the
default class used to point to a new class which implements the
Chain-based processing.
I like for
