Re: forcing relative urls from struts instead of the absolute urls!

["Michael P. Soulier" <mi...@mitel.com>]

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 <mi...@mitel.com>, 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: forcing relative urls from struts instead of the absolute urls!

[Ognjen Blagojevic <og...@etf.bg.ac.yu>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: forcing relative urls from struts instead of the absolute urls!

[Max Cooper <ma...@maxcooper.com>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org