Max Rahder

Ranch Hand
+ Follow
since Nov 06, 2000
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Max Rahder

That's good advice! Thanks!
12 years ago
JSP
Oh. The answer is "I don't know." That would have saved some time in this discussion...

As far as the idea that differing browsers may have other behavior, I doubt it. I've never seen differences in browsers in the "normal" case illustrated by my example -- all browsers consistently re-fetch the result every time the page is visited. Again -- this is the behavior we want, and I see no inconsistencies across browsers.

As far as why I want to know... It seems natural to want to understand what's going on in a technology... I just realized I couldn't differentiate the circumstances when manual intervention is needed, and when it isn't -- I tend to simply discover that a page is cached during testing, and add code to address it. 90% of the time it doesn't cache, which is good -- I just don't know the exact circumstances when the client chooses to do so, or not to do so. In other words, I know how to force no caching, as explained in the article you linked, but I don't know how to predict when that will be necessary. And I'm uncomfortable with that lack of understanding.

I thought someone might know here.. As you suggest, I'll keep digging elsewhere. I'm sorry I brought up what turned into an conversation wrought with mis-communication and misunderstanding.

[I wrote this before Paul's response. Thanks for trying that out. It's interesting. I'll get a sniffer and do some more digging. To answer the earlier question of why I'm going down this path: I'm playing with the unrelated topic of HTML5 application caching, and the cache manifest. In my design, it may be convenient to flag or "tough" the manifest programmatically, in order to force the browser to re-read the manifest. But before going down that path, I wanted to understand how it all works...]
12 years ago
JSP
Let's start over...

Here's my original question: "The content returned by a servlet/JSP is dynamic in nature: tags, scriptlets and espressions are evaluated to generate the content sent to the client. Therefore, every call to a URL needs to "run" the JSP to have a fresh copy of the page content generated. On the other hand, I've seen the opposite -- for example, when coding data feeds I've needed to add some kind of bogus "nocache" query parameter to the client URL to ensure the browser doesn't use its cached copy."

I want it to call my page each time. And it does. But I don't know why. In my simple example, which is a JSP that contains

every time I refresh I see the new time. This is "normal" and not surprising -- we all take it for granted. But when I look in the response header I see nothing about preventing caching. So I'm asking how the client knows *not* to cache a typical JSP page like this.
12 years ago
JSP
How about this: Pretend I'm stupid, because apparently I am, because that article isn't helping me. Or maybe someone else can respond...

The thread at https://coderanch.com/how-to/java/NoCacheHeaders talks about how to manually set headers. I've never needed to do that, yet somehow the client *does* seem to re-execute the JSP every time.

I just tried a test. My JSP simply returns the current time. The response headers (provided by Tomcat) are:
Content-Length:37
Content-Type:text/html;charset=ISO-8859-1
Date:Fri, 12 Aug 2011 15:09:48 GMT
Server:Apache-Coyote/1.1
Set-Cookie:JSESSIONID=DE03FA27C9F20605515197ECEF1D7BF4; Path=/Test

Nothing about the cache, as discussed in the article, yet the client *is* re-running the JSP every time I refresh the page. So why *isn't* it caching?
12 years ago
JSP
This feels like a treasure hunt...

No, I want to know why it isn't cached all the time, not how to manually set headers or add "nocache" query parameters...
12 years ago
JSP
I see about 20 topics there, none with an obviously relevant title. Please be more specific.
12 years ago
JSP
Something I never quite understood is how JSPs control client caching.

The content returned by a servlet/JSP is dynamic in nature: tags, scriptlets and espressions are evaluated to generate the content sent to the client. Therefore, every call to a URL needs to "run" the JSP to have a fresh copy of the page content generated. On the other hand, I've seen the opposite -- for example, when coding data feeds I've needed to add some kind of bogus "nocache" query parameter to the client URL to ensure the browser doesn't use its cached copy.

So.. What's going on such that JSPs seem to get evaluated each time without my intervention, yet some times I need to do something, like a "nocache" query parameter, to force a new copy?

:-)
12 years ago
JSP
No, I tried that first -- changed the signature in the tld to array. Then I tried passing in fn:split() on the items, etc. I tried several combinations, and finally waved the white flag and went with the solution above. Thanks for the help. :-)
13 years ago
JSP
Thanks for the idea, but that didn't work either. I can't figure it out. I switched the method to take a string and a delimiter -- the routine splits the string and processes the resulting array as before.
13 years ago
JSP
I'm trying to specify a function in a tld for a method whose argument is a varchar. What's the syntax?

My signature is,
public static String removeEnds(String string, String... prefixes) {

I'm not really sure what to try in the tld, although the obvious does not work:
<function-signature>java.lang.String removeEnds(java.lang.String, java.lang.String...)</function-signature>

When I tried this I got the following runtime error, so it obviously isn't recognizing that "String..." is special sytax, and not the name of a class.
org.apache.jasper.JasperException: The class java.lang.String... specified in the method signature in TLD for the function fn:removeEnds cannot be found. java.lang.String...
13 years ago
JSP
I'm sorry I didn't take the time to review the code in detail, but one thing jumps out at me: I suggest avoiding multiple try..catch blocks. The point of a try block is to group the set of statements that should succeed or fail as a whole. For example, in method saveApplications(), if you fail to read the first file is there any way to recover before subsequently running writeObject()? If not, there's no point in separating the call into it's own try..catch. Instead, group all the statements that must success together in a single try block. Review all your try..catch blocks to see which should be done as a single larger try block.

:-)
14 years ago
It depends on what types of object you want to store in the map. If you might store anything in the Map, then there is no way to improve it -- what you've defined will store any object/object pair. But, for example, if you know the key is a String, then define the variable as private Map<String, Object> map = new HashMap<String, Object>(); -- the more specific your requirements, the more specific you can be. (By the way, your get() and put() methods don't seem to do anything more than what's provided in the map itself.)
14 years ago

jami siva wrote:is any more explanation for why we can'nt declare static variables in static block


You are allowed to code a local variable in a block, but you can't declare a member in any block. As far as "why" -- that's just the rule. The Java Language Specification says "A block is a sequence of statements, local class declarations and local variable declaration statements within braces." So, members, such as static fields, can't be declared in a block.
14 years ago
(You get simultaneous responses when you write your response, take a phone call, then press Submit when you hang up.)
14 years ago
You've defined the member inside the static block. You need to define it outside the block, and within the block, simply reference it.
14 years ago