Re: DO NOT REPLY [Bug 35128] - Cannot pass "-ea" to Tomcat JRE

[Aditya Ahuja]

My email address has changed to [EMAIL PROTECTED]

I require this info urgently....

[Aditya Gujarathi]

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  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]

byterange/byte-serving with mod_jk

[Aditya]

I have a servlet returning PDF stored as a large-object in a database. I was
recently asked why "byte-serving" wasn't turned on and I'm at a loss to try to
understand the situation. From what I've found/understood:

- byte-serving is the term Adobe uses when "chunks" of a PDF are returned by
the server, each with a "byterange" header so that the PDF display program can
start displaying immediately instead of having to wait for the entire file to
be downloaded

- AFAICT, Apache supported this automatically starting in 1.3.14 or so, and it
seems implictly enabled in Apache 2.0 according to:

  http://httpd.apache.org/docs-2.0/developer/filters.html

- it sounds like even if there was a way to convince mod_jk to support this,
it wouldn't really work since you can't "stream" the response to the client
from Tomcat via mod_jk via Apache

- and since the entire PDF would be returned as part of a single SQL request,
it doesn't provide any efficiency/performance gain for Tomcat or even Apache

I'm running Tomcat 4.1 fronted by mod_jk 1.2.5-dev with Apache 2.0.46

So is there anything I'm missing? is there a way to implement short of serving
the PDFs from disk directly by Apache?

thanks,
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?]

[Aditya]

> 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]

Filter access to response object [was Re: domain-wide sessioncookies?]

[Aditya]

> 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: domain-wide session cookies?

[Aditya]

> 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]

Re: domain-wide session cookies?

[Aditya]

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?

[Aditya]

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]

[Aditya]

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]

memory leak on context reload or stop/start? [was Re: trackingmemory usage over time]

[Aditya]

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]

How many Loggers in a stanza? [was Re: Tomcat "id" inAccessLogValve and Spread]

[Aditya]

I've written a new class that extends o.a.c.logger.LoggerBase (using
spread - www.spread.org) and can be used as a  in server.xml;
AFAICT it works fine and does what I wanted it to do. However it seems
that there can only be one  section per container which means
I can't have (for testing purposes at least) something like this:








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]

Re: tracking memory usage over time

[Aditya]

> On Tue, 25 Feb 2003 22:08:41 -0600, Glenn Nielsen <[EMAIL PROTECTED]> said:
> Does the increase in memory usage correlate with an increased number
> of connectors due to a spike in request volume?

There does not seem to be a correlation between a request spike and
un-gc'able heap usage.  I'm using mod_jk (1.2.2 from CVS) with the
following in server.xml:



In our "Tomcat Performance Tuning and Troubleshooting" ApacheCon presentation I see 
that you have a connectionTimeout="0" attribute -- however I don't see that documented 
at:

  http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/jk.html

is it something I should set/know about? I currently see 30
ESTABLISHED TCP connections between the tomcat server and the apache server...

> Perhaps you should try increasing the heap size.

In the hopes that the "plateau" is higher than around 100 Megs free?

Thanks,
Adi


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tracking memory usage over time

[Aditya]

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

[Aditya]

> 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]

Re: tracking memory usage over time

[Aditya]

> On Fri, 14 Feb 2003 05:14:33 -0800 (PST), Peter Lin <[EMAIL PROTECTED]> said:
> Is there any particular reason the pages are recompiled frequently?
> If you're using tomcat 4.1.12 or newer, it should use Ant to compile
> the pages, which should get around the issue of memory leak due to
> page compilation.

we're using jikes for the page compilation and running 4.1.20 so AFAIK
there are no known leaks due to page compilation. The reason for the
frequent recompilation is that the machine is a development server.

Adi

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

tracking memory usage over time

[Aditya]

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]

4.1.20 release date? [re bug 15845]

[Aditya]

Is there an interim build with this patch applied (I can't see
anything in the nightly builds on jakarta.apache.org)? If not, is
there a target date for 4.1.20? Building from source is an adventure
I'd rather not have at this point.

Thanks,
Adi

> On Sun, 26 Jan 2003 20:35:20 -0600, Glenn Nielsen <[EMAIL PROTECTED]> said:
> You read it correctly. AFAIK, all previous versions of jasper held
> on to objects which it no longer needed after a JSP compile.

> Glenn

> Aditya wrote: 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]>

-
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

[Aditya]

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:   
For additional commands, e-mail: 

Tomcat "id" in AccessLogValve and Spread

[Aditya]

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  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:   
For additional commands, e-mail: 

Re: Duplicate session IDs are *common*

[Aditya]

> 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:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0mod_jk.c

[Aditya]

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

[Aditya]

> 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:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default

[Aditya]

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("fullPath: " + fullPath);

  String docBase = pageContext.getServletContext().getRealPath("/");
  out.println("docBase: " + 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
org.apache.catalina.valves.ErrorReportValve.i

Re: DO NOT REPLY [Bug 13907] - security manager does not give readpermission on a context by default

[Aditya]

> 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

[Aditya]

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:   
For additional commands, e-mail: