JSP page is "trashed" if Tomcat port is changed from 80.

[Al Koch]

Hello,

I have a servlet that uses three JSP pages. I am using Eclipse Indigo and running the Tomcat v5.5 server on localhost, port 80 and the app runs just fine. The app starts up with a login page (JSP page 1). The user credentials are authenticated and then JSP page 2 is displayed. The user clicks on a list item on this page to make a selection and JSP page 3 is "loaded" with the associated bean data and displayed. When running under port 80 there is no problem.

However, if I change the Tomcat port this breaks the app in a bizarre way. If I change Tomcat's port to, say, 25000, then JSP page 1 displays fine and we see JSP page 2. The user clicks to make a selection and again the associated bean data is used to "load" JSP page 3 and it is displayed. However, this time, the HTML [head] (can't use angle brackets in the post!) block that is delivered to the browser is the [head] block of JSP page ***2***. Further, the HTML [body] block that is delivered to the browser consists of the contents of the [body] block of JSP page ***2***, followed by the correct contents of the [body] block of JSP page 3! That is, the page that is "generated" out Tomcat is the [head] block from page 2 and a combination of the [body] block of page 2 and 3.

The [head] in JSP page 2 has four [script src=...] items that load four sets of JavaScript from the local server. One is a custom script, one is the Modernizr package and the last two are jQuery and jQuery Mobile. I have discovered that if I remove jQuery Mobile the problem goes away.

In summary, if I run Tomcat on port 80 I can include jQuery in JSP page 2 and there is no problem. If I change Tomcat's port to something other than 80, the inclusion of jQuery Mobile in JSP page 2 causes JSP page 3 to be trashed. At this point I don't think that jQuery Mobile itself could be the real problem - how could it cause JSP page 3 to include page 2? However, the Tomcat JSP processing facility is parsing, patching and generating these pages that are sent to the browser so it seems more likely that the problem lies there. But I have no clue as to why changing the Tomcat port # would affect JSP processing.

Is there something else I must change other than the port # on the Eclipse Tomcat v5.5 Server pane to ensure that JSP processing keeps working? Anyone who can explain what in the world is going on here really knows their stuff!!!

Thank you.

[Bear Bibeault]

What do your resource URLs look like? If they're not server-relative, then they're likely to all expect port 80.

[Al Koch]

Hi Bear,

Thanks for the super fast response.

Here is the jQuery Mobile reference (angle changed to square brackets):
[script src="${pageContext.request.contextPath}/<jsp:getProperty property="sPathJSGeneric" name="BeanPage2"/>/jquery-1.6.4.min.js" async][/script]

I've looked at the value of ${pageContext.request.contextPath}/<jsp:getProperty property="sPathJSGeneric" name="BeanPage2"/> and it resolves to "MyServer/Resources/Scripts" which works just fine with Port 80. Since the Port # appears "upstreeam" from this string, how would Port # be involved?

Does that give you a clue?

Thanks.

[William P O'Sullivan]

MyServer/Resources/Scripts defaults to port 80

It has to be: MyServer:MyPort/Resources/Scripts if you change port from 80

e.g: MyServer:25000/Resources/Scripts

You pages are trashed because your scripts/css etc.. are not getting loaded.

WP

[Bear Bibeault]

William P O'Sullivan wrote:MyServer/Resources/Scripts defaults to port 80

It has to be: MyServer:MyPort/Resources/Scripts if you change port from 80

No it does not. If the URL is server relative, it will use the same port as the page.

If what you said was true, we'd need to add 8080 to all pages when running under Tomcat and clearly we do not.

[Bear Bibeault]

Al, the server-side markup i much less interesting than the client-side results. What do the URLs look like when they hit the browser.

[William P O'Sullivan]

The URL is server relative when not built "on the fly", which is what he is attempting to do.

WP

[Bear Bibeault]

William P O'Sullivan wrote:The URL is server relative when not built "on the fly", which is what he is attempting to do.

Not sure what you mean by this. Whether the URL is built on-the-fly or not is moot. All that matters what it looks like in the resulting HTML that's delivered to the browser. Whether it's hard-coded or "built" is irrelevant.

That's why we need to see what the browser sees.

Al, one other thing: you're obviously using the EL on your pages, what's with the ancient <jsp:getProperty> action? Use the EL.

[Bear Bibeault]

One other diagnostic tip: run the page in Chrome or Safari with the built-in debugger deployed. The Network tab will show what loads and what doesn't.

[William P O'Sullivan]

"/Resources/Scripts" would be relative to the current server:port

"MyServer/Resources/Scripts" is going to default to port 80 where MyServer is an IP or DNS name

Bear is right, Turn on FireBug and you will see what is going on.

WP

[Bear Bibeault]

William P O'Sullivan wrote:"/Resources/Scripts" would be relative to the current server:port

"MyServer/Resources/Scripts" is going to default to port 80 where MyServer is an IP or DNS name

That we can agree on. The latter, that includes the host is not a server-relative URL and shouldn't be used when referencing resources in the same web application.

[Bear Bibeault]

William P O'Sullivan wrote:Bear is right, Turn on FireBug and you will see what is going on.

Firebug is OK as far as it goes. I used to do most of my client-side debugging in Firefox because of it.

It's not aging well however. The builtin WebKit debugger in Chrome and Safari is much more modern and has a lot of nice facilities that Firebug lacks.

[Al Koch]

Hi William and Bear,

Thanks for the responses. I'm going to learn something from all of this!

Bear, if I understood your request, here is the URL on JSP Page 2 (this page appears to be assembled just fine) that I click on to the launch JSP Page 3 (that is trashed):

href="http://localhost:9476/MyServer/doit?Arg1=2e6032f18edbcca50331e3d57d030e375b5d7d08&Arg2=0000104923986216B7". I see that it includes the correct port #. Is this the client side URL you wanted? I am running Firebug so I can fetch other info - just not sure what that might be.

Also, Bear, once this problem is (hopefully) diagnosed, I'd like to follow up with you about your preference for the Chrome debugger and your question about the "jsp parameter" syntax.

Thanks again to both of you for your help.

Al.

[Bear Bibeault]

Is the resource on the same server? In the same web app? If so, then again, no host in the URL! The "href="http://localhost:9476/" is extraneous and even when it might sometimes work, a problem waiting to happen.

Again: server-relative URLS! These start with the context path and nothing else.

[Al Koch]

Hi Bear,

I think I may have given you a URL different than what you were asking for. On JSP Page 2, I construct a list. Each item in the list is a request to see JSP Page 3 loaded with certain data. An example of an item in the list is the URL I gave you, e.g., href="http://localhost:9476/MyServer/doit?Arg1=2e6032f18edbcca50331e3d57d030e375b5d7d08&Arg2=0000104923986216B7". In this URL Arg1 is a request to see JSP Page 3 and Arg2 is info used to populate JSP Page 3. I have to have a full URL (including the host and port) for the browser to communicate to the servlet so I suspect that this is not the "resource" URL you were asking about.

It turns out that I DID have some resources that were being fetched with the "full" URL you cautioned against. (I thought that just about a week ago I had been told by somebody in another post that I was supposed to do exactly this, but I guess misunderstood!) In any case, I have removed all references to the host in all URLs related to fetching resources. E.G., src="Resources/Scripts/MyScript.js" is now what I am using. I was excited because I was sure that was going to be the problem. But I have audited all of the JSP and ensured that all resource URLs look like the example but I still have the same problem with JSP Page 3. I have cleaned the Tomcat Working Directory and flushed the Firefox cache and still have the problem. So, I've learned something useful about the form of resource URLs but I still have a fatal problem.

What would you suggest now?

Thanks again for the help.

[Bear Bibeault]

Al Koch wrote:I have to have a full URL (including the host and port) for the browser to communicate to the servlet

Why?

was supposed to do exactly this, but I guess misunderstood!) In any case, I have removed all references to the host in all URLs related to fetching resources. E.G., src="Resources/Scripts/MyScript.js"

That is a page-relative URL. You are setting yourself up for heartbreak and despair. Server-relative URLs. Server-relative URLs. Server-relative URLs. I can't say it enough times. Server-relative URLs.

Have you checked the resource loading in the debugger as suggested?

[Al Koch]

Hi Bear,

I am truly hearing you say "server relative" but I obviously am not understanding what you mean. Please bear with me since there is something very fundamental that I am confused about.

1) Your question about why I think I need a "full" URL for the browser to be able to request a new page has me very confused. We start out and the browser clearly needs a full URL (host, port and server name) to establish contact with the server. If a link on that 1st page needs to request that the servlet load up and return a JSP the URL has to include two params; one to indicate the specific JSP and the other to indicate what particular data is to be used to populate the JSP. If a "full" URL (host & port,etc.) is not needed, can you give me an example of what that URL can (must?) look like? Even if a full URL is not needed am I creating a problem by using one since that is one this server app has always done?

2) I guess I don't know what you are actually saying when you use the phrase "Server relative URL" (vs. "page relative URL"). From my perspective, there are two "types" of URLs that are at play here. One is the type I just described in the above item; a URL that requests that the servlet construct a new page. The other "type" is a URL that the browser receives as part of that constructed page that triggers a request back to the server for what I've been calling "resources" such as images, CSS and scripts. Those are the URLs I thought your prior response was saying were supposed to *NOT* include the host,port and servlet name. But you've just described those as "page relative URLs" and I get the impression it was wrong for me to remove the "host,..." from the URL. Please explain what I am missing here.

3) I am running the Firebug debugger but I guess I don't specifically understand what you mean when you ask if I've checked "the resource loading".

I apologize for such confusion but there is something in our dialog that has me running in circles. I really appreciate the time you are taking with this.

Thanks, Al.

[Bear Bibeault]

A server relative URL is one that begins with the context path. It is valid no matter what the page URL is, unlike page relative URLs which are fragile and will break easily.

I know you know how to create one because in an earlier post you used ${pageContext.request.contextPath} to fetch the context path.

For example: <img src="${pageContext.request.contextPath}/images/x.jpg"> where images is a folder at the root of the web context.

There should be no domains in URLs that reference resources in the same web app.

And that includes servlet references. For example: <form action="${pageContext.request.contextPath}/some-servlet" method="post">

Using any other type of URL is almost guaranteed to cause problems, if not today, then tomorrow. It's highly likely that your problems may be related to this but we won't know until you've fixed all the URLs and seeing if the problem is resolved.

[Al Koch]

Hi Bear,

Thank you again for your response. Here is what I think you said:

1) The URL for a resource "embedded" in a page such as an image, script or CSS *SHOULD* start with the page context. I have changed all of this type of resources to look like:
<script src="${pageContext.request.contextPath}/${BeanProcessPage.sPathJSGeneric}/Modernizr-2.5.3.js" async></script>

This resolves in the browser to a form like:
<script async="" src="/MyServer/Resources/Scripts/Modernizr-2.5.3.js"></script>

Is this a correct understanding of how "embedded" resources should be written so as work in any deployment?


2) I have rewritten all of the "page request" URLs to look like (this is loaded in a bean and fetched in the JSP):
request.getContextPath()+"/doit?Arg=..."

This resolves in the browser to a form like:
href="/MyServer/doit?Arg=f69037c7ed9610175feefb805d41fcebb356e2e9"

Is this a correct understanding of how page request resources should be written so as work in any deployment?

*IF* I have gotten these both correct then the good news is that I may finally have this straight. The bad news is that making these changes throughout all of the code has not changed the problem. The browser still ends up with a JSP page 3 that is a "combo" of page 2 and 3.

If I have the form of URLs correct what can you suggest we look at next?

As always, your help is very much appreciated.

Al.

[Bear Bibeault]

Al Koch wrote:Is this a correct understanding of how "embedded" resources should be written so as work in any deployment?

Yes, except that it's called the context path not "page context".

Is this a correct understanding of how page request resources should be written so as work in any deployment?

Yes. Essentially everything that's going to be referenced from the browser (scripts, servlets, images, stylesheets, et al) that are part of the same web application should use server-relative addressing. This causes the protocol, domain, and port to all stay the same without having to explicitly state them every time, and makes the web app portable to any server using any context path.

If I have the form of URLs correct what can you suggest we look at next?

Even if that all want the problem, it was a a problem waiting to happen. Now that's behind us.

Next is to inspect what's happening when the "bad" page is loading in the browser's debugger. Have you done that?

[Al Koch]

Hi Bear - thanks for the weekend assistance!

It was from looking at Page 3 in Firebug that I discovered that it was comprised of Page 2's header and a combo of page 2 and 3's bodys. I've scanned the various tabs and nothing jumps out at me as to the cause. In fact, it seems that at this point the "damage has been done" back in Tomcat in the generation of the page, so I guess I need some help in knowing what to be looking for.

Thanks,
Al.

[Al Koch]

For anyone who might have been following this, I finally simplified the (very large) code base down to a very simple example that revealed that this bizarre behavior was actually caused by the inclusion of jQuery Mobile (as I mentioned in passing in the original post) and had nothing to do with JSP. If that is of interest, you can follow that new problem @ http://stackoverflow.com/questions/10241256/two-pages-are-merged-together-if-include-jquery-mobile-in-1st-page/10253256#10253256.

Again, thanks to William and Bear.