RE: Why doesn't JSP precompilation solve this problem?

2005-03-13 Thread Frank Burns
No, I'm not using container-managed security. No, my .css files are not in a
different application context (webapp) as the pages. But, yes, I am using
MSIE6.

Other than the common MSIE6, unfortunately our problems don't appear to be
that similar.

Frank

-Original Message-
From: alexander dosher [mailto:[EMAIL PROTECTED] 
Sent: 13 March 2005 00:03
To: Tomcat Users List
Subject: Re: Why doesn't JSP precompilation solve this problem?

 When I deploy the application, and I newly visit each page, all of
 the text is displayed but the other visual elements (such as
 font-sizes, table layouts, colours, and other formatting set by
 CSS)appear broken.

are you using container-managed security?  are your .css files in a 
different application context than the page?  is your browser MSIE6?

if so, this *might* be similar to a problem i'm having, which stems from 
the fact that tomcat will serve unauthenticated http 304s (Not 
Modified). so IE will render the page content it has cached, but if the 
.css files come from a different context (or maybe even the same one, i 
haven't tried it like that) IE won't reload them - and apparently it 
doesn't cache them like it does the page. and you get non-styled ugliness.

haven't got a solution, short of filing the 403s thing as a bug, but 
this might help explain what you're seeing...

--alex.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Why doesn't JSP precompilation solve this problem?

2005-03-13 Thread Tim Funk
Sounds odd.
For debugging - try using Mozilla (or Firefox). For Mozilla there is a 
utility for viewing the header sent and received. Firefox also has one called 
the webdeveloper toobar which can also do the same.

Try loading the css files (or other broken assets) and check the responses 
being sent and received to find sketchy activity.

-Tim
Frank Burns wrote:
I'm using Tomcat v5.0.28 and have built a Struts-based application, using
Tiles, to construct the web pages.
When I deploy the application, and I newly visit each page, all of the text
is displayed but the other visual elements (such as font-sizes, table
layouts, colours, and other formatting set by CSS)appear broken.
When I'm developing the pages and want to check that they are visually
correct, I lose a lot of time having to re-hit the pages -- sometimes up to
twenty times before they will render properly -- and it's driving me
bonkers!
I thought the problem might have something to do with the fact that the JSPs
have to be compiled by Tomcat (Jasper) when they are first accessed.
However, I now precompile all of my JSPs before deploying the application
but exactly the same problems occur.
I have no idea why this is happening.
Can anyone explain why?
And, especially, can anyone tell me how to resolve this?
Sincerely,
Frank Burns.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Why doesn't JSP precompilation solve this problem?

2005-03-12 Thread alexander dosher
When I deploy the application, and I newly visit each page, all of
the text is displayed but the other visual elements (such as
font-sizes, table layouts, colours, and other formatting set by
CSS)appear broken.
are you using container-managed security?  are your .css files in a 
different application context than the page?  is your browser MSIE6?

if so, this *might* be similar to a problem i'm having, which stems from 
the fact that tomcat will serve unauthenticated http 304s (Not 
Modified). so IE will render the page content it has cached, but if the 
.css files come from a different context (or maybe even the same one, i 
haven't tried it like that) IE won't reload them - and apparently it 
doesn't cache them like it does the page. and you get non-styled ugliness.

haven't got a solution, short of filing the 403s thing as a bug, but 
this might help explain what you're seeing...

--alex.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]