Re: Going to other context and/or server in 1.1
Naw, that's just another person saying they have the same problem, I think. I didn't see a patch in the attachment - but the question remains if this is something we want to allow. Personally, I think we should. If so, I'll see about getting it fixed-up. That is the bug I was looking at though, yes. There have been others wanting this ability too. One thought that comes to mind is to check the path specified to see if it starts out http://...; - and just treat that differently. That would be easy enough for users to do, and I don't think it would require too significant of a change to implement. This is one time I think startsWith criteria would suffice ;-) but I'm open to suggestions. David Graham wrote: Are you referring to this bug? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13721 Looks like someone has submitted a patch. Dave -- 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
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. David From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Going to other context and/or server in 1.1 Date: Fri, 18 Oct 2002 10:26:31 -0500 Naw, that's just another person saying they have the same problem, I think. I didn't see a patch in the attachment - but the question remains if this is something we want to allow. Personally, I think we should. If so, I'll see about getting it fixed-up. That is the bug I was looking at though, yes. There have been others wanting this ability too. One thought that comes to mind is to check the path specified to see if it starts out http://...; - and just treat that differently. That would be easy enough for users to do, and I don't think it would require too significant of a change to implement. This is one time I think startsWith criteria would suffice ;-) but I'm open to suggestions. David Graham wrote: Are you referring to this bug? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13721 Looks like someone has submitted a patch. Dave -- 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 _ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
David Graham wrote: 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. I don't like that idea either, but I can't think of a better approach. As I said, I'm open to suggestions :-) You could look for /word.word.word/, but I think that would be ... just as bad and a lot nastier to implement. Very problematic, I would think. Looking for http: seems the best solution that I can think of. David -- 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
RE: Going to other context and/or server in 1.1
I would have thought the same would apply for any specified protocol scheme. For example someone may wish to redirect to an ftp:// through the action forward, or maybe news:// - who knows. Without a protocol specification of any description it's probably safe to assume we want context relative. Having said that, I don't know enough to spot any possible caveats. -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: 18 October 2002 16:29 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. David From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Going to other context and/or server in 1.1 Date: Fri, 18 Oct 2002 10:26:31 -0500 Naw, that's just another person saying they have the same problem, I think. I didn't see a patch in the attachment - but the question remains if this is something we want to allow. Personally, I think we should. If so, I'll see about getting it fixed-up. That is the bug I was looking at though, yes. There have been others wanting this ability too. One thought that comes to mind is to check the path specified to see if it starts out http://...; - and just treat that differently. That would be easy enough for users to do, and I don't think it would require too significant of a change to implement. This is one time I think startsWith criteria would suffice ;-) but I'm open to suggestions. David Graham wrote: Are you referring to this bug? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13721 Looks like someone has submitted a patch. Dave -- 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 _ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
Well, we could implement a static array of protocols somewhere - and iterate over them to see if there's a match (like was being done with module prefixes before). Then, adding support for another protocol would just be a matter of editing that one array. Should this go in Globals? You've got a good point, Cliff. Cliff Rowley wrote: I would have thought the same would apply for any specified protocol scheme. For example someone may wish to redirect to an ftp:// through the action forward, or maybe news:// - who knows. Without a protocol specification of any description it's probably safe to assume we want context relative. Having said that, I don't know enough to spot any possible caveats. -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: 18 October 2002 16:29 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. David -- 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
RE: Going to other context and/or server in 1.1
Shouldn't you look for https: as well as a possible likely request? I've seen several occurances where a special domain is setup for secure stuff - e.g. www.mydomain.com - shop.mydomain.com which switches to https: in the process. Also, ftp:// would defeinitely need to be in there. chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: 18 October 2002 16:37 To: Struts Developers List Subject: Re: Going to other context and/or server in 1.1 David Graham wrote: 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. I don't like that idea either, but I can't think of a better approach. As I said, I'm open to suggestions :-) You could look for /word.word.word/, but I think that would be ... just as bad and a lot nastier to implement. Very problematic, I would think. Looking for http: seems the best solution that I can think of. David -- 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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Going to other context and/or server in 1.1
What if we looked for :// instead of specific protocols? We could also add an attribute like contextRelative=false. David From: Chanoch [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Going to other context and/or server in 1.1 Date: Fri, 18 Oct 2002 16:53:37 +0100 Shouldn't you look for https: as well as a possible likely request? I've seen several occurances where a special domain is setup for secure stuff - e.g. www.mydomain.com - shop.mydomain.com which switches to https: in the process. Also, ftp:// would defeinitely need to be in there. chanoch - The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Although we routinely screen for viruses, recipients should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments. -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: 18 October 2002 16:37 To: Struts Developers List Subject: Re: Going to other context and/or server in 1.1 David Graham wrote: 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. I don't like that idea either, but I can't think of a better approach. As I said, I'm open to suggestions :-) You could look for /word.word.word/, but I think that would be ... just as bad and a lot nastier to implement. Very problematic, I would think. Looking for http: seems the best solution that I can think of. David -- 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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
At the risk of entertaining the masses, I think I'll comment that I like that idea. I'll try to get a fix in by this evening. If someone thinks that is bad, speak now or forever hold your peas! David Graham wrote: What if we looked for :// instead of specific protocols? We could also add an attribute like contextRelative=false. David -- 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
Re: Going to other context and/or server in 1.1
If we are talking about the internal forward= form of the ActionMapping, then I would say that perhaps we should restrict this to the same context/module, and suggest that ActionForwards be used to go outside the application context. I believe this hehavior also applies to 1.0.x. If we are talking about ActionForwards, then it sounds like something is broken. Is there not an contextRelative property that one can set to get to prevent the path from being munged? -Ted. 10/18/2002 12:10:02 PM, Eddie Bush [EMAIL PROTECTED] wrote: At the risk of entertaining the masses, I think I'll comment that I like that idea. I'll try to get a fix in by this evening. If someone thinks that is bad, speak now or forever hold your peas! David Graham wrote: What if we looked for :// instead of specific protocols? We could also add an attribute like contextRelative=false. David -- 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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Going to other context and/or server in 1.1
On Fri, 18 Oct 2002, Cliff Rowley wrote: While I think about it, it may also be desirable in some situations to keep the session information, even when redirecting to another scheme. IMHO, passing the session identifier to something that is not a URL into the same webapp is a security vulnerability. Struts should never do this -- although applications may (of course) implement their own schemes for establishing shared state, and such techniques may or may not be based on the servlet API's session id. Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Going to other context and/or server in 1.1
IMHO, passing the session identifier to something that is not a URL into the same webapp is a security vulnerability. Struts should never do this -- although applications may (of course) implement their own schemes for establishing shared state, and such techniques may or may not be based on the servlet API's session id. I wish I could remember the exact context in which this was used - but I do recall it was a requirement at the time. Possibly a Transact limitation. We're going back a year or two though. I agree after more thought, however, that it would not be the responsibility of Struts to implement this (after all, a response.redirect() would achieve the same thing). --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
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
RE: Going to other context and/or server in 1.1
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- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
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
Re: Going to other context and/or server in 1.1
I guess I'm still missing the point here. If contextRelative=true, are we not reverting to the Struts 1.0.x behavior? If we didn't need an absolute property in Struts 1.0.x, why do we need one now? -Ted. 10/18/2002 1:32:58 PM, Eddie Bush [EMAIL PROTECTED] wrote: +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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
Maybe I'm being thick-headed here, but I cannot succeed in formulating anything that lets me go to, say http://www.yahoo.com by way of an action. My testing has centered primarily around use of ForwardAction. Ted Husted wrote: I guess I'm still missing the point here. If contextRelative=true, are we not reverting to the Struts 1.0.x behavior? If we didn't need an absolute property in Struts 1.0.x, why do we need one now? -Ted. -- 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
Re: Going to other context and/or server in 1.1
Or - ... contextRelative is new to 1.1 (obviously). What if we replaced it with relativeTo. relativeTo could take on the values: application/module/absolute Then we're not just growing warts on the side for effect. Craig R. McClanahan wrote: 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
[BRANCH] RE: Going to other context and/or server in 1.1
While this discussion is going on regarding 'relativity', I'd like to note that bug #12600 reports a problem with the form tag that seems related: Basically form action=login.do always prepends the module context, making it impossible to specify a true relative link (like login.do rather than /app/login.do or /app/module/login.do) which is sometimes desirable. Is it a bug or feature? I'm forced by my architecture to always specify relative links back to the browser, so I can't use the form tag as is. The bug description discusses the type of situation where this may arise... Any thoughts? -JT -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Friday, October 18, 2002 1:12 PM To: Struts Developers List Subject: Re: Going to other context and/or server in 1.1 Or - ... contextRelative is new to 1.1 (obviously). What if we replaced it with relativeTo. relativeTo could take on the values: application/module/absolute Then we're not just growing warts on the side for effect. Craig R. McClanahan wrote: 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
Re: Going to other context and/or server in 1.1
Yep - that's the ticket alright. I guess I still don't fully understand the innards. I thought (after actually having examined the code) I had a pretty bulletproof understanding. Looks like you just shot holes all in it. APDS? I guess I was focusing on the wrong thing. This is not a requirement of mine - nor have I had it arise. I've seen a couple of inquiries though, and I think people were tending toward the way I was trying to do it. I'll keep my eyes peeled 8-O for anyone else having this miconception. ForwardAction actually does return an ActionForward now. It could be made contextRealtive very easily. Ted Husted wrote: Try using a SuccessAction that returns a real live ActionForward return findForward(success); with something like this forward name=success path=http://jakarta.apache.org; contextRelative=true/ and see if that gets you out. The internal forward= action is already module/context relative. In 1.0, I had been using forward= inside the application and ForwardAction to get out. Maybe ForwardAction should always be contextRelative, since it's stated purpose is to let us interact with other servlets, which implies it shouldn't understand modules at all. I think there's another ticket in there about ForwardAction bypassing the RequestProcessor. May be it needs to create an ActionForward on the fly and set it to contextRelative=true, and then just return that. I think a lot of people may be using ForwardAction when the ActionMapping.forward would be better suited, and maybe we need to clarify the difference. I think ForwardAction is for hooking up with other servlets, applications, or domains, and ActionMapping.forward is for hooking up with other Struts resources in the same module, like JSPs. -Ted. -- 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
RE: [BRANCH] RE: Going to other context and/or server in 1.1
On my current project, we've dealt with this situation (form tags with context relative actions) by defining another action using the same classes, i.e. now we have two actions in different modules defined using the same Action class, Form class, etc. Then you can still use the Struts form tag. While this at first may seem ugly, it is part of the power of Struts to be able to define new actions without writing any new code, and consistent with the philosophy of modules being independent. That said, for other tag situations where it's nice to share, like html:link, html:image, and html:img, we extended those tags to add a contextRelative attribute. Steve -Original Message- From: Taylor, Jason [mailto:jtaylor;cobaltgroup.com] Sent: Friday, October 18, 2002 1:44 PM To: 'Struts Developers List' Subject: [BRANCH] RE: Going to other context and/or server in 1.1 While this discussion is going on regarding 'relativity', I'd like to note that bug #12600 reports a problem with the form tag that seems related: Basically form action=login.do always prepends the module context, making it impossible to specify a true relative link (like login.do rather than /app/login.do or /app/module/login.do) which is sometimes desirable. Is it a bug or feature? I'm forced by my architecture to always specify relative links back to the browser, so I can't use the form tag as is. The bug description discusses the type of situation where this may arise... Any thoughts? -JT -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Friday, October 18, 2002 1:12 PM To: Struts Developers List Subject: Re: Going to other context and/or server in 1.1 Or - ... contextRelative is new to 1.1 (obviously). What if we replaced it with relativeTo. relativeTo could take on the values: application/module/absolute Then we're not just growing warts on the side for effect. Craig R. McClanahan wrote: 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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Going to other context and/or server in 1.1
The JavaDocs say context-relative, so I would say we should make that there ActionForward context-relative. Otherwise, how could it be used to interact with another servlet? Ditto for IncludeAction. We might also document that To forward to a module-relative resource, the ActionMapping.forward property can be used in lieu of an Action. Ditto for include. Thanks for catching this Eddie! -Ted. 10/18/2002 5:32:29 PM, Eddie Bush [EMAIL PROTECTED] wrote: Yep - that's the ticket alright. I guess I still don't fully understand the innards. I thought (after actually having examined the code) I had a pretty bulletproof understanding. Looks like you just shot holes all in it. APDS? I guess I was focusing on the wrong thing. This is not a requirement of mine - nor have I had it arise. I've seen a couple of inquiries though, and I think people were tending toward the way I was trying to do it. I'll keep my eyes peeled 8-O for anyone else having this miconception. ForwardAction actually does return an ActionForward now. It could be made contextRealtive very easily. Ted Husted wrote: Try using a SuccessAction that returns a real live ActionForward return findForward(success); with something like this forward name=success path=http://jakarta.apache.org; contextRelative=true/ and see if that gets you out. The internal forward= action is already module/context relative. In 1.0, I had been using forward= inside the application and ForwardAction to get out. Maybe ForwardAction should always be contextRelative, since it's stated purpose is to let us interact with other servlets, which implies it shouldn't understand modules at all. I think there's another ticket in there about ForwardAction bypassing the RequestProcessor. May be it needs to create an ActionForward on the fly and set it to contextRelative=true, and then just return that. I think a lot of people may be using ForwardAction when the ActionMapping.forward would be better suited, and maybe we need to clarify the difference. I think ForwardAction is for hooking up with other servlets, applications, or domains, and ActionMapping.forward is for hooking up with other Struts resources in the same module, like JSPs. -Ted. -- 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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [BRANCH] RE: Going to other context and/or server in 1.1
This behavior is consistent with Struts 1.0. It always prepended the application context, and now it always prepends the application/context. Since actions are not physical files, and we spend a lot of time forwading from here to there, trying to use relative references is not really recommended. -Ted. 10/18/2002 4:44:01 PM, Taylor, Jason [EMAIL PROTECTED] wrote: While this discussion is going on regarding 'relativity', I'd like to note that bug #12600 reports a problem with the form tag that seems related: Basically form action=login.do always prepends the module context, making it impossible to specify a true relative link (like login.do rather than /app/login.do or /app/module/login.do) which is sometimes desirable. Is it a bug or feature? I'm forced by my architecture to always specify relative links back to the browser, so I can't use the form tag as is. The bug description discusses the type of situation where this may arise... Any thoughts? -JT -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Friday, October 18, 2002 1:12 PM To: Struts Developers List Subject: Re: Going to other context and/or server in 1.1 Or - ... contextRelative is new to 1.1 (obviously). What if we replaced it with relativeTo. relativeTo could take on the values: application/module/absolute Then we're not just growing warts on the side for effect. Craig R. McClanahan wrote: 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 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
