Mayer Salzer

Greenhorn
+ Follow
since Apr 01, 2002
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 Mayer Salzer

After some further research, I finally got it!
My Struts servlet was using the "commons" logging (org.apache.commons.logging). Once I figured that out it was merely a matter of time before I found this doc (http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/impl/SimpleLog.html) on how to configure the "commons" logging interface.
For those interested, you can do it by setting System properties (i.e. System.setProperty("org.apache.commons.logging.simplelog.defaultlog", "ERROR") or by creating a property file named "simplelog.properties" with that name/value pair, and putting the file in your (class loader) classpath.
I also came across this doc that explains how struts uses logging by default (http://jakarta.apache.org/struts/userGuide/building_controller.html#logging).
20 years ago
Dora,
I am using Log4J but I don't think that's it. The debug level is set to "ERROR" and I know it works because I dodn't get any of the other "debug" or "info" messages I have in my code. Also, my log4j messages go to a special log file, these (struts) messages are going to my "stderr" log/console.
Unless there's something else that I need to do with the log4j properties file - specifically for the struts servlet . . . ? Did you experience similar problems?
Thanks,
Mayer
20 years ago
I'm not aware of any request.getProperty() method either.
I think you mean the 'getParameter' method (and how that's different from the getAttribute' method). If that's the case check out this post. https://coderanch.com/t/354641/Servlets/java/Difference-request-getAttribute-request-getParameter
[ March 15, 2004: Message edited by: Mayer Salzer ]
20 years ago
Hi All,
I'm working with Struts for the first time and can't seem to disable the 'Info' messages. For example on every forward (to path ''default.do) I get a message on the console/log '[INFO] RequestProcessor - -Processing a 'POST' for path '/default''. I also get a bunch of other annoying info messages specially upon servlet initialization.
The strange thing is that no matter what I do the messages end up in my 'stderr' log/console (not 'stdout').
I'm using WSAD 5.0 (with 4.0 test environment) as well as the Websphere 4.05 server (the same thing happens in both WSAD and WAS).
I've tried using changing the values of the ActionServlet's 'debug' and 'detail' init-params but it did not help (I've used all of the following values to no avail -1, 0, 1, 2, 3 etc).
Here's an excerpt of my web.xml file.

Any help would be appreciated.
Thanks!
[ March 15, 2004: Message edited by: Mayer Salzer ]
[ March 15, 2004: Message edited by: Mayer Salzer ]
20 years ago

Originally posted by Servin Park:

Use loginCookie.setMaxAge(1); instead of loginCookie.setMaxAge(0)


I tried it, it makes no difference . . . (it actually prolongs the life of the cookie for one more second). If the time on the clients computer is running behind the server, the cookie will still not be expired, until the client's clock catches up . . .
21 years ago
Chanoch,
Setting the expiration date to the past (by passing a negative number to the 'setMaxAge' method) does not work the way you would expect it to. Instead, when you set the expiration date to any negative number, the cookie gets treated like a 'session cookie' which means it gets deleted (on the client's side) when the browser is closed - not before then. If the user doesn't close the browser the cookie is still alive and well. Try it yourself and see how it works.

Thomas,
Invalidating the session is a good solution if you're dealing with session cookies (tracks the session id for each session). However, we're talking about regular cookies. These things are used to maintain state long after the session is gone. They're totally independent of sessions. . .
21 years ago
I'm no expert on cookies, but I think I've had the same or similar situation where I'd expire a cookie and it would take a while for it to die. After fooling around with the system clock om my computer, I figured out that if the (client's) computer's time is running behind the server's, the cookie will still be alive and chirping, long after you buried it . . .
The reason for this is that you don't delete cookies, only expire them. When you code loginCookie.setMaxAge(0); all you're doing is setting the cookies expiration time to the current time on the server. If the client's computer is running slower, it won't realize that the cookie is supposed to be expired and it'll still get sent back on the next request . . .
However you can still identify these dead cookies (ghosts ???), by altering its contents the same time you're expiring it. In fact you're already doing that, loginCookie.setValue("");. Thus, even if you find the cookie in the clients request, if its value is blank you know it's dead . . .
Hope this helps . . . .
[ December 03, 2002: Message edited by: Mayer Salzer ]
21 years ago
1) request.getSession(true) retreives the current session if it was already created before otherwise it creates a new one (first time in).
2)There are a number of ways to determine if a session is new. isNew() will work, so will extracting some value from the session and asking if it is null provided you put it into the session before. A third option is checking for request.getSession(false) == null. . .
22 years ago
Hi,
I don't know if this will solve your problems, but it's worth noting a couple of things.
1) From your sample code it seems that you are creating or modifying a cookie in your servlet and then "forwarding" the request to your jsp and expecting the changes to the cookie to be visible right away in your jsp. This may be your problem.
I'm assuming that your jsp finds the cookie by calling the "request.get Cookies()" method, which returns an array of cookies that were saved on your client's hard drive and were submitted along with the request. When you create or modify a cookie it saves it back to your client's hard drive by adding it to the "response" object (response.addCookie). This means it doesn't get saved back to the client's hard drive until the request's trip completes. The request does not complete its trip until after it's done with the jsp you "forwarded" to as well. Since the jsp looks for the cookie in the "request" object, it does not see these changes until you complete the trip and then hit it a second time . . . The same is true for when you expire a cookie (setting max-age to 0). Your jsp won't know the cookie's max-age was changed in the servlet unless the trip (back to your client) was completed in the interim.
One way to get around this, is by having your servlet "redirect" to the jsp (response.sendRedirect). Unlike "forwarding", redirecting does complete the trip first, and only then does it come back to your jsp with the newly created/modified/expired cookie in tow . . .
2) The second point is something you mentioned about setting the max-age and not seeing it in the cookie. I too seem to recall debugging a servlet (using Visual Age for Java) and peering in on the contents of a cookie I created, and noticing that the max-age was always -1. This was true for all cookies even those that did in fact have a different max-age (meaning they were in fact expiring after a designated time, yet I still wasn't seeing their true max-age value when debugging it). Since this wasn't an actual problem (like I said the cookies were expiring at the designated time), I never pursued it any further . . .
Good luck . . .
[ June 09, 2002: Message edited by: Mayer Salzer ]
22 years ago
You problem is the path to the "exe" file. Since your invoking it on the server side, you need your class (servlet) to execute it directly, instead of executing it on the client side (downloading it through the "http . . " path) and then being at the mercy of the browser as to whether the file is opened, saved, etc.
Instead of using the virtual directory Runtime.getRuntime().exec("http://servers IP address/the path on the server/filename.exe")
You should use the actual physical directory where the "exe" is located Runtime.getRuntime().exec("/physical/location/of/your/filename.exe") (on unix) or Runtime.getRuntime().exec("C:\\physical\\location\\of\\your\\filename.exe") (on windows) I'm sure you get the idea by now . . .
[ June 07, 2002: Message edited by: Mayer Salzer ]
[ June 07, 2002: Message edited by: Mayer Salzer ]
[ June 07, 2002: Message edited by: Mayer Salzer ]
22 years ago
I'm not sure why that's happening. I tried an example like that myself and it works fine.
When you redirect, a message is sent to the client (your browser) telling it to send the request elsewhere. Provided that you redirect to the appropriate path of your cgi-bin (or whatever else runs your script), your websphere server should be out of the loop at that point. . .
For example suppose you have a servlet "TestServlet" invoked with "http://yourhost/webapp/TestServlet". You also have a cgi script named "script.cgi" invoked with "http://yourhost/cgi-bin/script.cgi". In the servlet, if you call response.sendRedirect("http://yourhost/cgi-bin/script.cgi") it will redirect the request to the new url which happens to be your cgi script. The fact that the request was rerouted from a websphere server (or any other) should not matter.
22 years ago
Hi,
If I understand you correctly you want the client's request (via the servlet) to kick off (or run) an "exe" file on the server. You can do that by calling the "Runtime" class' "exec" method.
Example (in windows environment):
Runtime.getRuntime().exec("calc.exe");
would start the claculator . . . You can do the same for your own "exe" file provided you include the path for it . . .
[ June 07, 2002: Message edited by: Mayer Salzer ]
22 years ago
Hi,
What if anything are you getting on your output page? Are you getting any error codes?
Also I noticed in your example <form action= "/servlet/coreservlets1.ThreeParams1"method="Get"> that there's no space between the "action" tag and the "method" tag. I don't know if this was just a typo when you copied it over, or if you actualy have it this way in your html page, in which case you probably got a 404 error code . .
If you're not getting anything, did you start your test environment? Is it set up correctly (including the ".webapp" file etc . .)
Good luck.
[ June 06, 2002: Message edited by: Mayer Salzer ]
22 years ago
I would start by trying to redirect the servlet-request to your cgi script.
In your "service" method:
response.sendRedirect("/cgi-bin/yourScriptName");
22 years ago
To throw in my own 2 cents on this topic . .
Attributes are set explicitly (with the setAttribute() method). This is nice since it allows you to add attributes to a request object at any point and then forward it to another servlet or jsp. Parameters on the other hand come from posted form variables AND from the query string (example: http: //hostname/myServlet?testing=123, will return a value of '123' when you call request.getParameter("testing"); ). This means that similar to attributes, you can intercept a request and add parameters to it, by appending a query-string, and then redirecting it to another servlet (however I'm not sure whether you'd then lose any parameters that were in the orginal query-string).
Another significant difference between the 2 is that parameters can only be 'String' objects (and are returned as such from the getParameter method). Whereas attributes can be any object (and are returned as 'Object' objects which you then cast back to its original type).
22 years ago