Re: DO NOT REPLY [Bug 35128] - Cannot pass -ea to Tomcat JRE
My email address has changed to [EMAIL PROTECTED]
I require this info urgently....
Greetings, How can I get Tomcat to use a policies file to do RMI? I have a policies file. I have a servlet that attempts to make use of RMI, but I don't see where I can tell Tomcat to use the policies file. I get: exception: java.security.AccessControlException: access denied (java.net.SocketPermission IP address:port connect,resolve) when I try to access the servlet via a browser. Thanks, Aditya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: domain-wide session cookies?
On Mon, 24 Mar 2003 11:44:04 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? 1) if not, is this the right place to do it? 2) what is the best place (ie. where in server.xml) to put an option to enable this? I personally prefer option 3 -- don't change anything. Exposing session id cookies to a broader audience than just the webapp that created them is a security vulnerability. If you need to share stuff across webapps, use some other cookie, not the container-managed one. It's a little more wierd and esoteric than that -- we have multiple virtual hosts (all in the same second-level domain) pointing at a single webapp/context (with Apache/mod_jk) and we need to have sessions shared across the virtual hosts. I started by reimplementing a parallel session manager that wrote a domain cookie, but that seemed silly, so I've written a filter that writes a copy of the session cookie valid for the entire domain when the session.isNew(). Of course, this isn't perfect since Tomcat insists on writing the default host session cookie *after* all filters are evaluated...which might be construed as a bug/feature. After all, shouldn't filters have the ability to manipulate the entire HTTP response? If anyone has a suggestion on how to deal with that, I would welcome any hints. Thanks, Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Filter access to response object [was Re: domain-wide sessioncookies?]
On Mon, 24 Mar 2003 14:10:59 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: Sharing a session across virtual hosts violates the Servlet spec (Section 7.3 - HttpSession objects must be scoped at the application (or servlet context) level and Section 3.6 - Servlet contexts can not be shared across virtual hosts), so you should not really be surprised to find the logic for setting up a session cookie be hard coded in the manner you describe. Okay, you're right, that violates the spec. So please forget I asked (grin). Instead, what is now troubling me is that it seems that Tomcat adds HTTP headers to the response object *after* all filters have been applied. AFAICT, the spec does not explictly comment on this and so I'm assuming it is a detail left to the implementator. Here's my problem: - I have a single filter that essentially does: doFilter(...) do stuff to request object... chain.doFilter(..); do stuff to response object... } however, it seems that Tomcat adds response headers _after_ the filter, is there a reason for that? I'd like to manipulate *ALL* the headers in the response object with my filter... Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filter access to response object [was Re: domain-wide sessioncookies?]
On Mon, 24 Mar 2003 21:32:07 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: On Mon, 24 Mar 2003, Aditya wrote: Here's my problem: - I have a single filter that essentially does: doFilter(...) do stuff to request object... chain.doFilter(..); do stuff to response object... } however, it seems that Tomcat adds response headers _after_ the filter, is there a reason for that? I'd like to manipulate *ALL* the headers in the response object with my filter... Since Tomcat adds its last headers when the response is committed (because otherwise they would not be able to be added), why not just add a call to: response.flushBuffer(); before the line that says: do stuff to response object... Maybe I wasn't clear -- I'd like to manipulate all the response headers at the point I say do stuff to response object... and if I call response.flushBuffer() right before that, I no longer can manipulate the headers in the response object (empirically verified under Tomcat 4.1.20). I must be missing something. Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: domain-wide session cookies?
For those who care, I've answered my own questions: On Thu, 20 Mar 2003 21:40:20 -0800, Aditya [EMAIL PROTECTED] said: Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? Yup, do it in a filter. Using a filter to manipulate cookies is trivial and using session.isNew() guarantees that we just do this once. If anyone wants any more detail about this strange, slightly yucky hack, please ask. Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
domain-wide session cookies?
Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? 1) if not, is this the right place to do it? 2) what is the best place (ie. where in server.xml) to put an option to enable this? Thanks, Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: memory leak on context reload or stop/start? [was Re: trackingmemory usage over time]
We are using 4.1.20 where this particular leak (and another one in Jasper) is supposed to be fixed and we use jikes in any case. Thanks, Adi On Fri, 14 Mar 2003 10:51:57 +0530, Uddhav Shirname [EMAIL PROTECTED] said: The release note of Tomcat 4.1.18 talks about a known memory leak with JSPs. I am not aware of its status with Tomcat 4.1.20. This is what it has to say, JAVAC leaking memory: The Java compiler leaks memory each time a class is compiled. Web applications containing hundreds of JSP files may as a result trigger out of memory errors once a significant number of pages have been accessed. The memory can only be freed by stopping Tomcat and then restarting it. The JSP command line compiler (JSPC) can also be used to precompile the JSPs. -- Uddhav - Original Message - From: Aditya [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 14, 2003 10:27 AM Subject: memory leak on context reload or stop/start? [was Re: tracking memory usage over time] Just to followup, we have found a few things that were causing this leak, two that were particular to our setup, but the third seems to be a Tomcat problem (4.1.20 with Jasper2): 1) log4j was eating up a lot of memory and there was a slow leak. Since it wasn't strictly required, we've stopped using it and the largest leak stopped. 2) we are using jdbcpool from http://www.bitmechanic.com/projects/jdbcpool/ (it is the only connection pool we could find that can be instantiated programmatically from within a context without having to define a pool in advance via JDNI -- we give each context it's own database and therefore it's own pool) which doesn't seem to have a clean way to stop the pool manager thread when a context is stopped/reloaded. We've worked around this, however the memory leak remains and is due to context reloads / stops-starts 3) there seems to be a leak caused by reloading or stopping/starting a context (we have an automatic httpunit test that builds a jar file periodically and makes sure it is working in a context). We don't see the memory leak unless one or more JSPs are compiled before the context is reloaded or stopped/started. Is there some particular section of the code we should be examining to track this further? Adi On Tue, 25 Feb 2003 22:08:41 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Aditya wrote: Glenn, several months ago you had posted a URL to a document (at kinetic.more.net if I remember correctly) where you talked about having to restart your production Tomcat(s) every 4 weeks or so due to Heap exhaustion. Is that still the case? If so what causes the heap exhaustion? I think that part of the heap problem for me was the recent bug in Jasper which I fixed where a number of resources such as Node trees from a JSP page compile were not dereferenced between compiles. This was fixed in Jasper before the 4.1.20 release. We've looked high and low, with JProbe etc, and we still can't find where the leak is. We're having to restart a Tomcat (4.1.20) with -Xms and -Xmx both set to 256M every 4 days or so. Does the increase in memory usage correlate with an increased number of connectors due to a spike in request volume? Perhaps you should try increasing the heap size. Regards, Glenn - 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]
How many Loggers in a stanza? [was Re: Tomcat id inAccessLogValve and Spread]
I've written a new class that extends o.a.c.logger.LoggerBase (using spread - www.spread.org) and can be used as a Logger in server.xml; AFAICT it works fine and does what I wanted it to do. However it seems that there can only be one Logger section per container which means I can't have (for testing purposes at least) something like this: Host ... Logger className=org.apache.catalina.logger.FileLogger directory=/var/log/tomcat prefix=localhost_log. suffix=.txt timestamp=true/ Logger className=com.zapatec.catalina.SpreadLogger spreadName=localhost-six spreadGroup=tcexcep timestamp=true/ /Host which writes both the logfile to disk and sends a copy of the log messages via spread without having to have both in the same class. Is there a reason why one can't have multiple Logger sesions per container? Thanks, Adi On Fri, 17 Jan 2003 16:54:07 -0500, Shapira, Yoav [EMAIL PROTECTED] said: Howdy, I'm trying to consolidate the access logs for a whole bunch of Tomcats using Spread (www.spread.org) like I do with Apache. The easiest way to do this seems to be to patch org.apache.catalina.valves.AccessLogValve to use Spread and I've done that trivially. Perhaps it would be better to subclass AccessLogValve to add this functionality? Then you could contribute your class to the tomcat project and users of the normal AccessLogValve wouldn't need to know anything (or depend on) Spread. somewhat figure out where it came from, but I run into problems when I have multiple Tomcats load-balanced by mod_jk serving the same virtual hosts. The easiest way then to tell where it came from seems to be to use the jvmRouteId any other, better, more easily obtained, unique identifier I can use? The combination of host name and jvmRouteId is decent. Would %A (local IP address) in the access log work for you? I'm assuming your load-balanced servers have different IP addresses even if they share the virtual hosts. Yoav Shapira Millennium ChemInformatics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
memory leak on context reload or stop/start? [was Re: trackingmemory usage over time]
Just to followup, we have found a few things that were causing this leak, two that were particular to our setup, but the third seems to be a Tomcat problem (4.1.20 with Jasper2): 1) log4j was eating up a lot of memory and there was a slow leak. Since it wasn't strictly required, we've stopped using it and the largest leak stopped. 2) we are using jdbcpool from http://www.bitmechanic.com/projects/jdbcpool/ (it is the only connection pool we could find that can be instantiated programmatically from within a context without having to define a pool in advance via JDNI -- we give each context it's own database and therefore it's own pool) which doesn't seem to have a clean way to stop the pool manager thread when a context is stopped/reloaded. We've worked around this, however the memory leak remains and is due to context reloads / stops-starts 3) there seems to be a leak caused by reloading or stopping/starting a context (we have an automatic httpunit test that builds a jar file periodically and makes sure it is working in a context). We don't see the memory leak unless one or more JSPs are compiled before the context is reloaded or stopped/started. Is there some particular section of the code we should be examining to track this further? Adi On Tue, 25 Feb 2003 22:08:41 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Aditya wrote: Glenn, several months ago you had posted a URL to a document (at kinetic.more.net if I remember correctly) where you talked about having to restart your production Tomcat(s) every 4 weeks or so due to Heap exhaustion. Is that still the case? If so what causes the heap exhaustion? I think that part of the heap problem for me was the recent bug in Jasper which I fixed where a number of resources such as Node trees from a JSP page compile were not dereferenced between compiles. This was fixed in Jasper before the 4.1.20 release. We've looked high and low, with JProbe etc, and we still can't find where the leak is. We're having to restart a Tomcat (4.1.20) with -Xms and -Xmx both set to 256M every 4 days or so. Does the increase in memory usage correlate with an increased number of connectors due to a spike in request volume? Perhaps you should try increasing the heap size. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tracking memory usage over time
Glenn, several months ago you had posted a URL to a document (at kinetic.more.net if I remember correctly) where you talked about having to restart your production Tomcat(s) every 4 weeks or so due to Heap exhaustion. Is that still the case? If so what causes the heap exhaustion? We've looked high and low, with JProbe etc, and we still can't find where the leak is. We're having to restart a Tomcat (4.1.20) with -Xms and -Xmx both set to 256M every 4 days or so. Thanks, Adi On Fri, 14 Feb 2003 06:45:26 -0600, Glenn Nielsen [EMAIL PROTECTED] said: An easier way to measure memory usage in production is to start the JVM which runs Tomcat with the arg -verbose:gc, this will print information to stdout about each garbage collection and the memory used. I doubt if the memory leak is in Tomcat itself. The best way to find the memory leak in your application is to setup a test server and use OptimizeIt or JProbe to profile Tomcat and your web application. You can use something like JMeter to simulate load. Regards, Glenn Aditya wrote: I have the following JSP that I hit every 5 minutes and stuff the returned values into a RRD (www.rrdtool.org) to measure the memory (heap I presume) consumption of Tomcat over time. Is there a better way, short of using JMX in the newer Tomcat builds, of doing this? %@ page language=java % %@ page session=false % % long free = java.lang.Runtime.getRuntime().freeMemory(); long total = java.lang.Runtime.getRuntime().totalMemory(); out.print(free + | + total + |); % I can see a clear leak (about 20 contexts with a dozen or so hit constantly and recompiling JSPs very often) which necessitates (-Xmx and -Xms set to 256 MB) a restart of Tomcat every 4 days or so (with 4.1.14). I just upgraded to 4.1.20 thinking that the constant compiling was the source of the leak and that doesn't seem to have made a difference. Running 4.1.14 under jprobe doesn't evidence any leaks in our JSPs/filters. Hints on how to trace this leak down would be most welcome. Thanks, Adi - 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: tracking memory usage over time
On Fri, 14 Feb 2003 06:45:26 -0600, Glenn Nielsen [EMAIL PROTECTED] said: An easier way to measure memory usage in production is to start the JVM which runs Tomcat with the arg -verbose:gc, this will print information to stdout about each garbage collection and the memory used. thank you, we'll try that. I doubt if the memory leak is in Tomcat itself. The best way to find the memory leak in your application is to setup a test server and use OptimizeIt or JProbe to profile Tomcat and your web application. You can use something like JMeter to simulate load. we did run 4.1.14 under JProbe and didn't find any obvious leaks in our application/classes -- it was clearly in the Tomcat compilation. We haven't run 4.1.20 under JProbe yet. Thanks, Adi seem to have made a difference. Running 4.1.14 under jprobe doesn't evidence any leaks in our JSPs/filters. Hints on how to trace this leak down would be most welcome. Thanks, Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tracking memory usage over time
I have the following JSP that I hit every 5 minutes and stuff the returned values into a RRD (www.rrdtool.org) to measure the memory (heap I presume) consumption of Tomcat over time. Is there a better way, short of using JMX in the newer Tomcat builds, of doing this? %@ page language=java % %@ page session=false % % long free = java.lang.Runtime.getRuntime().freeMemory(); long total = java.lang.Runtime.getRuntime().totalMemory(); out.print(free + | + total + |); % I can see a clear leak (about 20 contexts with a dozen or so hit constantly and recompiling JSPs very often) which necessitates (-Xmx and -Xms set to 256 MB) a restart of Tomcat every 4 days or so (with 4.1.14). I just upgraded to 4.1.20 thinking that the constant compiling was the source of the leak and that doesn't seem to have made a difference. Running 4.1.14 under jprobe doesn't evidence any leaks in our JSPs/filters. Hints on how to trace this leak down would be most welcome. Thanks, Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt
Although bug 15845 is listed as being for 4.1.19, it looks like it affected Jasper2 even before that -- or am I reading the commit message wrong? Thanks, Adi On 26 Jan 2003 19:00:19 -, [EMAIL PROTECTED] said: glenn 2003/01/26 11:00:19 Modified: . RELEASE-NOTES-4.1.txt Log: Update release notes Revision Changes Path 1.52 +6 -1 jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt Index: RELEASE-NOTES-4.1.txt === RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- RELEASE-NOTES-4.1.txt 21 Jan 2003 23:19:56 - 1.51 +++ RELEASE-NOTES-4.1.txt 26 Jan 2003 19:00:19 - 1.52 @@ -1041,6 +1041,11 @@ PageContextImpl: pushBody()/popBody() error on tomcat 4.1.X. +[4.1.20] #15845 + Fixed JSP page compiles so that objects created for performing + the JSP page compiles which are not reused are dereferenced so + they are eligible for GC. This should reduce the memory footprint + and improve GC performance. KNOWN ISSUES IN THIS RELEASE: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat id in AccessLogValve and Spread
I'm trying to consolidate the access logs for a whole bunch of Tomcats using Spread (www.spread.org) like I do with Apache. The easiest way to do this seems to be to patch org.apache.catalina.valves.AccessLogValve to use Spread and I've done that trivially. However, now that I am collecting access logs from multiple Tomcats in a single location, I need to be able to tell which Tomcat a log line came from. Since the AccessLogValve comes from inside a Host/ stanza, I can use %v to somewhat figure out where it came from, but I run into problems when I have multiple Tomcats load-balanced by mod_jk serving the same virtual hosts. The easiest way then to tell where it came from seems to be to use the jvmRouteId -- any other, better, more easily obtained, unique identifier I can use? Thanks, Adi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
On Wed, 08 Jan 2003 19:37:28 -0800, Costin Manolache [EMAIL PROTECTED] said: The default is java.security.SecureRandom - and should give enough randomness. There is a change on head ( that would work with 5.0 - but it can be backported ) that allow you to use /dev/urandom ( or another source - it can be a pipe or something like that ). what about hashing the random part with System.currentTimeMillis() so that even the vanishingly small probability of a collision is avoided? Or would that be too expensive? Adi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
Glenn, On Mon, 06 Jan 2003 19:30:42 -0600, Glenn Nielsen [EMAIL PROTECTED] said: Thanks for reporting this. I have changed the code so that if there is no content only status codes = 400 are passed back through apache. The original patch was made so that when an error occurred at the Ajp13Processor layer it could propogated back to the browser correctly instead of a blank page being displayed. and it was a welcome fix (now, when Tomcat is being restarted, instead of the JSP being displayed as HTML, I can use a custom error page). Please test from a CVS build and let me know if this fixes the problem for you. I just updated mod_jk.c from CVS and the fix of only passing empty content errors = 400 seems to work in my quick testing. Thanks, Adi Aditya wrote: On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said: glenn 2003/01/02 04:58:58 Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0 mod_jk.c Log: Make sure http errors are handled by Apache if not handled by Tomcat Revision Changes Path 1.34 +6 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c This fix seems to cause container form-based authentication to have problems - instead of the usual sequence of: 1) GET protected page - 302 to login page 2) GET login page - 200 retrieved 3) POST login page - 302 to protected page 4) GET protected page - 200 retrieved The *first* time I try to go to the protected page, instead of (4), I get: HTTP status 400 (invalid direct reference...) However, if I then try to get the protected page a *second* time, it works fine... reverting to a verison of mod_jk that does not include the below fix doesn't evidence this problem... Adi -- 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: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c
On 2 Jan 2003 12:58:58 -, [EMAIL PROTECTED] said: glenn 2003/01/02 04:58:58 Modified: jk/native/apache-1.3 mod_jk.c jk/native/apache-2.0 mod_jk.c Log: Make sure http errors are handled by Apache if not handled by Tomcat Revision Changes Path 1.34 +6 -1 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c This fix seems to cause container form-based authentication to have problems - instead of the usual sequence of: 1) GET protected page - 302 to login page 2) GET login page - 200 retrieved 3) POST login page - 302 to protected page 4) GET protected page - 200 retrieved The *first* time I try to go to the protected page, instead of (4), I get: HTTP status 400 (invalid direct reference...) However, if I then try to get the protected page a *second* time, it works fine... reverting to a verison of mod_jk that does not include the below fix doesn't evidence this problem... Adi -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default
Glenn,
On Fri, Oct 25, 2002 at 08:40:28AM -0500, Glenn Nielsen wrote:
I suspect that for some reason the Context does not have a context
directory. Add
FWIW, I'm not running the context from a WAR file -- it's just the examples
context that comes with the default install.
String docBase = context.getRealPath(/); to your test jsp and see if it
returns null.
could you fully qualify the context Class -- if it's the same as:
pageContext.getServletContext().getRealPath(/);
then docBase returns /usr/local/tomcat/webapps/examples/ correctly. ie. if I
have just the following in the JSP:
String fullPath = pageContext.getServletContext().getRealPath(/test2.new);
out.println(brfullPath: + fullPath);
String docBase = pageContext.getServletContext().getRealPath(/);
out.println(brdocBase: + docBase);
I correctly get:
fullPath: /usr/local/tomcat/webapps/examples/test2.new
docBase: /usr/local/tomcat/webapps/examples/
however when I add:
java.io.File foo = new java.io.File(fullPath);
if (foo.exists())
out.println(Exists: + fullPath);
else {
out.println(does not exist);
}
to the JSP I get the old:
java.io.FilePermission /usr/local/tomcat/webapps/examples/test2.new read
the debug output is appended below (let me know if you want more) -- I set all
the debug flats in server.xml to 9.
Also try setting the debug attributes in your server.xml to 9 and capture
the debug output.
from localhost_examples_log:
2002-10-25 14:25:19 Authenticator[/examples]: Security checking request GET
/examples/jsp/test.jsp
2002-10-25 14:25:19 Authenticator[/examples]: Checking constraint
'SecurityConstraint[Protected Area]' against GET /jsp/test.jsp -- false
2002-10-25 14:25:19 Authenticator[/examples]: No applicable constraint
located
2002-10-25 14:25:19 Authenticator[/examples]: Not subject to any constraint
2002-10-25 14:25:19 StandardContext[/examples]: Mapping
contextPath='/examples' with requestURI='/examples/jsp/test.jsp' and
relativeURI='/jsp/test.jsp'
2002-10-25 14:25:19 StandardContext[/examples]: Trying exact match
2002-10-25 14:25:19 StandardContext[/examples]: Trying prefix match
2002-10-25 14:25:19 StandardContext[/examples]: Trying extension match
2002-10-25 14:25:19 StandardContext[/examples]: Mapped to servlet 'jsp' with
servlet path '/jsp/test.jsp' and path info 'null' and update=true
2002-10-25 14:25:27 StandardWrapperValve[jsp]: Servlet.service() for servlet
jsp threw exception
org.apache.jasper.JasperException: access denied (java.io.FilePermission
/usr/local/tomcat/webapps/examples/test2.new read)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:248)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:471)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default
On Thu, 24 Oct 2002 22:59:59 -0500, Glenn Nielsen [EMAIL PROTECTED] said: Gettting the latest version from CVS won't fix your problem. I still think the problem is somewhere in your configuration. I've installed the 4.1.12 tarball from the website and am running it without modification other than adding the test jsp to webapps/examples/jsp/test.jsp I've now tried it under: Solaris/JDK1.4 with 4.1.12-LE FreeBSD/JDK1.3.1 with 4.1.12 Debian/JDK1.3.1 with 4.1.12 with the same result. You might try posting the SecurityManager debug output when the FilePermission read is denied. Including the stack trace and the ProtectionDomain which failed. Okay, here goes -- as I mentioned before, I see this as the exception: org.apache.jasper.JasperException: access denied (java.io.FilePermission /usr/local/tomcat/webapps/examples/test2.new read) and with the following CATALINA_OPTS=-Djava.security.debug=access,failure I get this in logs/catalina.out: access: access denied (java.io.FilePermission /usr/local/tomcat/webapps/examples/test2.new read) java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1071) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:259) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:542) at java.lang.SecurityManager.checkRead(SecurityManager.java:887) at java.io.File.exists(File.java:677) at org.apache.jsp.test_jsp._jspService(test_jsp.java:53) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:136) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:471) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:256)
Re: DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default
Glenn, On Thu, Oct 24, 2002 at 10:03:47AM -, [EMAIL PROTECTED] wrote: This must be a problem in your local system configuration. Check the unix file ownerhsip and permissions for test2.new. I've done that and the fact is that it works fine without the security manager so it's not a unix file ownership and permissions problem. Also try running Tomcat with java property -Djava.security.debug=access,failure defined and then check the security manager debug output. yup, done that and the output has nothing more than the failure of read permissions. I just tested the jsp you posted with a fresh build of Tomcat 4.1 from the CVS head (What will be Tomcat 4.1.13) and Jasper 2. The FilePermission read for the context directory is being granted automatically and the JSP works. I just read the 4.1.13 announcement from Remy and it has the following note: IMPORTANT NOTE: Security manager functionality is broken in this milestone. This will be fixed in the next milestone. This milestone will not be proposed for official release, and should be used for testing purposes only. so before I checkout a fresh copy from CVS, need I be worried about this? Thanks, Adi -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
