Re: TC4's classloader choking on xerces.jar (maybe)
- Original Message - From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > Tomcat 4 follows the new rules in the servlet 2.3 PFD spec, which allows a > container to change this so that loading starts with your WEB-INF areas first. > > Consider the following scenario - I put a copy of the Postgres JDBC driver (just > to show that it's not specific to xml parsers :-) in my shared library > directory, because lots of my apps need it. But, one of my webapps needs a > different version of the Postgres driver, because it depends on a new feature > that was implemented in a later version. So, I put the new driver file in the > WEB-INF/lib directory of my webapp, and install it in Tomcat. > > Under Tomcat 3.2, the newer driver is ignored (because it's got the same class > names). Under Tomcat 4.0, the newer driver is respected for that webap -- all > others continue to use the shared one. Craig, I have a small doubt here. If I place the same jar file containing the class xyz.class in the tomcat/lib directory and in WEB-INF/lib directory, then will tomcat load the class from the tomcat/lib directory or WEB-INF/lib directory? If it is loaded from the WEB-INF/lib directory then this class gets loaded by a different classloader(webapp class loader) and is incompatible with the classes loaded from tomcat/lib. Should the container not check the META-INF/MANIFEST.MF to find out if the versions are same and if the versions are same it loads the class from tomcat/lib directory. Or do the specs mandate that any class in the WEB-INF/lib directory overrides class found in the tomcat/lib directory. Do the classes in WEB-INF/lib override the classes on the classpath in tomcat 4.0? Regds, Gokul > > Craig McClanahan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
- Original Message - From: "Hans Bergsten" <[EMAIL PROTECTED]> > > Gokul Singh wrote: > > > > Hans Bergsten wrote: > > > [...] > > > > I am trying to disallow a single user to have multiple login sessions > > valid at any given time. I have to enforce this even if the user tried > > to login from two different machines. A small addition here. The requirement is that the user be allowed to login by creating a new session on login request and invalidating any valid session that he may have at that time. To be more elaborate. 1. A user U logs in and has a session associated with him i.e. S1. 2. user U goes to another machine and tries to login. 3. The user U should get a new session S2 with S1 being invalidated. I hope the requirements are now clear. > archives for details). The bottom line is that a session is associated > with a "client", not a "user". Agreed. > > Can you suggest a solution for this which works on tomcat 3.2.1 and > > uses servlet specs 2.2 only. > > Something like this should work in any compliant container. Thanks for putting down the whole code for me. I already implement this philosophy in my code. But the requirements are slightly different as spelled above. > To make sure a user only logs in once, check if the loginID is > already in the context structure before allowing a new login > and creating the UserBean. The requirement is that the user can login any no. of times he wants. But he should have only one valid session and that should be the session from the last successful login attempt as mentioned above. Can you please tell me if this is possible using 2.2 specs and tomcat 3.2.1 Regds, Gokul PS: I have joined this list today only. I am not sure if this posting is appropriate for this list or not. If it is inappropriate here, then please mail to me privately. > > Hans > -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: NullPointerException from HttpSessionFacade.invalidate()
Christopher K. St. John wrote:> > All I'm saying is that it's dangerous to rely on behavior> > that's not clearly defined by the spec, > >> But give me a break: what JServ is doing in this case> is just fantastically counterintiutive. I agree with Chris on this. > This probably needs to be summarized and sent as > spec feedback, but unless he says otherwise I will> assume Gokul Singh is going to do it (Gokul?) I think the specs do need to clarify this matter. So I think I am going to summarize it and send it to spec feedback. Regds, Gokul > > -cks>
Re: NullPointerException from HttpSessionFacade.invalidate()
Hans Bergsten wrote:> [...]> The spec may not be explicit enough about this, but the session object> you get back from the getSession() object is a container-managed object> that the application is not supposed/allowed to keep long-lived> references > to. It's the same as with all other container-objects made available to> the> application; request, response, JSP tag handlers, etc. > I'm not sure why you're keeping references to the session objects in> you're application, but if you describe what you're trying to do I'm> sure I can give you a hint about another way to accomplish the same> thing without the problems you have with your current solution. I am trying to disallow a single user to have multiple login sessions valid at any given time. I have to enforce this even if the user tried to login from two different machines. Can you suggest a solution for this which works on tomcat 3.2.1 and uses servlet specs 2.2 only. Regds, Gokul
Re: NullPointerException from HttpSessionFacade.invalidate()
- Original Message - From: Craig R. McClanahan To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Thanks for looking into the problem. I think the I was not able to convey the problem properly. I have some clarifications below. > The session object is valid for more than one request, but only up until the time that it is invalidated. After that, further access to the old session object is illegal. Agreed. But this is not what I am doing. The session is valid. You can remove the lines of code listed below from the code I posted and still you will get the Exception. Remove the following two lines and follow the steps mentioned in the earlier mail to reproduce the error. == if(objSession != null) objSession.invalidate(); == > The reason you see a behavior difference is that Tomcat 3.1 did not recycle session object instances, but Tomcat 3.2 does. There lies the catch and the source of problem in my understanding. In different requests relating to the same session, I may get referance to HttpSessionFacade instances which are different, but I expect them to be same (although not guarantied by specs but I thought it was a tacit agreement between container and servlet developer). What I suggest is that tomcat should recycle the HttpSessionFacade instance only when the HttpSession instance is recycled.This might be more inefficient as it will result in N instances on HttpSessionFacade if there are N valid sessions on the server, where as in the present scenario, if my understanding is correct, there will be X instances of HttpSessionFacade if there are X simultaneous requests. and X is less than N. To be more elaborate: Lets us assume the following scenario. 1. A request comes which creates a new session. A HttpSession object (HS1) is created and the Facade object (HSF1) wraps around it. 2. I store a referance to the session in the context that is a handle to HSF1 which maps to the userid. 2. Another request comes from the same session . The object made available to the request is not necessarily HSF1 and may be HSFx which wraps around HS1. 3. At this point in time HSF1 may wrapped around another instance of HS or nothing at all ( null). 4. I get the handle to the session which I want to invalidate from the context which is HSF1. Now I am in trouble due to the point above. In my opinion HSF1 should not refer to any other session till HS1 is invalidated (or timed out). What should I do to avoid this problem? Why am I storing the referance of a session in context? I want to prevent double login of the same user and on the second login want to invalidate his previous login. The second login may be from a different machine with no valid session. Regds, Gokul > > Craig McClanahan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
NullPointerException from HttpSessionFacade.invalidate()
Hi,I am trying to build a login servlet and get a
NullPointerException from HttpSessionFacade class in Tomcat 3.2.1.The code
of the simple version of the servlet which reproduces theproblem is attached
at the end of this mail along with the stack trace of the Exception
thrown.This piece of code works fine on tomcat 3.1.1 but fails on tomcat
3.2.1
To reproduce the error,1. start tomcat 3.2.1 afresh.2. Login from a
browser.The password field is not required as for now.3. Open another
browser (not a new instance of the same browser) on the samemachine or
another machine.4. Login with the same username.the servlet does the
following1.it invalidates any existing session on this request.2.it
checks the context to find if the present user has any associatedsession and
if it is there tries to invalidate it. (This is where I get theexception,
given below).3. creates a new session.4. puts the new session into the
context with the user id.In tomcat 3.2 is the session object which I get
( actually HttpSessionFacade) valid only for the request or can span multiple
Requests?
Any help would be greatly appreciated.
I am not on this mailing list. Please send a CC to me at [EMAIL PROTECTED] when replying to
this mailRegds,Gokul= 8< SERVLET CODE
= 8< ===import javax.servlet.*;import
javax.servlet.http.*;import java.io.*;public class
TestSessionBehaviourextends HttpServlet{ private static String
STR="LOGIN.SESSION.USER."; public void doGet(HttpServletRequest req,
HttpServletResponse res) throws IOException,
ServletException { res.setContentType("text/html");
PrintWriter out = res.getWriter(); sendLoginPage(out);
out.close(); } public void doPost(HttpServletRequest req,
HttpServletResponse res) throws IOException { String
name = req.getParameter("id"); HttpSession objSession =
req.getSession(false); // if the present request has a session
invalidate it. if(objSession != null)
objSession.invalidate(); // if this user has a valid session,
invalidate it. objSession =
(HttpSession)getServletContext().getAttribute(STR+name); if
(objSession != null) { System.out.println("The session
from context retrieved"); try
{ objSession.invalidate();
}catch(IllegalStateException ex) { }
} // create new session objSession =
req.getSession(true); // store in the context the username and
session.
getServletContext().setAttribute(STR+name,objSession); // send
reciept html res.setContentType("text/html"); PrintWriter
out = res.getWriter(); sendReceipt(out);
out.close(); } private void sendReceipt(PrintWriter
out) {
out.println("ReceiptThe login
isrecorded"); } private
void sendLoginPage(PrintWriter out) {
out.println("Test LoginPlease
login method=post> ");
out.println("Name
");
out.println("Passwordname=pass>");
out.println("type=submit
value=login>");
out.println(""); }}=
8<= EXCEPTION THROWN 8< =Internal Servlet
Error:java.lang.NullPointerException atorg.apache.tomcat.facade.HttpSessionFacade.invalidate(HttpSessionFacade.java:136) at
TestSessionBehaviour.doPost(TestSessionBehaviour.java:33) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404) at
org.apache.tomcat.core.Handler.service(Handler.java:286) at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) atorg.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) atorg.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) atorg.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) atorg.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at
java.lang.Thread.run(Thread.java:484)= 8<= 8<
=
---"The
proverb warns that, 'You should not bite the hand that
feeds you.' But maybe you should, if it prevents you from feeding
yourself."--Thomas
Szasz---
