Re: Repost: Double Login
Just a few thoughts since it looks like the JDBC realm that's causing you the problem. (And you don't say what Tomcat version you're using.) When I setup my own JDBC realm (for form-based-authentication) I noticed that its error handling wasn't all that hot. If the call errored (e.g. because I'd specified incorrect table or column names) it just looked like a failed logon. Maybe the first call is failing so the user's asked to log on again? (Tomcat 4.0.4) Also, what happens if you don't request the logon page first but request another protected page? (You may get errors generated, but at least that means your request got through...) How many times are you asked to authenticate then? If it's only one then that points to something your logon page is doing, right? Mike. - Original Message - From: Nathan McMinn [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 2:26 PM Subject: Re: Repost: Double Login Nope, it is just HTTP BASIC authentication, running over SSL. And there is no magic url or domain trickery going on. The really unusual part is that with a memory realm, I didn't have this problem. It only popped up after switching to a JDBC Realm. - Original Message - From: Troy J. Kelley [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Wednesday, January 08, 2003 8:23 AM Subject: RE: Repost: Double Login Are you using cookies or URL re-writing for session identifier? Are you doing anything funky with domain names or other such trickery which would cause your cookie to not be available upon doing the forward? -Troy -Original Message- From: Nathan McMinn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 9:07 AM To: [EMAIL PROTECTED] Subject: Repost: Double Login Hi all, Some of you had been kind enough to assist with this issue I posted previously. I had thought it was fixed, but it has appeared again. Any ideas? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpSession issues
Yep, that's the problem!
Try keeping a list of the names that you want to remove until you've
finished iterating the loop, then remove them all at once?
Mike
- Original Message -
From: Felipe Schnack [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, December 18, 2002 11:12 AM
Subject: Re: HttpSession issues
Yes, but this is related to an user session. How is possible to have
concurrent updates on an user session when an user have only one browser
window open and does a refresh? This iteration is done in a taglib. And
why this only happens when he refreshes the pages, but not when he hits
enter in the url bar?
BTW, inside this loop in some circumstances I change the session
attributes. In other words, the code look like this:
Enumeration attrs = session.getAttributeNames();
while(attrs.hasMoreElements())
{
String name = (String)attrs.nextElement();
Object value = session.getAttribute(name);
if (some weird conditions)
{
session.removeAttribute(name);
}
}
This removeAttribute() is the problem?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpSession issues
Also (but not related to your problem) I think I noticed just the other day
that hitting return in the address bar isn't the same as hitting refresh,
because the browser can serve the page from the cache.
For what it's worth, you can have concurrent requests if they hit refresh
twice in quick succession (the browser just ignores the response to the
first one, I think).
Mike
- Original Message -
From: Felipe Schnack [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Wednesday, December 18, 2002 11:12 AM
Subject: Re: HttpSession issues
Yes, but this is related to an user session. How is possible to have
concurrent updates on an user session when an user have only one browser
window open and does a refresh? This iteration is done in a taglib. And
why this only happens when he refreshes the pages, but not when he hits
enter in the url bar?
BTW, inside this loop in some circumstances I change the session
attributes. In other words, the code look like this:
Enumeration attrs = session.getAttributeNames();
while(attrs.hasMoreElements())
{
String name = (String)attrs.nextElement();
Object value = session.getAttribute(name);
if (some weird conditions)
{
session.removeAttribute(name);
}
}
This removeAttribute() is the problem?
On Wed, 2002-12-18 at 00:18, Mike W-M wrote:
This is nothing in particular to do with Tomcat, more with multi-threaded
programming.
The exception is used to indicate that whatever you've started iterating
through has been changed in the meantime.
The likely scenario here is that some other request is running at the same
time as you're doing your looping and it's adding or deleting a session
attribute. Check the java.util javadocs for more info.
I think the solution will be to synchronise the enumerating block of code,
and all other blocks that modify the session attributes, on the session
object. It's generally good practice to minimise the amount of code that
needs to be synchronised (and the time it takes) for performance reasons.
Mike.
- Original Message -
From: Felipe Schnack [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 9:12 PM
Subject: HttpSession issues
There's something problematic about the Enumeration i get from
HttpSession.getAttributeNames?
I have some situations in my application that I have to loop thru all
my session attributes, but for some reason sometimes I get an
java.util.ConcurrentModificationException then looping them...
The strangest thing is that a developer here get this error when he
reloads a page, but it doesn't happen when he press enter in the URL
bar... and this JSP file isn't the target of an HTML form... but
receives parameters from the query string
I'm using JDK 1.4.1 and Tomcat 4.1.12
--
Felipe Schnack
Analista de Sistemas
[EMAIL PROTECTED]
Cel.: (51)91287530
Linux Counter #281893
Faculdade Ritter dos Reis
www.ritterdosreis.br
[EMAIL PROTECTED]
Fone/Fax.: (51)32303328
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Felipe Schnack
Analista de Sistemas
[EMAIL PROTECTED]
Cel.: (51)91287530
Linux Counter #281893
Faculdade Ritter dos Reis
www.ritterdosreis.br
[EMAIL PROTECTED]
Fone/Fax.: (51)32303328
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Workaround for login page direct reference
I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect to the index page. It's not nice to be relying on a cookie name (what if they change it between versions, or if cookies are turned off (though I'm not sure the authentication works then anyway!)?) but I'm inclined to move in that direction when it's my turn Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Brett M. Bergquist [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 10:55 AM Subject: Re: Workaround for login page direct reference I'll give that a go. Thanks Ben - Original Message - From: Brett M. Bergquist [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; Ben Jessel [EMAIL PROTECTED] Sent: Monday, December 16, 2002 8:54 PM Subject: Re: Workaround for login page direct reference Ben, I'm not sure but I believe that I've seen mention that you can forward to a page that is not accessible to the outside. That is, put the Login.jsp page within WEB-INF of your web app and it will not be available to the outside world but you can forward to it from inside the web app. I don't know if this will work because I have not tried it but it might. Brett ... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: bug in Tomcat 4 or .... what?
From the Servlet Spec (2.3)'s section on the getParameter() method:
If the parameter data was sent in the request body, such as occurs with an
HTTP POST request, then reading the body directly via getInputStream() or
getReader() can interefere with the execution of this method.
I believe there's other stuff in there too about not expecting everything to
work as normal if you go low-level messing around with the request.
Mike.
- Original Message -
From: Ivan Venuti [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 12:31 PM
Subject: bug in Tomcat 4 or what?
Hi,
I have a servlet that opens a DataInputStrem on the request (see below)
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException{
try{
// Open the I/O streams
DataInputStream in = new DataInputStream(request.getInputStream() );
After this pice of code I cant' access any more to the request parameters.
Infact this code:
request.getParameter(anyParameter)
retrieves ALWAYS null.
The strange thing is that this servlet was Ok for tomcat 3, but can't work
any more with Tomcat4.
Anyone can explain why opening a DataInputStream alters the
HttpServletRequest?
Thanks
-- Ivan Venuti --
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Simultaneous request from same IP
A sensible investigation, granted, but there's a flaw in your argument! The current hypothesis is that two different requests are getting confused and giving the same values. So if the RequestDumperValve shows the same values for both requests then how will you know whether they originated as identical requests or whether they're different requests that have been confused Mike :-) - Original Message - From: Cox, Charlie [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 2:01 PM Subject: RE: Simultaneous request from same IP this goes along with the suggestion I made of using RequestDumperValve to dump the request to ensure that you are receiving 2 different requests. Charlie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Workaround for login page direct reference
Agreed. Don't forget that the beauty of open-source is that we can look at what Tomcat's doing... It throws the invalid reference error from the FormAuthenticator class, if no original request details have been saved as an internal note within the session. It doesn't immediately look like it's easy to get access to that information. As a last resort, it looks easy to alter that behaviour (assuming one can manage to recompile Tomcat). If no-one comes up with a better resolution to the problem (which, like you say, must be one that's cropped up many times before) then it would seem smart to try and get the developers to code in something a little more configurable. [I don't recall the spec says this behaviour is required, but...] i.e. it defaults to the current action unless you've specified a defaultPostLoginPage property of something or other. Still, the code had Craig's name on the top of it. Hopefully he'll come to our rescue Mike. - Original Message - From: Ben Jessel [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 2:16 PM Subject: Re: Workaround for login page direct reference Thanks mech, that's very interesting, however, i simply just can't believe that there are Tomcat instances out there in a live production environment with configured realms that suffer from this problem. Surely there must be something - Original Message - From: mech [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED]; 'Ben Jessel' [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 12:57 PM Subject: RE: Workaround for login page direct reference Some more ideas... In my application I never have a direct link to the login.jsp. Try to link either to any file that will be accessed after login (e.g. content.jsp) or link only to the secure directory that you mapped and let the welcome-file redirect link to index.jsp or whatever. Doesn't solve the back button issue (check tomcat bug list), doesn't prohibit users to bookmark the login.jsp, but improves usability at least a bit by avoiding some opportunities to get errors. For your intermediate page thing I would suggest looking into using filters. Unfortunately nothing can prohibit the anyone from using the browser back button and try to relog again because in that back button case the login.jsp isn't even loaded again; so you can't even check for that error by any means. Michael -Original Message- From: Ben Jessel [mailto:[EMAIL PROTECTED]] Sent: Dienstag, 17. Dezember 2002 13:43 To: Tomcat Users List Subject: Re: Workaround for login page direct reference Thanks Mike, I guess, another workaround is that you could just invalidate their session if they go to the login page Now, I still don't see how all this is going help that direct reference to login pageas it seems that I get this error if I go to login.jsp and then enter in my details. - Say the user goes to /login.jsp directly - If we've protecteed that page Tomcat goes, no - that's a protected resource, and forwards to /login.jsp Otherwise, tomcat just goes to the login page. - You enter the user details, and then tomcat tries to forward to the page you came from ( i.e login.jsp ), but detects this is invalid ( presumably by comparing against login-page in the web.xml, and displays an error - direct reference to login page What I'd really, really, like, is some way of having an intermediate page where I can check the requestURI to find out what page tomcat is going to redirect me *after* login, so tomcat would give me login.jsp?page_to_forward_to=blah.jsp... but alas, I don't think I can... - Original Message - From: Mike W-M [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 11:28 AM Subject: Re: Workaround for login page direct reference I'm going to have to sort this myself in the near future, but I don't quite see how the fact that you can forward to the protected resource is going to help? Isn't Tomcat going to automatically redirect (not forward - the distinction is important since redirecting will result in the login page's URL showing up in the browser's address bar) to the login page you've configured? Actually... since redirecting causes the browser to initiate a new request (for your WEB-INF/login page in this case), won't you get a 404-type error? Someone posted in a similar thread the other day that they intended to check a couple of things in the login page: 1. request.getRequestedSessionId() is *NULL* and 2. There is *NO* cookie named JSESSIONID I think the theory was that these would both be true on the first occasion the login page was accessed, but that if the user was already authenticated then the conditions wouldn't hold so the page should redirect
Re: Invalidate Session Problem
No, there isn't a way to force it. It's stated as a know problem in whichever RFC it is that defines the HTTP Basic Authentication mechanism. Other Mike. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 12:11 PM Subject: Re: Invalidate Session Problem I read your text many times but couldn't get to a conclusion. So, isn't there a way to force a logout and let the user authenticate again? At least with BASIC. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP to Servlet to JSP pathing issue. Relative PathingPlease help.
True (and I missed that that was the whole point of your exercise) but redirecting is the (only) way to get the browser's URL to change. If you think about it, you're basically saying that you want two different URLs (one to the servlet and one to the jsp), when displayed in the browser, to mean the same thing - which just isn't going to work. Two possible solutions: a) The ugly but quicker one: code the absolute URL in the jsp's form's action attribute. b) The elegant one: Don't link to the jsp page at all. Always link to the servlet, then make the servlet check for the existence of parameters. If your parameters exist then it was a form submission, so do what ever you do now and then forward() to the jsp. (This leaves the URL the same in the browser and doesn't lose the request-info.) If parameters don't exist, then just forward() to the jsp page (without doing any processing). It'll presumably behave like it does now when you request it directly. However, the browser's URL will still have the servlet's URL - and you can code all the paths relative to that. Mike. - Original Message - From: Jason Johnston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 3:25 PM Subject: Re: JSP to Servlet to JSP pathing issue. Relative PathingPlease help. The redirecting doesn't seem to work. That tells the browser client to initiate a new request and all the information that I placed in the request object is gone, which undermines the purpose of the form. The forums have a lot on my problem, just no answers that have worked for me. Has anyone else ran into the issue of using a form in a JSP to submit data to a Servlet, have that servlet return data to the very same JSP? Thanks in advance. [EMAIL PROTECTED] 12/16/02 12:53PM Thanks for the advice, I didn't know you could redirect. The javadoc on the RequestDispatcher only lists the forward and include methods. I'll try that. The initial call to the servlet is actually being made by the client browser via a form response. [EMAIL PROTECTED] 12/16/02 12:00PM If you want the path in the browser's address bar to change, I think you have to use a redirect rather than a forward. (I've read that even then it's not guaranteed to work (since it's browser-dependent), but it's working fine for me. There's the disadvantage of an additional network round-trip that's not ideal, but I don't know of any other way.) [Actually, I guess you're already redirecting from the original jsp request to the servlet. If you changed that to forward then that'd probably solve you're problem without the additional round-trip] Mike. - Original Message - From: Jason Johnston [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 16, 2002 5:46 PM Subject: JSP to Servlet to JSP pathing issue. Relative Pathing Please help. I have a JSP that has a form that I want processed by a servlet. The servlet then places the results in the page context and redirects back to the JSP. Everything works fine on the first go, but the second time through the path in the client's browser is no longer valid. Initially, the path is: http://localhost:8080/testgroup/lookup.jsp This then sends the form data to the /testgroup/servlet/dolookup?parameters The servlet executes and uses the request dispatcher to load the original JSP. RequestDispatcher rd=getServletContext().getRequestDispatcher(//lookup.jsp); rd.forward(request,response); The original JSP comes up fine and has the results, but the path in the browser URL is still the servlet address. Since the form sends to a relative path, the second time you try to run, it doesn't work. http://localhost:8080/testgroup/servlet/test.dolookup?epaid=J2466search=id; firstname=lastname= This seems to be a very simple relative pathing problem, but I've tried various solutions with no luck. I'm sure someone else has run into this and found a solution. If anyone has any insight, please help. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP to Servlet to JSP pathing issue. RelativePathingPlease help.
I was in the same sort of situation a couple of months back. (I've seen a few other posts about how relative paths are difficult and I'm happy with my solution so I've not investigated further.) I've been reminded by your web.xml that one of the things that stopped me from doing what I wanted was the wildcard-asterisk. I don't believe it works as a portion of a name (and I don't think you need it if you've only got it there to match the parameters, which might be part of your problem) - only immediately after a / to match everything, I seem to recall. Never mind! [Must get on with the work] Mike - Original Message - From: Jason Johnston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 4:01 PM Subject: Re: JSP to Servlet to JSP pathing issue. RelativePathingPlease help. Thanks Mike, that's probably the solution I'm going to go with. I agree that I don't want absolute URL's. Though I feel like there should be a way to do what I'm wanting to do, I'm just not finding it. I had seen another suggestion on the forums about mapping the servlet to the same path as the JSP, which sounded like it might work. However, I'm running into problems with that too. I haven't done much mapping so this is a good exercise for me, but I will probably just end with the solution you have suggested. I have the following in my web.xml file servlet servlet-namedolookup/servlet-name servlet-classtest.dolookup/servlet-class /servlet servlet-mapping servlet-namedolookup/servlet-name url-pattern/teststuff/dolookup*/url-pattern /servlet-mapping In my mind, this should make both the lookup.jsp and the dolookup servlet available from the same path, specifically http://localhost:8080/teststuff/ If that works, then I can use a simple relative path from the form to the servlet and the client path won't be changed. However, I'm not finding this in practice. A call to http://localhost:8080/teststuff/dolookup?etc is returning a not found error. I'm currently looking up all I can on the forums and tutorials on mapping, but every time I think I've figured it out - it doesn't work. But this is the fun part, I guess. Thanks for all you help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpSession issues
This is nothing in particular to do with Tomcat, more with multi-threaded programming. The exception is used to indicate that whatever you've started iterating through has been changed in the meantime. The likely scenario here is that some other request is running at the same time as you're doing your looping and it's adding or deleting a session attribute. Check the java.util javadocs for more info. I think the solution will be to synchronise the enumerating block of code, and all other blocks that modify the session attributes, on the session object. It's generally good practice to minimise the amount of code that needs to be synchronised (and the time it takes) for performance reasons. Mike. - Original Message - From: Felipe Schnack [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 9:12 PM Subject: HttpSession issues There's something problematic about the Enumeration i get from HttpSession.getAttributeNames? I have some situations in my application that I have to loop thru all my session attributes, but for some reason sometimes I get an java.util.ConcurrentModificationException then looping them... The strangest thing is that a developer here get this error when he reloads a page, but it doesn't happen when he press enter in the URL bar... and this JSP file isn't the target of an HTML form... but receives parameters from the query string I'm using JDK 1.4.1 and Tomcat 4.1.12 -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Faculdade Ritter dos Reis www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303328 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Simultaneous request from same IP
I might be missing the point!
What exactly is the problem? I didn't think there was any rule that said
you couldn't have two identical requests running at the same time (as long
as the outputs don't get mixed up).
As I understand it, requests will be differentiated by the fact that they
come from different TCP/IP port-numbers on the client machine. (Not sure
whether that info is available to your servlet, but I suspect Tomcat will
have to know it.)
Mike.
- Original Message -
From: Chris Bick [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Monday, December 16, 2002 3:13 PM
Subject: RE: Simultaneous request from same IP
Thanks for responding. I don't think it is an instance variable
problem. Here is the code to reproduce the problem:
public class AServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
reponse) throws ServletException, IOException {
printWriter pw = reponse.getWriter();
reponse.setContentType(text/html);
synchronized(System.out)
{
System.out.println(Query String: + request.getQueryString());
System.our.println(Header :
+request.getHeader(Test-Header);
}
out.println(Done);
}
Two different request hit this servlet about 1 sec apart everything is
fine. It's only when they enter the servlet at the same time.
I will submit a bug report if know one sees a problem with the above
code.
-cb
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 15, 2002 10:22 PM
To: Tomcat Users List
Subject: Re: Simultaneous request from same IP
On Sun, 15 Dec 2002, Chris Bick wrote:
Date: Sun, 15 Dec 2002 22:05:45 -0500
From: Chris Bick [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Simultaneous request from same IP
Hello,
Has anyone seen two requests from the same IP hitting a
servlet at approximately the time result in the same query string and
headers?
I can reproduce this every time. Make two requests from one machine
that hits my servlet at approximately the same time. Both
HttpServletRequest objects contain query string and header information
of the first request in. If the IPs are different everything works
properly.
This seems *much* more likely to be a thread-safety problem in your user
code than a bug in Tomcat. For example, using instance variables in
your
servlet to store per-request state information is pretty much guaranteed
to have difficulties.
The only way to know for sure would be for you to post a bug report
(http://nagoya.apache.org/bugzilla/) with a reproducible test case, so
that Tomcat developers can see what you are seeing.
Thanks,
-cb
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Simultaneous request from same IP
I should think it's likely, indeed desirable, that both requests are being handled by the same servlet, but I don't see how we could consider request-related headers to be global servlet variables. (And if there's any synchronising to do it surely belongs within the Tomcat code, since I can't see any circumstance where this kind of behaviour would be acceptable. We're only reading, as well.) I'm with CB - if this is indeed reproducible (I haven't checked, and I don't think CB has mentioned the version of Tomcat?) - then it's a bug, surely? [Also: is it just the headers that are identical or are the parameters identical too? (The getQueryString includes the parameter info, right?)] Mike. - Original Message - From: ContestAdmin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 16, 2002 4:06 PM Subject: Re: Simultaneous request from same IP It is possible that the two requests are being handled by the same servlet. The outputs can be confused if the servlet uses any 'global' servlet variables. Try either synchronizing the methods or have your servlet implement SingleThreadModel. -CA Chris Bick wrote: snip -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP to Servlet to JSP pathing issue. Relative Pathing Please help.
If you want the path in the browser's address bar to change, I think you have to use a redirect rather than a forward. (I've read that even then it's not guaranteed to work (since it's browser-dependent), but it's working fine for me. There's the disadvantage of an additional network round-trip that's not ideal, but I don't know of any other way.) [Actually, I guess you're already redirecting from the original jsp request to the servlet. If you changed that to forward then that'd probably solve you're problem without the additional round-trip] Mike. - Original Message - From: Jason Johnston [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, December 16, 2002 5:46 PM Subject: JSP to Servlet to JSP pathing issue. Relative Pathing Please help. I have a JSP that has a form that I want processed by a servlet. The servlet then places the results in the page context and redirects back to the JSP. Everything works fine on the first go, but the second time through the path in the client's browser is no longer valid. Initially, the path is: http://localhost:8080/testgroup/lookup.jsp This then sends the form data to the /testgroup/servlet/dolookup?parameters The servlet executes and uses the request dispatcher to load the original JSP. RequestDispatcher rd=getServletContext().getRequestDispatcher(//lookup.jsp); rd.forward(request,response); The original JSP comes up fine and has the results, but the path in the browser URL is still the servlet address. Since the form sends to a relative path, the second time you try to run, it doesn't work. http://localhost:8080/testgroup/servlet/test.dolookup?epaid=J2466search=id; firstname=lastname= This seems to be a very simple relative pathing problem, but I've tried various solutions with no luck. I'm sure someone else has run into this and found a solution. If anyone has any insight, please help. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Simultaneous request from same IP
That's the way I understand it.
I guess TrafficCop could be doing something screwy, but I'm not sure what.
(We note that the header-read code in the servlet (which presumably uses
some kind of collection-lookup) could be running at the same time as
TrafficCop is doing something, because a lock won't be attempted until you
reach the add() method. Still, that seems a little obscure given that you
say you can reproduce this every run.)
I just had a thought. Are you sure that your code that generates the
requests isn't operating in an unthreadsafe fashion and sending duplicate
requests?
Mike.
- Original Message -
From: Chris Bick [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Monday, December 16, 2002 6:25 PM
Subject: RE: Simultaneous request from same IP
TrafficCop is thread safe because add() is synchronized. Regardless if
trafficcop is thread safe or not the values that I get from
HttpServletRequest should not be the same. If I were to take TrafficCop
out of the servlet, I would get the same results in my servlet. I guess
what I am saying is that TrafficCop should have nothing to do with the
behavior that I am seeing inside the servlet. Right?
-cb
-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 1:05 PM
To: Tomcat Users List
Subject: Re: Simultaneous request from same IP
But the same trafficCop instance is being used at the same time for 2
differnt requests.
The trafficCop object has a method called add() which (seems to) acts
on instance variables inside of the trafficCop object. This makes the
trafficCop object not thread safe.
-Tim
Chris Bick wrote:
Why does that effect the HttpServletRequest object? If you look at
the
code it evaluates the header and query string values before I access
the
trafficcop object. I will give it a try.
-cb
-Original Message-
From: Tim Funk [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 12:40 PM
To: Tomcat Users List
Subject: Re: Simultaneous request from same IP
Is TrafficCop.java thread safe?
If not - that is your problem. Both requests are using the same
trafficCop instance.
-Tim
Chris Bick wrote:
No offense taken. I still can't believe that this problem may exist.
If you can find a problem with my code, that would be much easy then
getting a fix into tomcat.
Thanks,
-cb
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
import java.util.*;
import java.net.*;
/**
* pTitle: /p
* pDescription: /p
* pCopyright: Copyright (c) 2002/p
* pCompany: /p
* @author not attributable
* @version 1.0
*/
public class TrafficCopServlet extends HttpServlet {
private static final String CONTENT_TYPE_XML = text/xml;
private static final String CONTENT_TYPE_HTML = text/html;
/**@todo set DTD*/
private static final String DOC_TYPE = null;
//Initialize global variables
private TrafficCop trafficCop;
public void init() throws ServletException
{
trafficCop = new TrafficCop(false);
}
//Process the HTTP Get request
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
try
{
if (request.getRequestURI().endsWith(/insert))
{
response.setContentType(CONTENT_TYPE_XML);
out.println(?xml version=\1.0\?);
String pcpVersion = request.getHeader(PCP-Client-Version);
String clientId = request.getHeader(PCP-Client-ID);
String listenIP = request.getHeader(Listen-IP);
String behindFirewall = request.getHeader(Behind-Firewall);
String urn = request.getQueryString();
synchronized(System.out)
{
System.out.println(URN: + request.getQueryString());
System.out.println(request.getHeader(Listen-IP));
}
//System.out.println(Listen-IP: + listenIP);
if (pcpVersion == null || clientId == null ||
listenIP == null || behindFirewall == null ||
urn == null)
{
String error = errorBad Headers/error;
out.println(error);
return;
}
String xml = trafficCop.add(urn,new
URL(null,pcp://+listenIP,new Handler()), new
Boolean(behindFirewall).booleanValue(), 0);
System.out.println(xml);
out.println(xml);
}
else if (request.getRequestURI().endsWith(/delete))
{
response.setContentType(CONTENT_TYPE_XML);
out.println(?xml version=\1.0\?);
String clientId = request.getHeader(PCP-Client-ID);
String sessionId = request.getHeader(My-Session-ID);
String deleteSessionId =
request.getHeader(Delete-Session-ID);
String listenIP = request.getHeader(Listen-IP);
String behindFirewall = request.getHeader(Behind-Firewall);
String completed = request.getHeader(Completed);
String elapsedTime = request.getHeader(Elapsed-Time);
Re: Simultaneous request from same IP
Chris,
I've played around with a servlet almost identical to your original (not
full!) test-case (below). (Did you actually get the problem to appear on
this one or is it just a theoretical cut-down of the larger example you
posted later?)
I've made - not exactly concurrent, but definitely sub-second-apart -
requests from two instances of Internet Explorer. (Nifty finger/mouse
coordination.)
I cannot reproduce your confused results. [I've even added a
thread.sleep(1) into the servlet to ensure that the requests are running
(or at least in existence) concurrently. ]
I still can't think of anything you're doing in the servlet that would
produce the results you describe.
I (still) think that the problem is most likely with your simultaneous
requests themselves. How are you making these requests - via code? Can
you reproduce the problem with nifty-I.E. fingerwork?
Mike.
- Original Message -
From: Chris Bick [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Monday, December 16, 2002 3:13 PM
Subject: RE: Simultaneous request from same IP
Thanks for responding. I don't think it is an instance variable
problem. Here is the code to reproduce the problem:
public class AServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
reponse) throws ServletException, IOException {
printWriter pw = reponse.getWriter();
reponse.setContentType(text/html);
synchronized(System.out)
{
System.out.println(Query String: + request.getQueryString());
System.our.println(Header :
+request.getHeader(Test-Header);
}
out.println(Done);
}
Two different request hit this servlet about 1 sec apart everything is
fine. It's only when they enter the servlet at the same time.
I will submit a bug report if know one sees a problem with the above
code.
-cb
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 15, 2002 10:22 PM
To: Tomcat Users List
Subject: Re: Simultaneous request from same IP
On Sun, 15 Dec 2002, Chris Bick wrote:
Date: Sun, 15 Dec 2002 22:05:45 -0500
From: Chris Bick [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Simultaneous request from same IP
Hello,
Has anyone seen two requests from the same IP hitting a
servlet at approximately the time result in the same query string and
headers?
I can reproduce this every time. Make two requests from one machine
that hits my servlet at approximately the same time. Both
HttpServletRequest objects contain query string and header information
of the first request in. If the IPs are different everything works
properly.
This seems *much* more likely to be a thread-safety problem in your user
code than a bug in Tomcat. For example, using instance variables in
your
servlet to store per-request state information is pretty much guaranteed
to have difficulties.
The only way to know for sure would be for you to post a bug report
(http://nagoya.apache.org/bugzilla/) with a reproducible test case, so
that Tomcat developers can see what you are seeing.
Thanks,
-cb
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat setup question.
When you add jars to the classpath you have to add the (full name of the) jar itself, not just the directory where it lives. If the classes are unpacked (i.e. you've unzipped the jar), then you just add the directory. Does that help? Mike. - Original Message - From: Peng Tuck Kwok [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 1:09 AM Subject: Re: Tomcat setup question. Don't panic, just attach a sample servlet that you were trying to compile to the list. I'll have a look at it and try to get it to compile ok? The javac -classpath should work by the way. Patrick Martz wrote: Thank you for the help. However, I tried that...I added the directory where servlet.jar is located to the classpath. Once I do that, it no longer recognizes ANY of the other classes in its own directory, and therefore cannot make any references to them. I am frankly stumpedand I apologize for my ignorance but this is all very new to me. -Original Message- From: Peng Tuck Kwok [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 5:00 PM To: Tomcat Users List Subject: Re: Tomcat setup question. Tomcat comes with servlet.jar, which has all the classes you need. Or you can download a copy from Sun Microsystems as well. Just point your compiler to the servlet.jar or add it to the classpath. If you unpack the servlet.jar with winzip you'll see what I mean. Plus I think it is javax.servlet, not java.servlet. Patrick Martz wrote: Ok this is exactly my problem. These aren't MY jar files. These are jar files that came with Tomcat. Apparently, the standard J2SDK does NOT come with the servlet classes that I need to compile java servlets. So therefore, when I try to import java.servlet.* it fails miserably. Even the classes that come WITH Tomcat itself (for example, HelloWorldExample in the examples directory) are not compilable. Therefore, clearly, something needs to be done so that the java compiler can find these packages. Exactly what that is I do not know and would be very appreciative if anyone could help! -Original Message- From: Peng Tuck Kwok [mailto:[EMAIL PROTECTED]] Sent: Monday, December 16, 2002 4:41 PM To: Tomcat Users List Subject: Re: Tomcat setup question. So do I need to add an environmental variable to let my compiler find these? Or do I just need to move the .jar files to the right location? How do I know which .jar files are the correct ones to use (as I mentioned, there are a number of them that seem to have what I'm looking for)? You can do any of the steps you have suggested yourself or you could also just tell the compiler where to find your jars. javac -classpath would do the trick -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat setup question.
As an earlier poster pointed out, it's not:
import java.servlet.*;
import java.servlet.http.*;
It's:
import javax.servlet.*;
import javax.servlet.http.*;
Try that? (You'll still need the jar in your classpath (unless there's a
script doing something clever with the _HOME variables that I don't know
about).)
Also, I tend not to use pathnames with spaces in, just in case.
Mike.
- Original Message -
From: Patrick Martz [EMAIL PROTECTED]
To: 'Tomcat Users List' [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 1:26 AM
Subject: RE: Tomcat setup question.
Ok here's the current setup I have:
1) The j2sdk installed in C:\j2sdk
2) The j2ee installed in C:\j2ee (because this supposedly contains what I
need)
3) Tomcat installed in C:\Program Files\Apache Group\Tomcat 4.1
4) The following environmental variables set:
a) J2EE_HOME = C:\j2ee
b) JAVA_HOME = C:\j2sdk
c) Both C:\j2ee\bin and C:\j2sdk\bin added to PATH.
d) TOMCAT_HOME = C:\Program Files\Apache Group\Tomcat 4.1
e) There is no CLASSPATH variable set.
I have noted that C:\j2ee\lib\j2ee.jar contains the HttpServlet class as
does C:\Program Files\Apache Group\Tomcat 4.1\common\lib\servlet.jar. If I
try to compile, my compiler (from Sun) fails to import java.servlet.* and
java.servlet.http.*. If I try to add the .jar file the classpath, it still
fails to compile. Below is the servlet (it's very simple, I just want to get
this thing working!).
import java.io.*;
import java.util.*;
import java.servlet.*;
import java.servlet.http.*;
public class Test extends HttpServlet
{
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType(text/html);
PrintWriter out = res.getWriter();
out.println(HTML);
out.println(HEADTITLETest/TITLE/HEAD);
out.println(BODY);
out.println(test);
out.println(/BODY);
out.println(/HTML);
}
}
-Original Message-
From: Peng Tuck Kwok [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 5:10 PM
To: Tomcat Users List
Subject: Re: Tomcat setup question.
Don't panic, just attach a sample servlet that you were trying to
compile to the list. I'll have a look at it and try to get it to compile
ok? The javac -classpath should work by the way.
Patrick Martz wrote:
Thank you for the help. However, I tried that...I added the directory
where
servlet.jar is located to the classpath. Once I do that, it no longer
recognizes ANY of the other classes in its own directory, and therefore
cannot make any references to them. I am frankly stumpedand I
apologize
for my ignorance but this is all very new to me.
-Original Message-
From: Peng Tuck Kwok [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 5:00 PM
To: Tomcat Users List
Subject: Re: Tomcat setup question.
Tomcat comes with servlet.jar, which has all the classes you need. Or
you can download a copy from Sun Microsystems as well. Just point your
compiler to the servlet.jar or add it to the classpath.
If you unpack the servlet.jar with winzip you'll see what I mean. Plus I
think it is javax.servlet, not java.servlet.
Patrick Martz wrote:
Ok this is exactly my problem. These aren't MY jar files. These are jar
files that came with Tomcat. Apparently, the standard J2SDK does NOT come
with the servlet classes that I need to compile java servlets. So
therefore,
when I try to import java.servlet.* it fails miserably. Even the classes
that come WITH Tomcat itself (for example, HelloWorldExample in the
examples
directory) are not compilable. Therefore, clearly, something needs to be
done so that the java compiler can find these packages. Exactly what that
is
I do not know and would be very appreciative if anyone could help!
-Original Message-
From: Peng Tuck Kwok [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 4:41 PM
To: Tomcat Users List
Subject: Re: Tomcat setup question.
So do I need to add an environmental variable to let my compiler find
these?
Or do I just need to move the .jar files to the right location? How do I
know which .jar files are the correct ones to use (as I mentioned, there
are
a number of them that seem to have what I'm looking for)?
You can do any of the steps you have suggested yourself or you could
also just tell the compiler where to find your jars. javac -classpath
would do the trick
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional
Re: How to intercept user authentication
A general approach (at least I use it, but not with Struts or Velocity) is to make sure a session is created for each user who logs on. (One will probably have already been created by Tomcat in handling the basic-authentication - it certainly is using form-based authentication.) Then... 1) Check to see if there's an attribute in the session, called (e.g.) LoggedOn. 2) If there is, don't do anything (because this isn't the first time the user has made an authenticated request). 3) If there isn't, create an attribute with this name and record in the database the fact that this user has logged on. [Note that it's not generally good practice to go storing things in sessions that are still new ( .isNew()) because the browser hasn't necessarily agreed to take part in the session at that stage. But since I think one will have been created by Tomcat I've not bothered considering this...] Like I say, I use this but not with Struts. I have my own controlling servlet that all requests are passed through so I can perform these checks there before the request is processed. My (very basic) understanding of Struts is that it has its own controller servlet, but then you probably don't want to change that. I'll leave it to you to see if there's somewhere else (within the framework) you could use this approach, or to someone else to give you a Struts-specific method. Mike. - Original Message - From: Iran Marcius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 16, 2002 5:48 PM Subject: How to intercept user authentication I'm trying to do something that propably somebody did before (or, at least needed to). Currently I'm using tomcat 4.1.16 with Struts 1.0.1 and Velocity Tools for my applications. I configured a BASIC authentication realm, with digested passwords. How can I intercept the process after authentication is made so I can register login date/time in my database. Somebody could point me the direction? Thanx in advance. iran -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat for Enterprise Applications
I'm currently working (independently!) with Oracle's BC4J application / persistence framework (against a transactional MySQL database). The framework is supposed to be client independent, and JDeveloper (with which the framework comes) provides tools for generating / designing both thick and thin-web-based clients against the same backend logic implementation. (My quotes, not theirs! I can't vouch for their clients since I'm hand-coding my own JSPs - primarily because the wizard-created JSPs didn't suit (and looked rubbish!) at the time (and I had enough to learn) - and basically using BC4J for managed persistence (in place of EJBs).) If you're at the stage where you're just learning that J2EE doesn't necessarily mean EJBs (and that Tomcat doesn't support them!) then you've got a pretty steep learning curve ahead of you. I'd urge you to try to take a generative or framework approach to building your application and NOT to start trying to hand-code an enterprise app from scratch. [I suspect the same is true of dotNet as well?] I don't have a wide breadth of experience in Java - hopefully others will have more to add - but I'd recommend you take a look at JDeveloper / BC4J (It's low-cost, too!). Mike. - Original Message - From: Peng Tuck Kwok [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, December 13, 2002 9:44 AM Subject: Re: Tomcat for Enterprise Applications Tomcat only does jsp/servlets, so if you are after EJB's then you need something like Jboss, which also bundles tomcat for jsp/servlets or jetty. Apparently Jboss is pretty good and a lot of people are happy with it so you might want to look into it. You need to pay for the docs though. G. Balandres wrote: Hi all, i have currently an dicussion going on about creating a 3/Multi Tier Enterprise Application which will have one Webbased Client and one Standalone Client. The main aim is the Webbased Client. snip. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problem with chinese output in jsp/tomcat 4.1.12
I don't quite see where the chinese characters come into it, but I think
you've forgotten to put the curly-brackets
round the thing that's supposed to be conditional.
Instead of
%if(request.getParameter(sel1).equals(1))%
??
%out.println(hi from partha);%
...I suggest you try...
% if(request.getParameter(sel1).equals(1)) { %
Hi from partha
% } %
However, I think this in itself is a little flawed because you're going to
get a null-reference error if you try the equals comparison if no sel1 was
supplied.
Hope that helps.
Mike.
- Original Message -
From: Partha Ranjan Das [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 12, 2002 5:46 AM
Subject: problem with chinese output in jsp/tomcat 4.1.12
Hi,
I am using Tomcat 4.1.12. My requirement is to get Chinese
characters in JSP
pages.
I am using the following code:
in one page which has the form I am using:
BODY
form name=frm1 action=page2.jsp method=POST
Select name=sel1
option value=1??/option
option value=2/option
/selectbr
input type=submit value=submit
/form
/BODY
in the next page (page2.jsp) i am using the following code:
%@ page contentType = text/html; charset=big5%
BODY
this is a chinese output:
br
%if(request.getParameter(sel1).equals(1))%
??
%out.println(hi from partha);%
/BODY
The problem is that in any case i am getting the output as
the chinese chars
that have been written into the jsp body of page2.jsp irrespective of
whether i choose the first or the second option. and in the
html output is
also similar to the jsp code, which means that the jsp
translation is not
taking place in the tomcat. For other english pages it is happening
perfectly alright.
Any idea what can be done so that the translation takes place and the
conditional display of chinese is possible. Also shall be
highly grateful if
you give idea as to how to initialize and manipulate chinese strings.
Thanks in advance,
Regards,
Partha
ps- those ? marks are the chinese characters. I am using
Unicode text option
while saving the jsp files. So character conversion to ASCII
while saving is
ruled out. In fact the IE output is giving chinese.
*
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you may
not copy or deliver this message to anyone. In such case, you should destroy
this message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email for
messages of this kind.
*
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problem with chinese output in jsp/tomcat 4.1.12
That's clearer.
My email client isn't showing the chinese characters, actually. I'm sure
both that fact and your problem are related to character-encoding...(though
I don't exactly know what to do about it).
JSPs have a contentType attribute. (I think it defaults to iso-8851
(equivalent to windows-1252?) or whatever it is if not specified - and I'm
pretty sure that won't support Chinese.)
I'm not sure whether that affects the parsing, but I'd hope so.
All my pages start with
%@ page contentType=text/html;charset=windows-1252 %.
You might want to look into that attribute (in the JSP specs) to see whether
it's supposed to affect parsing or is just used to indicate something to the
client. Otherwise, I'd bet that one of Tomcat's or Jasper's encoding types
doesn't match with something that it ought to.
Mike.
- Original Message -
From: Partha Ranjan Das [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 12, 2002 11:22 AM
Subject: RE: problem with chinese output in jsp/tomcat 4.1.12
Hi Mike,
Thanks for your observation.
The main problem is :
whenever i try to use some chinese content in the jsp whether in the body or
in the java code, the jsp tags are not being parsed by the jsp engine with
tomcat4.1.12.
And hence, in the html output, I am finding that the %...% tags are left
as they are. This is not happening for english content.
Don't bother about the fact that the ??? maks are not showing as chinese if
your email client can show chinese.
For example,
BODY
form name=frm1 action=page2.jsp method=POST
Select name=sel1
option value=1??/option
option value=2/option
/selectbr
input type=submit value=submit
/form
/BODY
I hope it shows the chinese.
Any idea what the problem can be (I feel the problem could be with tomcat,
but am not sure)?
Regards,
partha
-Original Message-
From: Laxmikanth M.S.
Sent: Thursday, December 12, 2002 4:38 PM
To: Partha Ranjan Das
Subject: FW: problem with chinese output in jsp/tomcat 4.1.12
I don't quite see where the chinese characters come into it, but I think
you've forgotten to put the curly-brackets
round the thing that's supposed to be conditional.
Instead of
%if(request.getParameter(sel1).equals(1))%
??
%out.println(hi from partha);%
...I suggest you try...
% if(request.getParameter(sel1).equals(1)) { %
Hi from partha
% } %
However, I think this in itself is a little flawed because you're going to
get a null-reference error if you try the equals comparison if no sel1
was
supplied.
Hope that helps.
Mike.
- Original Message -
From: Partha Ranjan Das [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 12, 2002 5:46 AM
Subject: problem with chinese output in jsp/tomcat 4.1.12
Hi,
I am using Tomcat 4.1.12. My requirement is to get Chinese
characters in JSP
pages.
I am using the following code:
in one page which has the form I am using:
BODY
form name=frm1 action=page2.jsp method=POST
Select name=sel1
option value=1??/option
option value=2/option
/selectbr
input type=submit value=submit
/form
/BODY
in the next page (page2.jsp) i am using the following code:
%@ page contentType = text/html; charset=big5%
BODY
this is a chinese output:
br
%if(request.getParameter(sel1).equals(1))%
??
%out.println(hi from partha);%
/BODY
The problem is that in any case i am getting the output as
the chinese chars
that have been written into the jsp body of page2.jsp irrespective of
whether i choose the first or the second option. and in the
html output is
also similar to the jsp code, which means that the jsp
translation is not
taking place in the tomcat. For other english pages it is happening
perfectly alright.
Any idea what can be done so that the translation takes place and the
conditional display of chinese is possible. Also shall be
highly grateful if
you give idea as to how to initialize and manipulate chinese strings.
Thanks in advance,
Regards,
Partha
ps- those ? marks are the chinese characters. I am using
Unicode text option
while saving the jsp files. So character conversion to ASCII
while saving is
ruled out. In fact the IE output is giving chinese.
*
Disclaimer: The information in this e-mail and any attachments is
confidential / privileged. It is intended solely for the addressee or
addressees. If you are not the addressee indicated in this message, you
may
not copy or deliver this message to anyone. In such case, you should
destroy
this message and kindly notify the sender by reply email. Please advise
immediately if you or your employer does not consent to Internet email for
messages of this kind.
*
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
Tomcat uptime and stability in production environments
I remember someone telling me once, No wonder we're having problems - that NT box hasn't been rebooted for a week. I haven't seen any mention of it here, but wondered if anyone has any similar(ly pithy) advice to offer on matters of Tomcat / Java stability and uptime. Is one sensible to plan to restart a production Tomcat every night, or foolish if you plan to do it every month? Do JVMs eat more and more memory unless they're restarted? I'm planning to deploy on Linux, but it'd be interesting to see how opinion varies by platform. Ta. Mike. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat uptime and stability in production environments
It's all making interesting reading. I'm slightly surprised to see so many people on 4.1.x. When I stuck my head down a month or so ago to do some work, 4.0.4 was the production release. (A longstanding one, I believe.) Suddenly 4.1.x is the production version and everyone seems to be using that. And there seem to be more than a few complaints about it. I'm expecting to deploy to 4.0.x (where x = 5, I guess)... Mike. - Original Message - From: Brandon Cruz [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, December 12, 2002 3:35 PM Subject: RE: Tomcat uptime and stability in production environments Mike, I had this mysterious problem with Tomcat 3.2.4 which would force us to restart the server almost every day due to CPU usage slowly increasing over time. We tried upgrading to Tomcat 4.1.12 and found it to have several bugs and crash every once in a while (the crashing could have been configuration problems). We upgraded to tomcat 4.1.16 and do not seem to see any of the original problems and the server has not crashed or slowed down yet, it has only been up for about four days without restart so far, but the memory and CPU seems to be totally under control. We are on a linux machine as well. -Original Message- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Apache-Tomcat mod_jk
Denise, In application scenarios like this (and particularly because you seem to have multiple systems on the go) the thing that you need to consider is itransactions/i. You need to consider what happens if there's a failure at any stage in the process, the aim being to ensure that there's no way you can: i) charge the customer when it looks like you haven't ii) charge them but fail to keep a record of it iii) not charge them but make it look like you have... iv) etc. Across multiple systems this can be difficult! (Particularly if there are flat-files involved - it's a lot easier to do if you're only using (transactional) databases.) Of course it's not actually necessary to work-around all the potential problems if the business are prepared to take the risk Apologies if you knew all that already! Mike. - Original Message - From: Denise Mangano [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Thursday, December 12, 2002 9:41 PM Subject: RE: Apache-Tomcat mod_jk Well I took the novice route and started all over again. I got Tomcat 4.1.12 itself back up and running, but without mod_jk installed. I haven't had a chance to get back to trying again today, but I will tomorrow. If I run into the same problems, I will post my entire server.xml file, and hopefully all you nice people will find something that my untrained eyes cant. Maybe a little background on my project will help determine exactly what it is that I need. I have a site running on Apache 1.3.27 (mostly HTML, some XML) on RedHat 7.3. This site, through a connector, is pulling information from a UNIX system. That part works fine. I get to the last screen, where the connection to UNIX is broken, but not before I am passed a transaction number. I then direct the user to an HTML form, where I collect all their credit card information. This is the point I am at now. What I need to do from here is collect the info and transmit it to the payment processor through an API call, which I will either use servlet or JSP. Then I will display an updated page that varies depending on what the response is from the payment processor. All this over a secure connection of course (which from what I understand will be another battle). I then have to send the info I receive back to the UNIX system to be updated. (If anyone has any experience in a similar situation or any input regarding this project it is definitely welcome). Hope the background paints a clearer picture... Will post tomorrow when I try to set up mod_jk again. Thanks! Denise Mangano Help Desk Analyst Complus Data Innovations, Inc. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: where is stderr sent? AND ALSO 'System.err'
From the documentation: (http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/logger.html) Standard Error Logger (org.apache.catalina.logger.SystemErrLogger) The Standard Error Logger records all logged messages to whatever stream the standard error output of Catalina is pointed at. The default Catalina startup script points this at file logs/catalina.out relative to $CATALINA_HOME. This logger supports no additional attributes. Mike. Hi, OK, thats right but where are the messages written to? Into a logFile? Patrick Jon Eaves wrote: Hi all, Try these: Logger className=org.apache.catalina.logger.SystemErrLogger / Logger className=org.apache.catalina.logger.SystemOutLogger / Cheers, -- jon Patrick Kosiol wrote: Hi, this is a good question. In Java there is also a System.err. So I am also interested where the Messages were written. How does Tomcat handle those errormessages? Are them be logged in a special file oder easiely given out through the console. Are there differences between Linux and Windows systems where the Tomcat runs? thx Patrick Fabien Roy wrote: Hi! Where is stderr sent? Where is this defined? I have the following line in my application log (the path is defined in server.xml) 2002-12-11 12:45:42 cgi: runCGI: 1 lines received on stderr And I would like to know what that line is... Thanx Fabien -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Two instances of Tomcat with Formula 1 Software(E-spreadsheet)
I haven't any experience with this particular scenario, but I'm not going to let that stop me! I guess the two instances must be running in separate java processes (and that's probably fine, since I seem to be able to start up two JDevelopers at once!), so a) Does Tomcat2 give the same failure if Tomcat1 isn't running? Or if you try and run the report in Tomcat2 first, does Tomcat1 then fail? b) Is there any chance they're configured differently? Does this formula1 thing have a config file or setting that you've forgotten to copy across? Maybe a spill-to-disk / virtual-memory setting? Do any relative paths in both instances resolve correctly? c) Is there any chance that they're conflicting when trying to access the same (absolute) resource? Files? Databases? Okay, I'll stop helping and get some sleep... Mike. - Original Message - From: Mohbe, Sameer [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Cc: Mohbe, Sameer [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 10:38 PM Subject: Two instances of Tomcat with Formula 1 Software(E-spreadsheet) Hi Folks, Thanks to Ben and John on their inputs,But second instance of Tomcat(tomcat2) still errors out when it tries to create a report with Formula 1 software with Java.Lang.Out.Of.Memory error --though i increased the Heap size upto upper limit of 1 GB.The system has total 2GB of Memory .Everything else in the application in tomcat2 instance works fine.But that Report part is a Crucial part of the Apps. Is anyone using Two Instances of Tomcat on the same server with Formula1 s/w.Guys any help on this will be greatly APPRECIATED. Configuration : Red Hat Linux 7.0 Apache 1.3.12 Tomcat 4.0.4 -Two instances i.e tomcat and tomcat2 Regards Sameer -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SSL enabling through Java Application
Looks like an interesting application! Presumably you're aware that Tomcat doesn't come with SSL by default and that you need to install an implementation (generally Sun's) of the required security classes? In Java parlance, it's called JSSE. There's a HOWTO in (at least the 4.0) docs on the jakarta site Mike. - Original Message - From: Abhijat Thakur [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 10, 2002 7:23 PM Subject: SSL enabling through Java Application I have been able to embed tomcat in my java application and startup tomcat on port 8080. I am trying to create a Connector for HTTPS but every time i do that i get. java.lang.ClassNotFoundException: Can't find any SSL implementation at org.apache.coyote.http11.Http11Protocol.checkSocketFactory(Http11Protocol.ja va:454) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:133) at org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:10 02) at org.apache.catalina.startup.Embedded.start(Embedded.java:999) at com.bdna.pl.testing.EmbeddedTomcat.startTomcat(EmbeddedTomcat.java:92) at com.bdna.pl.testing.EmbeddedTomcat.main(EmbeddedTomcat.java:166) LifecycleException: Protocol handler initialization failed: java.lang.ClassNotFoundException: Can't find any SSL implementation at org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:10 04) at org.apache.catalina.startup.Embedded.start(Embedded.java:999) at com.bdna.pl.testing.EmbeddedTomcat.startTomcat(EmbeddedTomcat.java:92) at com.bdna.pl.testing.EmbeddedTomcat.main(EmbeddedTomcat.java:166) The code snippet that i use to create a connector. Here embedded is instance of Embedded class. // Assemble and install a default HTTP connector Connector connector = embedded.createConnector(null, 8080, false); embedded.addConnector(connector); //This code fails Connector sslConnector = embedded.createConnector(null, 8443, true); embedded.addConnector(sslConnector); thanks abhijat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: static url routing
I assume you've looked through all the elements available to you in web.xml. (I can't think of any that might help, but I'm no authority!) One (reasonably simple) solution would be to write yourself a servlet that performs the mapping for you. Assuming the root of the path remains constant for your requests like this, map that to the servlet. The servlet then has to examine the final part of the URL, lookup against your mapping-list (which you should really load up from an XML file during class-load, but you *could* hard code it), and then either redirect or forward to your required resource. (Redirect involves an extra round-trip and will mean that the user sees a URL that ends with the real filename; forwarding will leave the original URL in place.) Mike. - Original Message - From: RXZ JLo [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, December 06, 2002 9:50 AM Subject: RE: static url routing --- Noel J. Bergman [EMAIL PROTECTED] wrote: my html files have long names like a_b_c_d_xyz213_e_f_g.html, a_b_c_d_pqr983_e_f_g.html is it possible to have urls like http://localhost:8080/myapp/html/xyz213 point to the first file above? You can use either a Filter, or mod_rewrite in Apache httpd. I had a glance at javax.servlet.Filter - with this I cannot avoid entering a servlet, which will then wont be 'static' response. --- Noel Thanks rf To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Security concerns over URL
Apologies if this has all been asked / answered before (in fact I hope it has, and a pointer to previous info would be great!), but I'm looking for a little reassurance on some security concerns. Okay I have a web-application for which I'm using form-based login to authenticate the user. It's running over HTTPS / SSL. When I fire up my browser and enter a URL requesting a resource that falls within the application's secured area, I'm being correctly redirected to the login page. I've noticed that I'm picking up a jsessionid as part of the URL at this point. I've also found that after I've successfully logged-in, I can go to another machine, fire up a browser and get immediate access (i.e. no login required) to a protected resource if I enter its URL and append the previous ;jsessionid=. string. So my issues are: a) I'm only slightly concerned that someone will look over someone else's shoulder and make a note of the jsessionid string, since it'd be easier to watch their fingers than make a note of a 32-character string. (Then again, if you've got a digital camera with a zoom lens - or a photographic memory - it'd be easier to note the id.) My major concern here is that because this string forms a part of the URL it could be read as it passes over the network. I've done some Google-based research and have come to the conclusion that if I'm running over SSL/TLS then the string has probably been encrypted. (This is only a vague conclusion, though: statements like (I paraphrase) SSL is independent of the protocol running on top of it reassure me, but newsgroup discussions push me the other way.) However, I think I did see (in an SSL faq?) mention of proxies, caches, the SOCKS(?) protocol, tunnelling, and - particular worrying in this scenario - one other protocol that allows https requests to be logged or filtered or something, because the request data was transmitted unencrypted. Now if this url is ever transmitted in the clear, then I think there's a big security issue. b) I remember - years ago - having read someone criticise a web-container because the session-ids were predictable. Are Tomcat's session-ids predictable? i.e. If I were to get myself one of these session-id strings by asking for a protected resource (but not being able to logon because I don't have a username and password), what are the odds I could have a good guess at the previous session-ids that have been allocated and are probably still active? I guess what I was hoping is that a jsessionid would be useless outside of the HTTPS session or connection that produced it Thanks for any help Mike. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
