Well, someone's opinion counts - and you're someone. I beg to differ ;-)

The question is though: <cringe/> How would I implement such a change? I'd have to change:

- the DTD
- the ActionConfig/ForwardConfig classes
- refactor all places requests are finally redirected/forwarded

Missing anything? I have *no* clue about the DTD - but I'm willing to learn ...

Cliff Rowley wrote:

Agreed, it would be the most flexible solution overall - allowing the
developer to programatically choose whether it's on or off.

Not that my opinion really counts :)

-----Original Message-----
From: Eddie Bush [mailto:ekbush@;swbell.net] Sent: 18 October 2002 18:33
To: Struts Developers List
Subject: Re: Going to other context and/or server in 1.1

+1 - that would simplify things a great deal.

My idea was to have a static protocol list we'd iterate over - but I like yours much better.

Craig R. McClanahan wrote:

On Fri, 18 Oct 2002, David Graham wrote:

Date: Fri, 18 Oct 2002 09:29:04 -0600
From: David Graham <[EMAIL PROTECTED]>
Reply-To: Struts Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Going to other context and/or server in 1.1

I thought of the http:// matching as well. Are there any
cases when
this logic wouldn't work? Hardcoding the protocol may be a
bad idea.

Failure case: https://www.mysecuresite.com

Maybe we need an "absolute" attribute on ForwardConfig (and
therefore
ActinForward)?

--
Eddie Bush




--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to