RE: using a datasource connection pool resource with username and password supplied by user
Hi Jeff, I will implement storing the connection in the session with the log out killing the connection. what happens if the user never logs out? then your Tomcat might end up with quite a few open connections that it cannot close and the only way to close such connections would be to restart Tomcat. I guess you'll also want to implement the connection closure when session times out/invalidated (using javax.servlet.http.HttpSessionListener) Kind regards, Sasha. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, 10 October 2005 3:48 PM To: Tomcat Users List Subject: Re: using a datasource connection pool resource with username and password supplied by user Thanks Doug and Chuck, I suspected as much re. the connection pool. This sort of negates the value of it a little (for me anyway). My original plan was to go with saving the connection to the session once it was established but I had read somewhere that connections are not 'serializable' and therefore the garbage cleanup in tomcat may kill the connection unexpectedly?!.? Has anyone used session tracking to store database connections? If so, has anything bad happened? Doug to answer your question How many users are there going to be on the system at once and can the system handle that many open connections?... I anticipate that the production version will have from 20 - 30 people updating information (in different cities ) and possibly 50 or so browsing the database for information. The backend database will be ORACLE 9i running in MS Server 2003 on an IBM server. In the pooled connection implementation I allowed for 150 concurrent users. I think oracle running on a pretty beefy application server should be able to handle it. The web server box will also be MS server 2003 on an older style server so I suppose the only scary part will be weaknesses (if there are any) in Tomcat itself. Anyway, I will implement storing the connection in the session with the log out killing the connection. Any comments or gotchas you know about would be useful. Jeffery S. Eaton Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. If you have received this electronic mail message in error, please immediately notify the sender and delete the message from your computer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Tomcat security realms question
Thanks Mark. I agree, but they are the security people and I have to at least try to comply. Do you think it would be feasible for us to change the org.apache.catalina.authenticator.AuthenticatorBase for Tomcat 4.1.18 to change the session ID post logging in? We'd obviously have to recompile tomcat after doing so. Are there any hidden gotchas you can think of with doing that? Thanks Alex. -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 2:50 AM To: Tomcat Users List Subject: Re: Tomcat security realms question The problem you describe is true of any session tracking system running over http. The solution is to use https. However, here's a question to fire back at your security team: If you are worried about an attacker physically looking at a session ID on a user's screen, what about if they decide to install a keyboard logger (physical or software) whilst they have access to the user's machine? In fact, I can think of a whole bunch of other things I could do as well that would be equally or more damaging than hijacking a single session. Fundamentally, if an attacker has physical access to a machine it is game over - they have won. Your security team knows the threat model for you situation far better than I do but it sounds to me like they are trying too hard in one area and have missed a bunch of other threats. Mark Akoulov, Alexandre [IT] wrote: Hi all I have a problem that's been raised by my security team to do with using Tomcat JDBCRealms. We're using such realms to protect restricted resources. We also have a custom login form. The steps Tomcat seems to follow when using such a setup is: 1. Check to see if the user is logged in with access to the restricted resource. 2. If they aren't, forward them to the login page and create an HTTPSession to keep track of that user. 3. Once they've logged in, add the authentication system to the HTTPSession created in step 2 to hold that info and forward them to the resource. 4. Continue using the same HTTPSession to maintain state. The problem my security team has with this is that someone could potentially steal the users HTTPSession ID before they've logged in, as this is created in the login screen. e.g. the user is forwarded to the login screen, then goes to make themselves a cup of coffee. A hacker goes to their computer and writes down the session ID. The user comes back and logs in, and the hacker pretends to be them from another computer. My question is: how can I avoid this situation and keep the security guys happy? Is it possible to have the session ID held by the browser (in JSessionID) change post-login (ie make tomcat invalidate the current session and create a new session after the user has been successfully authenticated)? Thanks for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat security realms question
Thanks a lot for your reply. We'll see if we can persuade our security guys to drop this issue. Kind regards, Alex. -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, 18 July 2005 2:50 AM To: Tomcat Users List Subject: Re: Tomcat security realms question The problem you describe is true of any session tracking system running over http. The solution is to use https. However, here's a question to fire back at your security team: If you are worried about an attacker physically looking at a session ID on a user's screen, what about if they decide to install a keyboard logger (physical or software) whilst they have access to the user's machine? In fact, I can think of a whole bunch of other things I could do as well that would be equally or more damaging than hijacking a single session. Fundamentally, if an attacker has physical access to a machine it is game over - they have won. Your security team knows the threat model for you situation far better than I do but it sounds to me like they are trying too hard in one area and have missed a bunch of other threats. Mark Akoulov, Alexandre [IT] wrote: Hi all I have a problem that's been raised by my security team to do with using Tomcat JDBCRealms. We're using such realms to protect restricted resources. We also have a custom login form. The steps Tomcat seems to follow when using such a setup is: 1. Check to see if the user is logged in with access to the restricted resource. 2. If they aren't, forward them to the login page and create an HTTPSession to keep track of that user. 3. Once they've logged in, add the authentication system to the HTTPSession created in step 2 to hold that info and forward them to the resource. 4. Continue using the same HTTPSession to maintain state. The problem my security team has with this is that someone could potentially steal the users HTTPSession ID before they've logged in, as this is created in the login screen. e.g. the user is forwarded to the login screen, then goes to make themselves a cup of coffee. A hacker goes to their computer and writes down the session ID. The user comes back and logs in, and the hacker pretends to be them from another computer. My question is: how can I avoid this situation and keep the security guys happy? Is it possible to have the session ID held by the browser (in JSessionID) change post-login (ie make tomcat invalidate the current session and create a new session after the user has been successfully authenticated)? Thanks for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat security realms question
Hi all I have a problem that's been raised by my security team to do with using Tomcat JDBCRealms. We're using such realms to protect restricted resources. We also have a custom login form. The steps Tomcat seems to follow when using such a setup is: 1. Check to see if the user is logged in with access to the restricted resource. 2. If they aren't, forward them to the login page and create an HTTPSession to keep track of that user. 3. Once they've logged in, add the authentication system to the HTTPSession created in step 2 to hold that info and forward them to the resource. 4. Continue using the same HTTPSession to maintain state. The problem my security team has with this is that someone could potentially steal the users HTTPSession ID before they've logged in, as this is created in the login screen. e.g. the user is forwarded to the login screen, then goes to make themselves a cup of coffee. A hacker goes to their computer and writes down the session ID. The user comes back and logs in, and the hacker pretends to be them from another computer. My question is: how can I avoid this situation and keep the security guys happy? Is it possible to have the session ID held by the browser (in JSessionID) change post-login (ie make tomcat invalidate the current session and create a new session after the user has been successfully authenticated)? Thanks for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: non-web app in tomcat
If your non-web application is to be only accessed by web apps why would not
you run it in the tomcat's JVM (just place non-web application in the
${catalina.base}/shared/classes or as a jar file into
${catalina.base}/shared/classes). In this scenario you eliminate the need for
maintaining the communication layer bw your non-web and web applications plus
launchable requirement becomes obsolete.
Regards,
Alex.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 5 July 2005 11:34 PM
To: tomcat-user@jakarta.apache.org
Subject: non-web app in tomcat
Hello all,
I need an advice : I have to develop an application which will be called by
other apps in the same server -- all the callers are wep apps stored in a
tomcat instance. This application is not a web app, but it has to access the
same resources (database), so I thought that the easiest would be to store this
non-web app in tomcat too.
This app has to be launchable :
- case 1 : by web apps stored in tomcat
- case 2 : by a scheduled task
My question is : which framework/technology should I use to develop this app ?
What communication ways would you advice me to use in both cases ?
Thanks !
Philippe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Use JSPC
Hi Mino, that is what we do: a) generate java files with JspC compiler b) compile java files with javac compiler c) copy class files to the required location (ie class directory under WEB-INF ) Hope it helps, Sasha. -Original Message- From: Giacomino Raccuia [mailto:[EMAIL PROTECTED] Sent: Thursday, 16 June 2005 7:13 PM To: tomcat-user@jakarta.apache.org Subject: Use JSPC Hi, I'd like to compile the JSP pages when I upload some new files on server (tomcat 4.0.3) . I use the utility JSPC, but this generate only java file but not the class file. I read that JRun has JSPC with -compile argument while my JSPC utilty doesn't have thi argument. Is possible to generate class file with tomcat and JSPC? Or there is another utility to use? Thanks in advance. Bye Mino - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem: Session invalidation in the servlet accessed via foreign context
Thanks, Steve, again. That's what I'm reading the servlet 2.4 spec as saying, because you can't invalidate a session in one context that is not accessible to you in another context, irrespective of whether you use getRequestDispatcher to do that. What section of the spec defines such behaviour? I understand that we cannot access a session created by one application from another one. However, an application can manage its own session(s) and the way the application is accessed (via RequestDispatcher or via direct hit) should not affect session management at all. Thanks again, I really appreciate your thoughts on this matter. Kind regards, Alex. -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, 23 May 2005 6:21 PM To: 'Tomcat Users List' Subject: RE: problem: Session invalidation in the servlet accessed via foreign context OK. So... your conclusion is that you can't do that, right? That's what I'm reading the servlet 2.4 spec as saying, because you can't invalidate a session in one context that is not accessible to you in another context, irrespective of whether you use getRequestDispatcher to do that. Or maybe I'm reading it wrong. That's possible as to be honest I've never tried what you're trying for real, I'm going on what the docs say not personal experience. -Original Message- From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED] Sent: Monday 23 May 2005 06:53 To: Tomcat Users List Subject: RE: problem: Session invalidation in the servlet accessed via foreign context Thanks again, Steve, for your time. I am not trying to share sessions between different apps. I just want to ensure that when we're programmatically accessing web application in the different context it can do its own session management (ie invalidate / create new ones) -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, 23 May 2005 11:52 AM To: 'Tomcat Users List' Subject: RE: problem: Session invalidation in the servlet accessed via foreign context I'm not sure why you think there is a problem with invalidation. I'm no expert, but I'm not sure that I would expect the code below to work, because by default, servlets must not share sessions between webapps, and you are asking that a client request to one context is passed to another, and still the session data is available. Withouht single sign-on, I would have thought that sessions will not be shared. I've just flipped through the 2.4 servlet spec. Section SRV.7.3 says something very specific about your scenario, as follows: if a servlet uses the RequestDispatcher to call a servlet in another Web application, any sessions created for and visible to the servlet being called must be different from those visible to the calling servlet. I appreciate that you are also saying that v3/v4 behaved differently - but are you sure that the config of those versions was not different, perhaps they were configured to share sessions (single sign-on)? I'm not sure on the detail of earlier versions of the servlet spec, but perhaps session behaviour was defined differently in previous versions. You could find out with a google search, or maybe someone else will answer -Original Message- From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED] Sent: Monday 23 May 2005 01:29 To: Tomcat Users List Subject: RE: problem: Session invalidation in the servlet accessed via foreign context Thanks a lot, Steve, for your reply. No, I am not using SingleSignOn neither hoping to share the same session across contexts. The only thing I was testing is that I could invalidate and then create a new session in different scenarios. I ran the test with the java debugger and could observe that when invalidating/creating a session in ForeignContextServlet it in fact did not create a new session and left us with the reference to old (ie invalidated) session after line No.3. My next step is start looking into the tomcat source code to try to work out what's happening. Do you think it's best way to approach this issue? Thanks again, Alex. -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, 23 May 2005 10:18 AM To: 'Tomcat Users List' Subject: RE: problem: Session invalidation in the servlet accessed via foreign context I'm not sure I fully understand this issue, but seeing as no-one else seems to have replied yet, maybe a few Qs might help you work through it: Are you hoping that both contexts will share their sessions? Are you using the SingleSignOn feature in server.xml? When you say that ForeignContextServlet does not create a new session object, are you explicitly testing that within ForeignContextServlet itself, or from a servlet in another context (e.g
Re: problem: Session invalidation in the servlet accessed via foreign context
Hi all,
I'd greatly appreciate if you could shed a ray of light on the following
problem ( see below)
-Original Message-
From: Akoulov, Alexandre [IT]
Sent: Friday, 20 May 2005 11:15 AM
To: Tomcat Users List
Subject: problem: Session invalidation in the servlet accessed via
foreign context
Hi all,
It seems that there is a problem with session invalidation in tomcat5.0. Please
refer to the explanation below:
1. HttpSession session = req.getSession(true); // get existing user session or
create one if does not exist
2. session.invalidate(); // invalidate user session
3. session = req.getSession(true); // create a new session ( ie a valid
session)
The above three lines of code are commonly used to invalidate the user session
and then create a new one. Tomcat implements this behaviour by creating a new
session object in line No.3.
However, in tomcat5.0 implementation (5.0.28) when the above code is accessed
via foreign context it does not create a new session object and therefore a
session is still invalid after lineNo.3 is executed. The following code
demonstrates the problem:
// servlet that runs in the same tomcat instance but in a different context to
DebuggerServlet's context
public class ForeignContextServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
HttpSession session = req.getSession(true);
session.invalidate();
session = req.getSession(true); // !!PROBLEM!! does NOT
create a new session when accessed via foreign context's dispatcher
}
}
// servlet that accesses ForeignContextServlet via foreign context's dispatcher
public class DebuggerServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
ServletContext ctx = getServletContext();
// dispatch the request to the servlet in a different context
ServletContext foreignContext = ctx.getContext(/AccessCommon);
foreignContext.getRequestDispatcher(/foreignContextServlet).include(req, res);
}
}
Such behaviour is only observed in tomcat 5.0 (have not tried on tomcat5.5);
tomcat3 and tomcat4 do create new session objects in lineNo.3
I greatly appreciate your comments on this issue.
Kind regards,
Alex.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: problem: Session invalidation in the servlet accessed via foreign context
Thanks a lot, Steve, for your reply.
No, I am not using SingleSignOn neither hoping to share the same session across
contexts.
The only thing I was testing is that I could invalidate and then create a new
session in different scenarios.
I ran the test with the java debugger and could observe that when
invalidating/creating a session in ForeignContextServlet it in fact did not
create a new session and left us with the reference to old (ie invalidated)
session after line No.3.
My next step is start looking into the tomcat source code to try to work out
what's happening. Do you think it's best way to approach this issue?
Thanks again,
Alex.
-Original Message-
From: Steve Kirk [mailto:[EMAIL PROTECTED]
Sent: Monday, 23 May 2005 10:18 AM
To: 'Tomcat Users List'
Subject: RE: problem: Session invalidation in the servlet accessed via
foreign context
I'm not sure I fully understand this issue, but seeing as no-one else seems
to have replied yet, maybe a few Qs might help you work through it:
Are you hoping that both contexts will share their sessions?
Are you using the SingleSignOn feature in server.xml?
When you say that ForeignContextServlet does not create a new session
object, are you explicitly testing that within ForeignContextServlet itself,
or from a servlet in another context (e.g. DebuggerServlet)? i.e. is
null==session after step 3?
You say that the session is invalid/null after line 2, but have you tested
that it was valid/non-null before line 2?
-Original Message-
From: Akoulov, Alexandre [IT]
[mailto:[EMAIL PROTECTED]
Sent: Monday 23 May 2005 00:43
To: tomcat-user@jakarta.apache.org
Subject: Re: problem: Session invalidation in the servlet
accessed via foreign context
Hi all,
I'd greatly appreciate if you could shed a ray of light on
the following problem ( see below)
-Original Message-
From: Akoulov, Alexandre [IT]
Sent: Friday, 20 May 2005 11:15 AM
To: Tomcat Users List
Subject: problem: Session invalidation in the servlet accessed via
foreign context
Hi all,
It seems that there is a problem with session invalidation in
tomcat5.0. Please refer to the explanation below:
1. HttpSession session = req.getSession(true); // get
existing user session or create one if does not exist
2. session.invalidate(); // invalidate user session
3. session = req.getSession(true); // create a new session (
ie a valid session)
The above three lines of code are commonly used to invalidate
the user session and then create a new one. Tomcat implements
this behaviour by creating a new session object in line No.3.
However, in tomcat5.0 implementation (5.0.28) when the above
code is accessed via foreign context it does not create a new
session object and therefore a session is still invalid after
lineNo.3 is executed. The following code demonstrates the
problem:
// servlet that runs in the same tomcat instance but in a
different context to DebuggerServlet's context
public class ForeignContextServlet extends HttpServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws ServletException, IOException {
HttpSession session = req.getSession(true);
session.invalidate();
session = req.getSession(true); //
!!PROBLEM!! does NOT create a new session when
accessed via foreign context's dispatcher
}
}
// servlet that accesses ForeignContextServlet via foreign
context's dispatcher
public class DebuggerServlet extends HttpServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws ServletException, IOException {
ServletContext ctx = getServletContext();
// dispatch the request to the servlet in a different context
ServletContext foreignContext =
ctx.getContext(/AccessCommon);
foreignContext.getRequestDispatcher(/foreignContextServlet).
include(req, res);
}
}
Such behaviour is only observed in tomcat 5.0 (have not tried
on tomcat5.5); tomcat3 and tomcat4 do create new session
objects in lineNo.3
I greatly appreciate your comments on this issue.
Kind regards,
Alex.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
RE: problem: Session invalidation in the servlet accessed via foreign context
Thanks again, Steve, for your time. I am not trying to share sessions between different apps. I just want to ensure that when we're programmatically accessing web application in the different context it can do its own session management (ie invalidate / create new ones) -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, 23 May 2005 11:52 AM To: 'Tomcat Users List' Subject: RE: problem: Session invalidation in the servlet accessed via foreign context I'm not sure why you think there is a problem with invalidation. I'm no expert, but I'm not sure that I would expect the code below to work, because by default, servlets must not share sessions between webapps, and you are asking that a client request to one context is passed to another, and still the session data is available. Withouht single sign-on, I would have thought that sessions will not be shared. I've just flipped through the 2.4 servlet spec. Section SRV.7.3 says something very specific about your scenario, as follows: if a servlet uses the RequestDispatcher to call a servlet in another Web application, any sessions created for and visible to the servlet being called must be different from those visible to the calling servlet. I appreciate that you are also saying that v3/v4 behaved differently - but are you sure that the config of those versions was not different, perhaps they were configured to share sessions (single sign-on)? I'm not sure on the detail of earlier versions of the servlet spec, but perhaps session behaviour was defined differently in previous versions. You could find out with a google search, or maybe someone else will answer -Original Message- From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED] Sent: Monday 23 May 2005 01:29 To: Tomcat Users List Subject: RE: problem: Session invalidation in the servlet accessed via foreign context Thanks a lot, Steve, for your reply. No, I am not using SingleSignOn neither hoping to share the same session across contexts. The only thing I was testing is that I could invalidate and then create a new session in different scenarios. I ran the test with the java debugger and could observe that when invalidating/creating a session in ForeignContextServlet it in fact did not create a new session and left us with the reference to old (ie invalidated) session after line No.3. My next step is start looking into the tomcat source code to try to work out what's happening. Do you think it's best way to approach this issue? Thanks again, Alex. -Original Message- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, 23 May 2005 10:18 AM To: 'Tomcat Users List' Subject: RE: problem: Session invalidation in the servlet accessed via foreign context I'm not sure I fully understand this issue, but seeing as no-one else seems to have replied yet, maybe a few Qs might help you work through it: Are you hoping that both contexts will share their sessions? Are you using the SingleSignOn feature in server.xml? When you say that ForeignContextServlet does not create a new session object, are you explicitly testing that within ForeignContextServlet itself, or from a servlet in another context (e.g. DebuggerServlet)? i.e. is null==session after step 3? You say that the session is invalid/null after line 2, but have you tested that it was valid/non-null before line 2? -Original Message- From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED] Sent: Monday 23 May 2005 00:43 To: tomcat-user@jakarta.apache.org Subject: Re: problem: Session invalidation in the servlet accessed via foreign context Hi all, I'd greatly appreciate if you could shed a ray of light on the following problem ( see below) -Original Message- From: Akoulov, Alexandre [IT] Sent: Friday, 20 May 2005 11:15 AM To: Tomcat Users List Subject: problem: Session invalidation in the servlet accessed via foreign context Hi all, It seems that there is a problem with session invalidation in tomcat5.0. Please refer to the explanation below: 1. HttpSession session = req.getSession(true); // get existing user session or create one if does not exist 2. session.invalidate(); // invalidate user session 3. session = req.getSession(true); // create a new session ( ie a valid session) The above three lines of code are commonly used to invalidate the user session and then create a new one. Tomcat implements this behaviour by creating a new session object in line No.3. However, in tomcat5.0 implementation (5.0.28) when the above code is accessed via foreign context it does not create a new session object and therefore a session is still invalid after lineNo.3 is executed. The following code
problem: Session invalidation in the servlet accessed via foreign context
Hi all,
It seems that there is a problem with session invalidation in tomcat5.0. Please
refer to the explanation below:
1. HttpSession session = req.getSession(true); // get existing user session or
create one if does not exist
2. session.invalidate(); // invalidate user session
3. session = req.getSession(true); // create a new session ( ie a valid
session)
The above three lines of code are commonly used to invalidate the user session
and then create a new one. Tomcat implements this behaviour by creating a new
session object in line No.3.
However, in tomcat5.0 implementation (5.0.28) when the above code is accessed
via foreign context it does not create a new session object and therefore a
session is still invalid after lineNo.3 is executed. The following code
demonstrates the problem:
// servlet that runs in the same tomcat instance but in a different context to
DebuggerServlet's context
public class ForeignContextServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
HttpSession session = req.getSession(true);
session.invalidate();
session = req.getSession(true); // !!PROBLEM!! does NOT
create a new session when accessed via foreign context's dispatcher
}
}
// servlet that accesses ForeignContextServlet via foreign context's dispatcher
public class DebuggerServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
ServletContext ctx = getServletContext();
// dispatch the request to the servlet in a different context
ServletContext foreignContext = ctx.getContext(/AccessCommon);
foreignContext.getRequestDispatcher(/foreignContextServlet).include(req, res);
}
}
Such behaviour is only observed in tomcat 5.0 (have not tried on tomcat5.5);
tomcat3 and tomcat4 do create new session objects in lineNo.3
I greatly appreciate your comments on this issue.
Kind regards,
Alex.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Recent spam
Thanks Mark and Co. for fixing the problem -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Wednesday, 18 May 2005 4:59 PM To: tomcat-user@jakarta.apache.org Subject: Recent spam All, Just a quick update on the recent issues. 1. The spam with German subject messages has been blocked by the infrastructure folks updating the anti-spam rules on the Apache list servers. 2. The New Atlanta List Server messages were blocked by me as soon as I saw them (Monday evening UK time). Due to the load on the list servers the unsubscribe message took about 10 hours to get through and another 10 hours to confirm. Since (as much as I'd like not to have to work for a living) I don't monitor my Apache e-mail 24x7 it wasn't sometime early Wednesday morning (UK time) that the messages were finally blocked. A couple of more general points about spam: 1. Sending messages of the form Is anyone else getting this spam? only makes matters worse. If you want to check what is appearing on the list, use one of the list archives available on the web. 2. If you think the list owners haven't noticed a problem, send a message to [EMAIL PROTECTED] Chances are we have seen the problem and are on the case but an extra heads up never hurt. Mark (one of) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem with the classloader in jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
Apparently, individual jars should be added as URLs rather than
normal file system paths. I suppose that means using
file:///path/file.jar, but I haven't tried it.
I guess that would work because Bootstrap.java has the following piece of code
in its createClassLoader(String, ClassLoader)
-
// Check for a JAR URL repository
try {
urlList.add(new URL(repository));
continue;
} catch (MalformedURLException e) {
// Ignore
}
-
Chuck, but would not be better if we fix the actual problem in the
ClassLoaderFactory#createClassLoader. Then people would not be spending time
working out why they cannot load a jar file :) We already have a fix - see
below :
---FIX-in
ClassLoaderFactory#createClassLoader---
// Add unpacked directories
//if (unpacked != null) {
//for (int i = 0; i unpacked.length; i++) {
//File file = unpacked[i];
//if (!file.exists() || !file.canRead())
//continue;
//if (debug = 1)
//log( Including directory or JAR
//+ file.getAbsolutePath());
//URL url = new URL(file, null,
// file.getCanonicalPath() + File.separator);
//list.add(url.toString());
//}
//}
//
if (unpacked != null) {
for (int i = 0; i unpacked.length; i++) {
File file = unpacked[i];
if (!file.exists() || !file.canRead())
continue;
if (debug = 1)
log( Including directory or JAR
+ file.getAbsolutePath());
// THE FIX !!!
StringBuffer filePath = new
StringBuffer(file.getCanonicalPath());
if ( file.isDirectory() ) {
// Only add a file separator if a file represents a
directory
filePath.append(File.separator);
}
URL url = new URL(file, null, filePath.toString());
list.add(url.toString());
}
}
Please let me know what you think
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Friday, 22 April 2005 4:09 PM
To: Tomcat Users List
Subject: RE: Problem with the classloader in jakarta-tomcat-5.0.28 -
cannot add a jar file to class repository
From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED]
Subject: RE: Problem with the classloader in
jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
However, if you add a reference to the actual jar file (eg,
shared.loader=${catalina.home}/shared/lib/velocity-dep-1.3.1.j
ar) you will not be able to use any classes from it but
rather will get ClassNotFoundException. This is the actual problem!
This appears to be the same situation described in Bugzilla entry 23344
(see
http://issues.apache.org/bugzilla/show_bug.cgi?id=23344
for details) which was marked as fixed in September 2003 in level
5.0.12. Apparently, individual jars should be added as URLs rather than
normal file system paths. I suppose that means using
file:///path/file.jar, but I haven't tried it.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem with the classloader in jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
Hi all,
I'd greatly appreciate your thoughts on the following issue (and the proposed
solution ):
When adding a jar file (eg, foo/bar.jar) to the class loader's repository it
treats as a directory and therefore it cannot load any classes from this jar.
The following explains why it happens.
org.apache.catalina.startup.ClassLoaderFactory is responsible for creating
class loader instances. Each instance is of
org.apache.catalina.loader.StandardClassLoader type, which in its turn extends
java.net.URLClassLoader:
-
public class StandardClassLoader extends URLClassLoader
-
ClassLoaderFactory#createClassLoader(File unpacked[], File packed[], URL
urls[], ClassLoader parent) is the actual method that creates class loaders.
The very first argument to this method contains jar files or directories ( that
is where the name unpacked comes from ).
ClassLoaderFactory#createClassLoader method adds File.separator to the end of
the jar file path ( file.getCanonicalPath() + File.separator ) when
constructing a URL instance to represent a jar file and then adds a string
representation of a newly created URL to its list of repositories (
list.add(url.toString()) ) :
-
if (unpacked != null) {
for (int i = 0; i unpacked.length; i++) {
File file = unpacked[i];
if (!file.exists() || !file.canRead())
continue;
if (debug = 1)
log( Including directory or JAR
+ file.getAbsolutePath());
URL url = new URL(file, null,
file.getCanonicalPath() +
File.separator);
list.add(url.toString());
}
}
-
For instance, if unpacked argument contains '/home/aa/lib/velocity.jar'
then a URL object is 'file:/home/aa/lib/velocity.jar/' - a forward slash /
(which is a Unix file separator) has been added to the url.
After ClassLoaderFactory#createClassLoader adds all repositories to its
repository list it converts this list to array and constructs
StandardClassLoader with it:
-
String array[] = (String[]) list.toArray(new
String[list.size()]);
StandardClassLoader classLoader = null;
if (parent == null)
classLoader = new StandardClassLoader(array);
-
StandardClassLoader( String[] ) constructor converts each repository found in
the given array argument to a URL object:
-
protected static URL[] convert(String input[],
URLStreamHandlerFactory factory) {
.
url[i] = new URL(null, input[i], streamHandler);
.
}
-
For instance, if the repositories array of String type contains
'file:/home/aa/lib/velocity.jar/' then a URL object is
'file:/home/aa/lib/velocity.jar/'. If the repository holds a path on Windows
machine then the URL object would have all backslashes replaced all with
forward slashes ( URL object crated with new URL(null,
file:I:\lib\velocity.jar\, streamHandler) would have
file:I:/lib/velocity.jar/ string representation ).
Once StandardClassLoader( String[] ) converts repository array of a String type
into a URL type it calls its super constructor, which in fact is a
URLClassLoader( URL[] ).
However, the contract for URLClassLoader( URL[] ) constructor indicates that
Any URL that ends with a '/' is assumed to refer to a directory. and
therefore a jar file gets ignored by the loader.
For instance, if the repositories array contains
'file:/home/aa/lib/velocity.jar/' url object the URLClassLoader( URL[] )
constructor treats this url as a directory and therefore a jar file is never
properly loaded.
Therefore, a File.separator that got added to a jar file in
ClassLoaderFactory#createClassLoader method made it invalid because the actual
class loader assumes that this jar file is a directory.
==
Proposed solution
==
RE: Problem with the classloader in jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
Thanks Chuck for your reply.
I still think it is a bug!!!
Please try the following: add a jar file (eg, foo/bar.jar) as a class
repository in the catalina.properties and then use one of the classes from this
jar file in one the servlets - will get a ClassNotFoundException.
I've attached ClassLoaderFactoryTest.java and
ClassLoaderFactoryWithTheFix.java. Please try to run the test - one of the
tests will fail, refer to the place where it fails and read the comments.
Kind regards,
Alex.
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Thursday, 21 April 2005 9:27 PM
To: Tomcat Users List
Subject: RE: Problem with the classloader in jakarta-tomcat-5.0.28 -
cannot add a jar file to class repository
From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED]
Subject: Problem with the classloader in
jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
ClassLoaderFactory#createClassLoader(File unpacked[], File
packed[], URL urls[], ClassLoader parent) is the actual
method that creates class loaders. The very first argument to
this method contains jar files or directories ( that is where
the name unpacked comes from ).
From what I can tell, it's the _second_ argument that should contain
.jar files; the first is for directories only.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-Original Message-
From: Akoulov, Alexandre [IT]
Sent: Thursday, 21 April 2005 6:29 PM
To: tomcat-user@jakarta.apache.org
Subject: Problem with the classloader in jakarta-tomcat-5.0.28 - cannot
add a jar file to class repository
Hi all,
I'd greatly appreciate your thoughts on the following issue (and the proposed
solution ):
When adding a jar file (eg, foo/bar.jar) to the class loader's repository it
treats as a directory and therefore it cannot load any classes from this jar.
The following explains why it happens.
org.apache.catalina.startup.ClassLoaderFactory is responsible for creating
class loader instances. Each instance is of
org.apache.catalina.loader.StandardClassLoader type, which in its turn extends
java.net.URLClassLoader:
-
public class StandardClassLoader extends URLClassLoader
-
ClassLoaderFactory#createClassLoader(File unpacked[], File packed[], URL
urls[], ClassLoader parent) is the actual method that creates class loaders.
The very first argument to this method contains jar files or directories ( that
is where the name unpacked comes from ).
ClassLoaderFactory#createClassLoader method adds File.separator to the end of
the jar file path ( file.getCanonicalPath() + File.separator ) when
constructing a URL instance to represent a jar file and then adds a string
representation of a newly created URL to its list of repositories (
list.add(url.toString()) ) :
-
if (unpacked != null) {
for (int i = 0; i unpacked.length; i++) {
File file = unpacked[i];
if (!file.exists() || !file.canRead())
continue;
if (debug = 1)
log( Including directory or JAR
+ file.getAbsolutePath());
URL url = new URL(file, null,
file.getCanonicalPath() +
File.separator);
list.add(url.toString());
}
}
-
For instance, if unpacked argument contains '/home/aa/lib/velocity.jar'
then a URL object is 'file:/home/aa/lib/velocity.jar/' - a forward slash /
(which is a Unix file separator) has been added to the url.
After ClassLoaderFactory#createClassLoader adds all repositories to its
repository list it converts this list to array and constructs
StandardClassLoader with it:
-
String array[] = (String[]) list.toArray(new
String[list.size()]);
StandardClassLoader classLoader = null;
if (parent == null)
classLoader = new StandardClassLoader(array
RE: Problem with the classloader in jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
The standard catalina.properties already has several jars and several
directories specified for the various class loaders,
standard catalina.properties has refs to *.jar (eg,
${catalina.home}/common/endorsed/*.jar) not to the actual jar file.
Bootstrap.java then checks whether there is *.jar at the end of the path,
strips it from the path and then adds to the packed list. If the path ends in
anything other than *.jar it gets added to unpacked list (that is where the
jar file ends up)
--
if (repository.endsWith(*.jar)) {
packed = true;
repository = repository.substring
(0, repository.length() - *.jar.length());
}
if (packed) {
packedList.add(new File(repository));
} else {
unpackedList.add(new File(repository));
}
--
However, if you add a reference to the actual jar file (eg,
shared.loader=${catalina.home}/shared/lib/velocity-dep-1.3.1.jar) you will not
be able to use any classes from it but rather will get ClassNotFoundException.
This is the actual problem!
Read the javadoc for the class in question. (The full URL is
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/catalina/docs/api/org/ap
ache/catalina/startup/ClassLoaderFactory.html#createClassLoader(java.io.
File[],%20java.io.File[],%20java.net.URL[],%20java.lang.ClassLoader).)
Well, the java doc says that packed - Array of pathnames to DIRECTORIES
CONTAINING JAR files that should be added to the repositories of the class
loader, or null for no directories of JAR files to be considered (not the
actual jar files).
At the same time java doc indicates that unpacked - Array of pathnames to
unpacked directories that should be added to the repositories of the class
loader, or null for no unpacked directories to be considered. I guess here it
means that a jar file is already considered to be unpacked directory. This
conclusion can be drawn from the Bootstrap.java code extract (see above) and
more importantly from the actual ClassLoaderFactory#createClassLoader method's
source:
if (unpacked != null) {
for (int i = 0; i unpacked.length; i++) {
File file = unpacked[i];
if (!file.exists() || !file.canRead())
continue;
if (debug = 1)
log( Including directory or JAR // LOOK HERE - expects
directory or a JAR file
+ file.getAbsolutePath());
..
..
if (packed != null) {
for (int i = 0; i packed.length; i++) {
File directory = packed[i];
if (!directory.isDirectory() || !directory.exists() ||
!directory.canRead()) // LOOK HERE - only expects to
find directories in here, not the files!!!
continue;
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Friday, 22 April 2005 3:13 PM
To: Tomcat Users List
Subject: RE: Problem with the classloader in jakarta-tomcat-5.0.28 -
cannot add a jar file to class repository
From: Akoulov, Alexandre [IT] [mailto:[EMAIL PROTECTED]
Sent: 2005 April 21, Thursday 19:48
Subject: RE: Problem with the classloader in
jakarta-tomcat-5.0.28 - cannot add a jar file to class repository
I still think it is a bug!!!
Read the javadoc for the class in question. (The full URL is
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/catalina/docs/api/org/ap
ache/catalina/startup/ClassLoaderFactory.html#createClassLoader(java.io.
File[],%20java.io.File[],%20java.net.URL[],%20java.lang.ClassLoader).)
The first parameter is for directories, the second for jars, which is
why they're named unpacked and packed, respectively.
Please try the following: add a jar file (eg, foo/bar.jar) as
a class repository in the catalina.properties
The standard catalina.properties already has several jars and several
directories specified for the various class loaders, and they all seem
to work fine in the levels I'm using (5.0.28 and 5.5.7) - otherwise
Tomcat wouldn't even be able to start up. What specifically did you
change in catalina.properties that led you to believe there's a problem?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
