Re: forcing relative urls from struts instead of the absolute urls!
Max Cooper wrote: It sounds like your main challenge is that you have requests to a web server that look like http://web.domain.com/foo/bar/me mapped to an app deployed on an app server that you might access directly as http://app.domain.com/me. The app will make site-root relative URLs like /me/foo.html, and the browser will them make a request to the web server like http://web.domain.com/me/foo.html which is not what you want. That is correct. (I don't have the original message, so I answer to this one) I have similar problem like you. Applications are deployed as http://app1.domain.com/ and http://app2.domain.com/ for production use, and developers deploy them to local Tomcats as http://localhost:8080/app1/ and http://localhost:8080/app2/. I found the solution in html:rewrite tag, since it will convert the relative path in JSP to the absolute one. It also does the URL-rewriting, but I don't mind that. Did anyone else try this solution? Ognjen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forcing relative urls from struts instead of the absolute urls!
On Tue, 2006-01-03 at 16:51 -0500, Michael P. Soulier wrote: On 13/12/05 Max Cooper did say: It sounds like your main challenge is that you have requests to a web server that look like http://web.domain.com/foo/bar/me mapped to an app deployed on an app server that you might access directly as http://app.domain.com/me. The app will make site-root relative URLs like /me/foo.html, and the browser will them make a request to the web server like http://web.domain.com/me/foo.html which is not what you want. That is correct. What is stopping you from deploying the app with a /foo/bar/me context, so that it matches the public context on the web server? This is almost certainly the easiest solution if you can do it. In this case, http://web.domain.com/foo is a prefix for a lot of UI elements that are pluggable for separate applications. That would mean that if /foo became a web application in tomcat, it would be much more difficult for applications to plug-in to it. If each application delivered a .war file, as a separate web application, that would be far easier to maintain in the long run than requiring all developers to coexist in one large web app under tomcat. I am not following why you can't make the context path (whether it is a webapp or not) the same on your app server as it is on the web server, e.g. http://web.com/foo --proxy-- http://app.com/foo, rather that http://web.com/foo --proxy-- http://app.com/something/else. This really would solve all of your problems -- perhaps it is worth further consideration, even if you have to change some paths to make it work. Note that I think you can deploy completely separate webapps to the following seemingly-nested paths, if this is the problem: /foo /foo/bar /foo/bar/baz Or how about setup another virtual host on tomcat, with the app (or whatever it is) deployed with a context path that matches the path on the public web server. Alternately, perhaps there is some proxy configuration magic that would work. To be robust, you'd probably need to use a connector (e.g. mod_jk) rather than just using a dumb proxy to forward requests, because I think the app server really needs to know the desired context path in order to render the pages with the proper URLs. (The alternative of filtering the response stream after-the-fact in hopes of converting all URLs is a lousy design for many reasons and not an approach I would recommend.) I'm currently using ProxyPass in apache, but if this can be done with mod_jk, then I'll focus on that. Do you know it's possible with AJP? I was hoping that I would see config items to address this, but I didn't see any when reviewing the docs. I guess it doesn't do it, at least not alone. Maybe it could be combined with mod_rewrite in some novel way to solve this problem, but I don't know how to do it. I do like using mod_jk (and similar for components other app servers) since they handle things (e.g. redirect URLs) that can be a pain to setup in a proxy and/or pain to work around with app code. Basically, they give you a solid base to build on, without a bunch of surprising proxy-related gotchas to work around in the app code. Be a little more specific about your situation -- I think that might help someone recognize a problem they had and offer you a solution. You can obviously obscure the particulars while still communicating the structure of your problem in sufficient detail. So far, I don't really get what your situation is beyond path on web server doesn't match context path on app server. -Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forcing relative urls from struts instead of the absolute urls!
On 13/12/05 Max Cooper did say: It sounds like your main challenge is that you have requests to a web server that look like http://web.domain.com/foo/bar/me mapped to an app deployed on an app server that you might access directly as http://app.domain.com/me. The app will make site-root relative URLs like /me/foo.html, and the browser will them make a request to the web server like http://web.domain.com/me/foo.html which is not what you want. That is correct. What is stopping you from deploying the app with a /foo/bar/me context, so that it matches the public context on the web server? This is almost certainly the easiest solution if you can do it. In this case, http://web.domain.com/foo is a prefix for a lot of UI elements that are pluggable for separate applications. That would mean that if /foo became a web application in tomcat, it would be much more difficult for applications to plug-in to it. If each application delivered a .war file, as a separate web application, that would be far easier to maintain in the long run than requiring all developers to coexist in one large web app under tomcat. Alternately, perhaps there is some proxy configuration magic that would work. To be robust, you'd probably need to use a connector (e.g. mod_jk) rather than just using a dumb proxy to forward requests, because I think the app server really needs to know the desired context path in order to render the pages with the proper URLs. (The alternative of filtering the response stream after-the-fact in hopes of converting all URLs is a lousy design for many reasons and not an approach I would recommend.) I'm currently using ProxyPass in apache, but if this can be done with mod_jk, then I'll focus on that. Do you know it's possible with AJP? Using context-relative references is really useful. Actions have the same name (path) no matter what page you are working on. Images are always /img/... (or whatever) without having to think twice what the request URL was that caused the JSP you are editing to execute (note that the request may not match the JSP file path). And you can choose (and change) the context path at deployment time without breaking anything. However, if you are dead set on using strictly relative references, you may still be able to get it to work. I am pretty sure I have seen html:form action=relative.do work, for instance. Why don't you post a specific example of something that isn't working for you. I tried that, but I couldn't get the existing web application to load once I'd made those changes. Perhaps I did it wrong. Mike -- Michael P. Soulier [EMAIL PROTECTED], 613-592-2122 x2522 Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forcing relative urls from struts instead of the absolute urls!
Note that Struts isn't writing absolute URLs. As a webapp developer, you use context-relative references that Struts turns into site-root relative URLs. Here are examples of each type of reference, just so we are all on the same page: Relative: foo.html Site-root relative: /myapp/foo.html (And the special case of context-relative /foo.html inside an app, which then becomes /myapp/foo.html if you deploy this app with a /myapp context path.) Absolute: http://server.com/bar.html It sounds like your main challenge is that you have requests to a web server that look like http://web.domain.com/foo/bar/me mapped to an app deployed on an app server that you might access directly as http://app.domain.com/me. The app will make site-root relative URLs like /me/foo.html, and the browser will them make a request to the web server like http://web.domain.com/me/foo.html which is not what you want. What is stopping you from deploying the app with a /foo/bar/me context, so that it matches the public context on the web server? This is almost certainly the easiest solution if you can do it. Alternately, perhaps there is some proxy configuration magic that would work. To be robust, you'd probably need to use a connector (e.g. mod_jk) rather than just using a dumb proxy to forward requests, because I think the app server really needs to know the desired context path in order to render the pages with the proper URLs. (The alternative of filtering the response stream after-the-fact in hopes of converting all URLs is a lousy design for many reasons and not an approach I would recommend.) Using context-relative references is really useful. Actions have the same name (path) no matter what page you are working on. Images are always /img/... (or whatever) without having to think twice what the request URL was that caused the JSP you are editing to execute (note that the request may not match the JSP file path). And you can choose (and change) the context path at deployment time without breaking anything. However, if you are dead set on using strictly relative references, you may still be able to get it to work. I am pretty sure I have seen html:form action=relative.do work, for instance. Why don't you post a specific example of something that isn't working for you. -Max On Mon, 2005-12-12 at 13:52 -0500, Michael P. Soulier wrote: Laurie Harper wrote: Because if they were relative Struts would have no way to know what they were relative *to*? But why does it need to know? I have links in sites that I look after like foo/bar/bash.html If I access this via http://mybox.com/, then the browser does the right thing. If it's accessed via http://otherbox.com/, then it still does the right thing. That's why relative links are always recommended. Why does Struts need to know? This seems like another case of a shortsighted framework to me, complicating something that would be dead simple if we were simply generating our own html. Maybe inputPattern and/or pagePattern are what you're looking for? http://struts.apache.org/struts-doc-1.2.7/userGuide/configuration.html#controller_config Maybe. I'll look at this, and thank you. Please pardon my exasperation. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: forcing relative urls from struts instead of the absolute urls!
Laurie Harper wrote: Because if they were relative Struts would have no way to know what they were relative *to*? But why does it need to know? I have links in sites that I look after like foo/bar/bash.html If I access this via http://mybox.com/, then the browser does the right thing. If it's accessed via http://otherbox.com/, then it still does the right thing. That's why relative links are always recommended. Why does Struts need to know? This seems like another case of a shortsighted framework to me, complicating something that would be dead simple if we were simply generating our own html. Maybe inputPattern and/or pagePattern are what you're looking for? http://struts.apache.org/struts-doc-1.2.7/userGuide/configuration.html#controller_config Maybe. I'll look at this, and thank you. Please pardon my exasperation. Mike -- Michael P. Soulier [EMAIL PROTECTED], 613-592-2122 x2522 Linux applications development ...the word HACK is used as a verb to indicate a massive amount of nerd-like effort. -Harley Hahn, A Student's Guide to Unix smime.p7s Description: S/MIME Cryptographic Signature
Re: forcing relative urls from struts instead of the absolute urls!
Michael Jouravlev wrote: Links to what? To action or to JSP page? A form action, primarily. I don't think that references below answer your question, but they contain valuable info anyway: No, I'm afraid that they don't. I don't need a tag lib to put a base tag in the html, but that won't fix the problem that struts, for some inane reason, _requires_ absolute URLs in its config! Why why why?? Mike -- Michael P. Soulier [EMAIL PROTECTED], 613-592-2122 x2522 Linux applications development ...the word HACK is used as a verb to indicate a massive amount of nerd-like effort. -Harley Hahn, A Student's Guide to Unix smime.p7s Description: S/MIME Cryptographic Signature
Re: forcing relative urls from struts instead of the absolute urls!
Michael P. Soulier wrote: Michael Jouravlev wrote: Links to what? To action or to JSP page? A form action, primarily. I don't think that references below answer your question, but they contain valuable info anyway: No, I'm afraid that they don't. I don't need a tag lib to put a base tag in the html, but that won't fix the problem that struts, for some inane reason, _requires_ absolute URLs in its config! Why why why?? Because if they were relative Struts would have no way to know what they were relative *to*? Maybe inputPattern and/or pagePattern are what you're looking for? http://struts.apache.org/struts-doc-1.2.7/userGuide/configuration.html#controller_config L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
