Re: [VOTE] Branch j-t-c for Tomcat 5

[Costin Manolache]

Bill Barker wrote:

> I, personally, think that it's time for a branch in j-t-c.  At this point,
> even Tomcat 3.3 won't build against the HEAD.
> 
> My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch
> (e.g.
> coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3
> and Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the
> HEAD.
> 
> [X] +1 I Support the idea of a branch, and will help maintain it.
> [ ] +0 I like the idea
> [ ] -0 I don't like the idea
> [ ] -1 I'm against the idea of branching
> 

We can branch at tomcat_4_19 tag - that's the simplest solution.

Sorry for the mess - but I think the benefits of knowing what happens
inside tomcat are worth the extra dependencies and some temporary build
problems ( and an extra branch ).

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Costin Manolache]

Bill Barker wrote:

>> I saw a significant, measureable improvement in performance when I
> upgraded
>> our production systems to Jasper 2 with tag pooling from Jasper 1
>> without. CPU load on the production server dropped around 30%, request
>> latency was
>> reduced significantly, etc.  The app server handles 30k-100K requests per
> day.
>> This is on a Sun dual CPU E250, 768MB of Ram, that is run solely as an
>> app
> server.
>> OS is Solaris 8, JVM is 1.3.1 using HotSpot server, and I have spent time
> tuning
>> the JVM stack and GC java startup args.
>>
>> Tag pooling elminates significant amounts of GC.  That is where the real
>> benefit of tag pooling comes from.  With tag pooing the frequency and
>> length of GC's are reduced a great deal.
>>
> 
> I saw just the opposite.  Jasper2 with tag-pooling was a real dog (the
> time spent in synchronized methods to maintain the pool completely swamped
> any
> benefit from GC).  After patching my copy to make don't-tag-pool the
> default (since there isn't any way to do this in the config :( ), then
> Tomcat 4.1/Jasper2 was about 60% faster that Tomcat 3.3/Jasper1 when I
> 'ab' benchmarked it against one of my more complex pages.


Yes, I've seen similar results - tag libs are very tricky from a performance
point of view.

The problem is that jasper does a lot of synchronization - it is a problem
with the tagpool implementation, not an indication that creating tons of 
garbage is good. You can make the whole tag reuse be sync-free,
and have the entire page served without any allocation - just create the
tags once, at init time - and keep them in a per/thread data. 


Costin





 






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] Branch j-t-c for Tomcat 5

[Bill Barker]

I, personally, think that it's time for a branch in j-t-c.  At this point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch (e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3 and
Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the HEAD.


[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Bill Barker]

- Original Message -
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 7:04 PM
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked


> Costin Manolache wrote:
> > Hans Bergsten wrote:
> >
> >
> >>evaluation all in one place. To make things even easier, these tag
> >>handlers can _not_ be reused at all. Benchmarks with modern JVMs show
> >>that the gain from reuse is not worth all the trouble. So, for new
> >>tags we recommend using the SimpleTag API which takes care of the
> >>problem by forbidding reuse.
> >
> >
> > Wow. I would be _very_ curious to see those benchmarks and the "modern"
> > JVM that was used.
> >
> > All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is
well
> > worth the trouble - at least if you have 100s of requests per second
> > ( it is not worht the trouble for very low loads ). But I'm happy to
> > hear that I'm wrong.
> >
> > Costin
>
> Hear, Hear!!
>
> I saw a significant, measureable improvement in performance when I
upgraded
> our production systems to Jasper 2 with tag pooling from Jasper 1 without.
> CPU load on the production server dropped around 30%, request latency was
> reduced significantly, etc.  The app server handles 30k-100K requests per
day.
> This is on a Sun dual CPU E250, 768MB of Ram, that is run solely as an app
server.
> OS is Solaris 8, JVM is 1.3.1 using HotSpot server, and I have spent time
tuning
> the JVM stack and GC java startup args.
>
> Tag pooling elminates significant amounts of GC.  That is where the real
> benefit of tag pooling comes from.  With tag pooing the frequency and
> length of GC's are reduced a great deal.
>

I saw just the opposite.  Jasper2 with tag-pooling was a real dog (the time
spent in synchronized methods to maintain the pool completely swamped any
benefit from GC).  After patching my copy to make don't-tag-pool the default
(since there isn't any way to do this in the config :( ), then Tomcat
4.1/Jasper2 was about 60% faster that Tomcat 3.3/Jasper1 when I 'ab'
benchmarked it against one of my more complex pages.

> Glenn
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionId.java

[billbarker]

billbarker2003/01/17 19:29:03

  Modified:src/share/org/apache/tomcat/modules/session SessionId.java
  Log:
  Fix session cookie for MSIE/Mac.
  
  Reported by: Costin
  
  Revision  ChangesPath
  1.22  +2 -2  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java
  
  Index: SessionId.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- SessionId.java31 Oct 2002 06:24:59 -  1.21
  +++ SessionId.java18 Jan 2003 03:29:03 -  1.22
  @@ -367,9 +367,9 @@
// the only one supported by all browsers
StringBuffer buf = new StringBuffer();
buf.append( "JSESSIONID=" ).append( reqSessionId );
  - buf.append( ";Path=" ).append(  sessionPath  );
  + buf.append( "; Path=" ).append(  sessionPath  );
if( secureCookie && rrequest.isSecure() ) {
  - buf.append(";Secure");
  + buf.append("; Secure");
}
response.addHeader( "Set-Cookie",
buf.toString());
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Glenn Nielsen]

Costin Manolache wrote:

Hans Bergsten wrote:



evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
problem by forbidding reuse.



Wow. I would be _very_ curious to see those benchmarks and the "modern"
JVM that was used. 

All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well
worth the trouble - at least if you have 100s of requests per second
( it is not worht the trouble for very low loads ). But I'm happy to
hear that I'm wrong.

Costin

Hear, Hear!!

I saw a significant, measureable improvement in performance when I upgraded
our production systems to Jasper 2 with tag pooling from Jasper 1 without.
CPU load on the production server dropped around 30%, request latency was
reduced significantly, etc.  The app server handles 30k-100K requests per day.
This is on a Sun dual CPU E250, 768MB of Ram, that is run solely as an app server.
OS is Solaris 8, JVM is 1.3.1 using HotSpot server, and I have spent time tuning
the JVM stack and GC java startup args.

Tag pooling elminates significant amounts of GC.  That is where the real
benefit of tag pooling comes from.  With tag pooing the frequency and
length of GC's are reduced a great deal.

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Cookies, space and MSIE

[Remy Maucherat]

Costin Manolache wrote:

It seems MSIE on mac ( aparently both 9 and X ) is failing
to parse the Cookie if tomcat is used in secure mode ( with
SSL enabled ). ( it doesn't matter on which platform you run
tomcat - the browser is broken ).

I added the extra space - and the problem went away.

Remy - should we backport this to 4.1 ( and 4.0 ) ? I made 
the change in 5.0, and did the tests with a patched 4.1.

+1 for backporting.


The problem is:
 Path=/foo;Secure  -> fails
 Path=/foo; Secure -> works

The examples in the Netscape specification of the Cookie include
space after ; - and don't explicitely say the space is optional.


Yes, I read your explanation in the commit message.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Building TC5

[Remy Maucherat]

Kevin Jones wrote:

Still doesn't work for me I get

BUILD FAILED
file d:\xxx\jakarta-servletapi5/jsr154/build.xml:67: srcdir
"d:\xxx\jakarta-servletapi5/jsr154/src/share" does not exist

where xxx is shorthand for the tomcat.source directory mentioned in the
instructions,


That directory must exist after a checkout. You should remove everything 
in the directory and start over.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Cookies, space and MSIE

[Costin Manolache]

It seems MSIE on mac ( aparently both 9 and X ) is failing
to parse the Cookie if tomcat is used in secure mode ( with
SSL enabled ). ( it doesn't matter on which platform you run
tomcat - the browser is broken ).

I added the extra space - and the problem went away.

Remy - should we backport this to 4.1 ( and 4.0 ) ? I made 
the change in 5.0, and did the tests with a patched 4.1.

The problem is:
 Path=/foo;Secure  -> fails
 Path=/foo; Secure -> works

The examples in the Netscape specification of the Cookie include
space after ; - and don't explicitely say the space is optional.


Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Hans Bergsten]

Tim Moore wrote:

[...]
I thought the benefit of Tag.release and pooling was that I could create
a tag that does something expensive at init time (acquire a DB
connection, read a file, whatever) and reuse those resources until
released.  Maybe that's a bad practice?  But then what's the advantage
of having release called only once before GC?


Yes, that was the idea, and since the "classic" API is still part of
JSP 2.0, you can use it for this type of tag handler if you need it.
Most tag handler's don't need it though (you can often cache the
expensive objects elsewhere, such as in the application or session
scope). So for the majority of case, the SimpleTag API will be the
best fit.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat "id" in AccessLogValve and Spread

[Tim Funk]

You can declare your own custom pattern in AccessLogValve in server.xml. 
Then you can always hardcode your "id" into the pattern.

-Tim

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





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Hans Bergsten]

Costin Manolache wrote:

Hans Bergsten wrote:



evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
problem by forbidding reuse.



Wow. I would be _very_ curious to see those benchmarks and the "modern"
JVM that was used. 

All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well
worth the trouble - at least if you have 100s of requests per second
( it is not worht the trouble for very low loads ). But I'm happy to
hear that I'm wrong.

I'll try to find the figures we looked at and post them, or run a new
benchmark against TC 4.1 with and without tag handler pooling enabled.
But it may take some time, because right now I'm busy with other stuff.
If you disagree with the decision, you may want to send your feedback
to the EG: [EMAIL PROTECTED] JSP 2.0 is still just PFD.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Tim Moore]

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 17, 2003 5:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> Hans Bergsten wrote:
> 
> > evaluation all in one place. To make things even easier, these tag 
> > handlers can _not_ be reused at all. Benchmarks with modern 
> JVMs show 
> > that the gain from reuse is not worth all the trouble. So, for new 
> > tags we recommend using the SimpleTag API which takes care of the 
> > problem by forbidding reuse.
> 
> Wow. I would be _very_ curious to see those benchmarks and 
> the "modern" JVM that was used. 
> 
> All my tests ( including JDK1.4, IBM vms, GCJ ) show that 
> reusing is well worth the trouble - at least if you have 100s 
> of requests per second ( it is not worht the trouble for very 
> low loads ). But I'm happy to hear that I'm wrong.
> 
> Costin

I thought the benefit of Tag.release and pooling was that I could create
a tag that does something expensive at init time (acquire a DB
connection, read a file, whatever) and reuse those resources until
released.  Maybe that's a bad practice?  But then what's the advantage
of having release called only once before GC?

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat "id" in AccessLogValve and Spread

[Michael Heinrichs]

I would also like to add functionality to the AccessLogValve, and a 
subclass would be fine for my purposes, but currently, 
org.apache.catalina.valves.AccessLogValve is declared final, presumably 
for performance reasons.  Is there any chance of changing that?

Mike

Shapira, Yoav wrote:

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


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Costin Manolache]

Hans Bergsten wrote:

> evaluation all in one place. To make things even easier, these tag
> handlers can _not_ be reused at all. Benchmarks with modern JVMs show
> that the gain from reuse is not worth all the trouble. So, for new
> tags we recommend using the SimpleTag API which takes care of the
> problem by forbidding reuse.

Wow. I would be _very_ curious to see those benchmarks and the "modern"
JVM that was used. 

All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well
worth the trouble - at least if you have 100s of requests per second
( it is not worht the trouble for very low loads ). But I'm happy to
hear that I'm wrong.

Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16224] New: - Unable to use page scope in action

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16224

Unable to use page scope in   action

   Summary: Unable to use page scope in   action
   Product: Tomcat 5
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a tag that looks like this

<%@ attribute name='author' %>
<%@ attribute name='title' %>

${author}
${title}


and a page like this

<%@ taglib prefix="b" tagdir="/WEB-INF/tags" %>



The book that Joseph Heller wished was never written. A riveting story of
Yossarian's escape from Pianosa.

${desc}


when executed the ${desc} variable isn't found. If I change the tag to



still no luck. However



works as does application and session

Kevin Jones
Developmentor

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tomcat "id" in AccessLogValve and Spread

[Shapira, Yoav]

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:   
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: Building TC5

[Jeanfrancois Arcand]

Hi Kevin,

I've just commited a fix for build.properties.default. You should try:

cvs checkout jakarta-tomcat-5
cd jakarta-tomcat-5
ant download
ant checkout
ant dist

I've just did it from a clean workspace and everything works fine.

-- Jeanfrancois

Kevin Jones wrote:


Still doesn't work for me I get

BUILD FAILED
file d:\xxx\jakarta-servletapi5/jsr154/build.xml:67: srcdir
"d:\xxx\jakarta-servletapi5/jsr154/src/share" does not exist

where xxx is shorthand for the tomcat.source directory mentioned in the
instructions,

Kevin

On Fri, 2003-01-17 at 17:30, Remy Maucherat wrote:
 

Kevin Jones wrote:
   

Thanks Remy,

I assume you mean I should start from scratch again?
 

Yes, follow these instructions: 
http://jakarta.apache.org/tomcat/building.html

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

   



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 

cvs commit: jakarta-tomcat-5 build.properties.default

[jfarcand]

jfarcand2003/01/17 12:30:30

  Modified:.build.properties.default
  Log:
  Force target name download to checkout modeler using cvs (not using the URL)
  
  Revision  ChangesPath
  1.57  +2 -2  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.56
  retrieving revision 1.57
  diff -u -r1.56 -r1.57
  --- build.properties.default  16 Jan 2003 22:00:52 -  1.56
  +++ build.properties.default  17 Jan 2003 20:30:30 -  1.57
  @@ -139,7 +139,7 @@
   #commons-modeler.lib=${commons-modeler.home}
   commons-modeler.lib=${commons-modeler.home}/dist
   commons-modeler.jar=${commons-modeler.lib}/commons-modeler.jar
  
-commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz
  
+#commons-modeler.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-modeler/v1.0/commons-modeler-1.0.tar.gz
   commons-modeler.cvs.loc=jakarta-commons/modeler
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Building TC5

[Kevin Jones]

Still doesn't work for me I get

BUILD FAILED
file d:\xxx\jakarta-servletapi5/jsr154/build.xml:67: srcdir
"d:\xxx\jakarta-servletapi5/jsr154/src/share" does not exist

where xxx is shorthand for the tomcat.source directory mentioned in the
instructions,

Kevin

On Fri, 2003-01-17 at 17:30, Remy Maucherat wrote:
> Kevin Jones wrote:
> > Thanks Remy,
> > 
> > I assume you mean I should start from scratch again?
> 
> Yes, follow these instructions: 
> http://jakarta.apache.org/tomcat/building.html
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 15851] - Parser generates a NullPointerException for invalid use case of jsp:attribute instead of a useful message.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15851

Parser generates a NullPointerException for invalid use case of jsp:attribute instead 
of a useful message.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 20:15 ---
NPE no longer occurs, but error message:

  jsp:attribute must be the subelement of a standard or custom action

is not what we want:

  a jsp:attribute standard action cannot be nested within another jsp:attribute
  standard action

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Hans Bergsten]

Tim Moore wrote:

[...]
I agree that the current behavior of release should not change.  There
are important uses for long-term state that we shouldn't throw away just
because of some confusion.


Right.


But what do you think about the idea of adding a new method?  My
thinking is that if there were a reset method where people could reset
invocation-local state, then it would be easier for people to understand
the correct purpose of release in contrast.  I know there are perfectly
good ways to reset now, so this change would be more for psychological
reasons than technical ones.  You have to admit, though, the fact that
this misunderstanding is so common does say something about the clarity
of the API.  I made this mistake initially, and I believe many of the
Jakarta tags did as well.


Yes, the whole reuse things was pretty much unspecified in JSP 1.1.
When we tried to clarify it in JSP 1.2, we discussed adding a reset()
method at length (the reuse discussions are by far the most intense
discussions in the JSP EG ;-) but in the end decided to keep the API
backwards compatible and bolt reuse on top of it (with the various
rules for when release() can be called, only reuse for the same
attribute set, etc.). In hindsight, I think it was a mistake, but that
boat has sailed. See below.


I also know that adding methods to an interface can be problematic for
backwards compatibility reasons, but if a noop implementation is added
to TagSupport, that would handle 90% of the problem.

What do you think?


That's the main reason that we decided to not add a method in JSP 1.2,
and the same applies to JSP 2.0. Even though you can minimize the
problem by adding a noop in TagSupport, you're still not covering 100%
of the cases.

Another reason for not doing this in JSP 2.0 is that JSP 2.0 introduces
a new tag handler API: SimpleTag. This API has a much simpler lifecycle,
basically just attribute setters and one doTag() method that, coupled
with the new JspFragment API, handles iterations and accessing the body
evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
problem by forbidding reuse.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Apprentice Seeks Master

[Conrad T. Pino]

Tomcat apprentice seeks Master to provide guidance and
training to execute a bug hunt on an obscure platform.

Apprentice has posted bug report at:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16106

and would greatly appreciate a Master's interpretation
of the IllegalAccess stack trace.

Please reply directly as apprentice is not yet worthy
of joining tomcat-dev mailing list.

Always there are two...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

[luehe]

luehe   2003/01/17 12:03:10

  Modified:jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  Escape '<'
  
  Revision  ChangesPath
  1.80  +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.79
  retrieving revision 1.80
  diff -u -r1.79 -r1.80
  --- messages.properties   13 Jan 2003 23:50:48 -  1.79
  +++ messages.properties   17 Jan 2003 20:03:10 -  1.80
  @@ -274,7 +274,7 @@
   jsp.error.empty.body.not.allowed=Empty body not allowed for {0}
   jsp.error.jspbody.required=Must use jsp:body to specify tag body for {0} if 
jsp:attribute is used.
   jsp.error.jspbody.emptybody.only=The {0} tag can only have jsp:attribute in its 
body.
  -jsp.error.no.scriptlets=Scripting elements ( <%!, mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Parser.java

[luehe]

luehe   2003/01/17 12:02:25

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  Fixed 16088: Translation error not generated if body of jsp:attribute, providing an 
attribute value of type JspFragment, contains a scripting element
  
  Revision  ChangesPath
  1.57  +5 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.56
  retrieving revision 1.57
  diff -u -r1.56 -r1.57
  --- Parser.java   13 Jan 2003 23:50:48 -  1.56
  +++ Parser.java   17 Jan 2003 20:02:25 -  1.57
  @@ -1702,7 +1702,8 @@
   reader.skipSpaces();
   }
   parseBody(namedAttributeNode, "jsp:attribute", 
  -   TagInfo.BODY_CONTENT_JSP);
  +   getAttributeBodyType(parent,
  +attrs.getValue("name")));
   if (namedAttributeNode.isTrim()) {
   Node.Nodes subElems = namedAttributeNode.getBody();
if (subElems != null) {
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16088] - Translation error not generated if body of jsp:attribute, providing an attribute value of type JspFragment, contains a scripting element

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16088

Translation error not generated if body of jsp:attribute, providing an attribute value 
of type JspFragment, contains a scripting element

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

MissingResourceException on ResourceBundle.getBundle()

[Manveen Kaur]

Hi,

I have a web-app that looks up a properties file.

I'm getting a java.util.MissingResourceException on ResourceBundle.getBundle(..);
The jar containg the properties file is in WEB-INF/lib.

Is this a classpath issue? Is there a workaround?

Any help would be greatly appreciated.

thanks
Manveen



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Tim Moore]

> -Original Message-
> From: Hans Bergsten [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 17, 2003 1:37 PM
> To: Tomcat Developers List
> Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> Tim Moore wrote:
> > This bug seems to be submitted several times a week.  Maybe an FAQ 
> > would be in order? (or FOB -- frequently opened bugs haha)
> > 
> > Then again, if people don't search the bug database before 
> submitting 
> > a new one, then I guess they can't be expected to read the FAQ.
> > 
> > And on the other hand, if the spec confuses this many people, maybe 
> > that should be fed back to the spec authors.  Just adding a "reset" 
> > method to Tag that is called before each invocation might 
> help people 
> > understand the difference between that and release.
> 
> I'm in the EG and we had a long discussion about this again 
> for JSP 2.0. The end result is that the current behavior (do 
> _not_ call release() between invocations) will stay. A 
> confusing arrow from the "released" state to the 
> "initialized" state in the state diagram will be removed, 
> however. This state transition came with lots and lots of 
> restrictions, but it seems like some vendor (and developers) 
> saw it as a requirement to call release() between 
> invocations, even though the text clearly state that that's 
> not the case.
> 

I agree that the current behavior of release should not change.  There
are important uses for long-term state that we shouldn't throw away just
because of some confusion.

But what do you think about the idea of adding a new method?  My
thinking is that if there were a reset method where people could reset
invocation-local state, then it would be easier for people to understand
the correct purpose of release in contrast.  I know there are perfectly
good ways to reset now, so this change would be more for psychological
reasons than technical ones.  You have to admit, though, the fact that
this misunderstanding is so common does say something about the clarity
of the API.  I made this mistake initially, and I believe many of the
Jakarta tags did as well.

I also know that adding methods to an interface can be problematic for
backwards compatibility reasons, but if a noop implementation is added
to TagSupport, that would handle 90% of the problem.

What do you think?
-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Q] Where was vulnerability fixed?

[Sam]

Thanks.  I was specifically looking for the file that contained
the delta.  Eventually I found it in jk_ajp_common.c rev 1.33.

-Sam

--- Henri Gomez <[EMAIL PROTECTED]> wrote:
> Sam wrote:
> > http://online.securityfocus.com/archive/1/302169/2002-12-03/2002-12-09/2
> > 
> > This vulnerability was reported last month.  The report
> > says mod_jk 1.2.1 as fixing the vulnerability.
> > Yet I have searched Bugzilla for reference to this vuln.
> > as well as looking at mod_jk.c to see what revision was
> > changed, but I have not been able to locate this change.
> > 
> > Can anyone shed some light as to whether this vuln. was fixed
> > or not, and if so, and what source file(s) were changed?  
> > I cannot seem to find it.
> 
> jk 1.2.1 should have fixed this, and we're today at jk 1.2.2 release.
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 19:43 ---
A note from Hans Bergsten, for reference.

I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16211

Classloader problems with Xerces





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 19:24 ---
I would never imagine that Xerces is actually blocked from loading, since I'm
running, as I said, on JDK 1.3.1_06... :-)))

But, I have a few more words:

1) I think Tomcat docs must be updated then, because it contains the following
wrong explanation (Classloader HOW-TO -> Class loader definitions -> Common):

"xerces.jar - The XML parser that is visible by default to Tomcat internal
classes and to web applications. This can be overridden, for a particular web
application, by including your desired parser in /WEB-INF/lib."

2) So, it's just impossible to use a parser different from that used by the
Tomcat internals? (is that Xerces 2.2.0?) I can use a parser only if it's
compatible with Tomcat?

I hope I'm wrong...

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Hans Bergsten]

Tim Moore wrote:

This bug seems to be submitted several times a week.  Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors.  Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.


I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16211

Classloader problems with Xerces





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 18:19 ---
Well, let try to clarify a little bit more. From the Servlet specs:

SRV.9.7.2 Web Application Classloader
The classloader that a container uses to load a servlet in a WAR must allow the
developer to load any resources contained in library JARs within the WAR
following normal J2SE semantics using getResource. It must not allow the WAR to
override J2SE or Java servlet API classes. It is further recommended that the
loader not allow servlets in the   WAR access to the web container’s
implementation classes. 

Xerces package contains file that are included with J2SE (org.w3c.*) and also
contain JAXP interface.

Thats's why we are bloking the loading of Xerces localed under /lib.

Hope that clarify better than the first message :-)

-- Jeanfrancois

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16211

Classloader problems with Xerces





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 17:37 ---
Forgot to say: I'm using JDK 1.3.1_06

"This is the proper behaviour."

Sounds like a contradiction to me, as Tomcat docs says that the WEB-INF/lib
location is searched before the Tomcat's endorsed dir, and it seems (see the
NoSuchMethodError stack trace) that this is not the actual behaviour.

This is not exactly a new problem: I don't care about the endorsed or internal
libraries of Tomcat, since my application carries all needed jars on it's
WEB-INF/lib directory.

"You need to change the Xerces version under endorsed dir if you want to use
Xerces 2.0.1 (like you do)"

And what if I've used a Xerces version not compatible with Tomcat? This would
not work, right? This way, I need to tie all my running applications to a single
Xerces version! This is not always desired...

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Building TC5

[Remy Maucherat]

Kevin Jones wrote:

Thanks Remy,

I assume you mean I should start from scratch again?


Yes, follow these instructions: 
http://jakarta.apache.org/tomcat/building.html

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Building TC5

[Kevin Jones]

Thanks Remy,

I assume you mean I should start from scratch again?

Kevin

On Fri, 2003-01-17 at 17:12, Remy Maucherat wrote:
> Kevin Jones wrote:
> > I'm trying to build TC 5 from sources and failing horribly.
> > 
> > Firstly I connected to cvs and checked out jakarta-tomcat-5 this
> > contains a buildme.txt file. Reading this, I followed the instructions,
> > downloaded the build.xml and ran ant.
> > 
> > This proceeeds to download all the appropriate files and starts the
> > build, but this fails when it gets to the build-tomcat-coyote
> > (compile.tomcat5) step. The first problem here was that the wrong value
> > was being specified for catalina.home so servlet-api.jar wasn't being
> > found. After fixing that I'm still getting compile errors telling me
> > that various org.apache.catalina classes can't be found.
> > 
> > I've seen various comments on here that building from sources is easy,
> > so what am I missing? :-)
> 
> The main build script is broken. Try again.
> 
> I'll let Costin reapply a fixed version of his patch.
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Building TC5

[Remy Maucherat]

Kevin Jones wrote:

I'm trying to build TC 5 from sources and failing horribly.

Firstly I connected to cvs and checked out jakarta-tomcat-5 this
contains a buildme.txt file. Reading this, I followed the instructions,
downloaded the build.xml and ran ant.

This proceeeds to download all the appropriate files and starts the
build, but this fails when it gets to the build-tomcat-coyote
(compile.tomcat5) step. The first problem here was that the wrong value
was being specified for catalina.home so servlet-api.jar wasn't being
found. After fixing that I'm still getting compile errors telling me
that various org.apache.catalina classes can't be found.

I've seen various comments on here that building from sources is easy,
so what am I missing? :-)


The main build script is broken. Try again.

I'll let Costin reapply a fixed version of his patch.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 build.xml

[remm]

remm2003/01/17 09:05:34

  Modified:.build.xml
  Log:
  - Revert to revision 1.62 of the build script.
  
  Revision  ChangesPath
  1.64  +26 -112   jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.63
  retrieving revision 1.64
  diff -u -r1.63 -r1.64
  --- build.xml 16 Jan 2003 23:14:02 -  1.63
  +++ build.xml 17 Jan 2003 17:05:34 -  1.64
  @@ -5,7 +5,6 @@
   
 
 
  -  
 
 
 
  @@ -66,10 +65,9 @@
   
   
   
  -
  -
  +
 
   
   
  @@ -92,17 +90,17 @@
 
   
   
  -
 
   
   
  -
 
   
   
  -
 
   
  @@ -150,14 +148,12 @@
   
 
   
  -  
  +  
   == Building: tomcat-jk 
   
  -
  +
 
  -  
 
  -  
 
   
 
  @@ -171,95 +167,39 @@
   
 
   
  -  
   == Building: tomcat-coyote 
   
  -
  +
 
  -  
 
  -  
 
   
 
   
  -  
   == Building: tomcat-http11 
   
  -
  +
 
 
  -  
 
  -  
   
 
   
  -  
  -== Building: admin to  ${tomcat.build}/server/webapps 
  +  
  +== Building: admin 
   
  -  
  +  
 
   
   
  -
  -
  -
  -
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -
  -
  -  
  -  
  -
  -
  -
  +
 
   
 == Building: catalina 
   
  -
  -
  -
  +
  +
   
  -
   
  +
   
   
  -
  +
   
  -
  +
   
  -
  +
 
   == Building: jasper 
   
  @@ -314,7 +251,7 @@
 
   == Building: commons-modeler 
   
  -
  +
   
   
   
  @@ -342,11 +279,7 @@
   
   
   Target: Catalina - Deploy ...
  -
  -
  -
  -
  -
  +
   
 
   
  @@ -1057,9 +990,6 @@
   
  -
 
   
   
  @@ -1070,21 +1000,5 @@
 
   
 
  -
  -  
  -  
  -
  -  
  -  
  -
  -
  -
  -
  -  
  -
  -
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Broken TC5 Nightly builds

[Kevin Jones]

As I've just posted I can't (yet) build TC from sources. The reason I
want to build from sources is that the nightly builds seem to be broken.
The directory is being created (so Jan 17th is there) but the files
aren't there.

The latest date for the nightly's is Jan 14th

Kevin Jones
Developmentor


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Building TC5

[Kevin Jones]

I'm trying to build TC 5 from sources and failing horribly.

Firstly I connected to cvs and checked out jakarta-tomcat-5 this
contains a buildme.txt file. Reading this, I followed the instructions,
downloaded the build.xml and ran ant.

This proceeeds to download all the appropriate files and starts the
build, but this fails when it gets to the build-tomcat-coyote
(compile.tomcat5) step. The first problem here was that the wrong value
was being specified for catalina.home so servlet-api.jar wasn't being
found. After fixing that I'm still getting compile errors telling me
that various org.apache.catalina classes can't be found.

I've seen various comments on here that building from sources is easy,
so what am I missing? :-)

Thanks,

Kevin Jones
Developmentor


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16178] - Unix process does not get killed when Tomcat is shutdown

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16178

Unix process does not get killed when Tomcat is shutdown





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 16:45 ---
An additional note:

We discovered that Tomcat 4.1 was not completely shutting down on our system 
because our app was spawning non-daemon threads that never terminated.  In 
Tomcat 3.x, the VM would be killed by the shutdown script, but in 4.1 it's 
expected to shutdown gracefully.  Ensure that any background threads that your 
webapp starts are stopped when the context is destroyed.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 16:39 ---
Ok guys. You're right.

I found the book (about JSP 1.1) in which a flow-chart of the life-cycle of a
tag has driven me in error.

More, there are some JSP engine (such as Weblogic that has implemented the pool
before Tomcat) where release is invoke just after the return of doEndTag, even
if specification says different.

But specs rule!

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Tim Moore]

This bug seems to be submitted several times a week.  Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors.  Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 17, 2003 10:58 AM
> To: Tomcat Developers List
> Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> Martin Algesten wrote:
> > Remy,
> > 
> > once again we agree :)
> 
> Lol, I guess. After the 100th time this bug is being reopened, I'm 
> getting pissed ;-)
> 
> Remy

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16211

Classloader problems with Xerces

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 16:17 ---
This is the proper behaviour. You cannot replace the endorsed classes. You need
to change the Xerces version under endorsed dir if you want to use Xerces 2.0.1
(like you do). See http://java.sun.com/j2se/1.4/docs/guide/standards/ for more
information. 

Please next time ask the question first on [EMAIL PROTECTED]

-- Jeanfrancois

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16211] New: - Classloader problems with Xerces

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16211

Classloader problems with Xerces

   Summary: Classloader problems with Xerces
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I'm running a JSP application, and have got some problems with the Tomcat's
classloader.

My application uses Xerces 2.0.1 (located on the application's WEB-INF/lib
directory), and Tomcat seems to use Xerces 2.2.0 (located on Tomcat's
common/endorsed directory). The exception I get when try to do some DOM
serialization using Xerces is:

--
java.lang.NoSuchMethodError
at org.apache.xml.serialize.XMLSerializer.reset(XMLSerializer.java:1516)
at
org.apache.xml.serialize.BaseMarkupSerializer.setOutputCharStream(BaseMarkupSerializer.java:335)
at org.apache.xml.serialize.XMLSerializer.(XMLSerializer.java:207)
at com.sdspb.messaging.client.XPathWrapper.toXML(Unknown Source)
at com.sdspb.messaging.client.XPathWrapper.toXML(Unknown Source)
at com.sdspb.messaging.client.XPathWrapper.writeExternal(Unknown Source)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1167)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
at
java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475)
at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361)
at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:263)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at com.sdspb.messaging.rmi.server.RMIMessagingServer_Stub.send(Unknown
Source)
at com.sdspb.messaging.rmi.client.RMIMessaging.send(Unknown Source)
at com.sdspb.messaging.presentation.MessageDispatcher.run(Unknown Source)
--

It seems that the classloader is trying to use the wrong Xerces classes, not
applying the precedence defined for Tomcat, which says that the application
local libraries are searched first:

* /WEB-INF/classes of your web application
* /WEB-INF/lib/*.jar of your web application
* Bootstrap classes of your JVM
* System class loader classses (described above)
* $CATALINA_HOME/common/classes
* $CATALINA_HOME/common/endorsed/*.jar
* $CATALINA_HOME/common/lib/*.jar
* $CATALINA_HOME/shared/classes
* $CATALINA_HOME/shared/lib/*.jar

I've tried to move the endorsed Xerces libraries to the Tomcat's "server/lib"
directory, to make sure only the Tomcat internals use the Xerces 2.2.0, but then
I get the following startup exception:

--
2003-01-17 11:36:23 ContextConfig[/contingency] Parse error in default web.xml
java.lang.NullPointerException
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:892)
at org.apache.commons.digester.Digester.parse(Digester.java:1495)
at
org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:548)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:638)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3567)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:2189)
at org.apache.catalina.startup.Catalina.start(Catalina.java:512)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstr

DO NOT REPLY [Bug 15845] - 4.1.19 Memory Leak when creating compilier for JSP pages

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15845

4.1.19 Memory Leak when creating compilier for JSP pages





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 16:10 ---
Is anyone looking into this bug, as we are finding the same problem.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Remy Maucherat]

Martin Algesten wrote:

Remy,

once again we agree :)


Lol, I guess. After the 100th time this bug is being reopened, I'm 
getting pissed ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Return of the CL bug

[Remy Maucherat]

Costin Manolache wrote:

It won't happen in JDK1.3

It won't happen if you remove the "endorsed.dirs" from the CLI.

I think endorsed is completely broken, there are many other problems
and leads to undeterministic behavior. We should just remove it and
add it back in JDK1.5 or when it is fixed.


Actually, the problem was that the "bin" directory was set as endorsed, 
and one JAR in there was including a lot of things that didn't belong. 
Nasty bug to spot ;-)

This should fix all the commons-logging CL failures users have been 
reporting (I think).

My +1 to remove the "endorsed". There is no need to use a different
version of javax.xml or org.w3c.dom or org.xml - and if someone needs
a different one, he can use JDK1.3 or file a bug report on Sun site.


With only the XML parser in there, I don't think it creates problems. If 
the user tries to use it, there could be problems, that's true ;-) It's 
a bit like allowing users to change the system classpath, actually.

BTW, I'm having issues with your latest change to the main build.xml (it 
fails trying to build Coyote).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Return of the CL bug

[Jeanfrancois Arcand]

Costin Manolache wrote:


It won't happen in JDK1.3

It won't happen if you remove the "endorsed.dirs" from the CLI.

I think endorsed is completely broken, there are many other problems
and leads to undeterministic behavior. We should just remove it and
add it back in JDK1.5 or when it is fixed.

My +1 to remove the "endorsed". There is no need to use a different
version of javax.xml or org.w3c.dom or org.xml - and if someone needs
a different one, he can use JDK1.3 or file a bug report on Sun site.


How we will supports XML schema if we remove the endorsed directory? In 
1.4, Crimson will be defaulted and Crimson doesn't supports schema :-(

-- Jeanfrancois



Costin



Remy Maucherat wrote:

 

This one looks similar to the CL problems with commons-logging (that I
don't get). If JK 2 is enabled, I get a CL error during its
initialization:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at

   

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 

at

   

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 

at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:262)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:395)
Caused by: java.lang.NoClassDefFoundError:
javax/management/MBeanRegistration
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at
java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at
java.lang.ClassLoader.loadClass(ClassLoader.java:292) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at
java.lang.ClassLoader.loadClass(ClassLoader.java:255) at

   

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)
 

at

   

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
 

at

   

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)
 

at

   

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
 

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at

   

org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:520)
 

at

   

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
 

at

   

org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
 

at

   

org.apache.coyote.tomcat5.CoyoteConnector.initialize(CoyoteConnector.java:983)
 

at

   

org.apache.catalina.core.StandardService.initialize(StandardService.java:579)
 

at

   

org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2347)
 

at org.apache.catalina.startup.Catalina.load(Catalina.java:503)
at org.apache.catalina.startup.Catalina.load(Catalina.java:521)
... 6 more

Somehow, if JMX is in endorsed, the error does not happen, as for some
odd reason, the CL thinks it is a good idea to look for the class in the
system classloader.
I did look very briefly at the problem, but can't find an explanation yet.

(like Costin, I hate classloaders)

Remy
   




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


 

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 15:29 ---

Consider reading the rest of the spec as well...
Yes tags are meant to be pooled. However .release() is NOT intended to be 
called between reuses of a tag... as the javadoc clearly states.

Even the name "release" tells us that this is not a "reinit".

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Return of the CL bug

[Costin Manolache]

It won't happen in JDK1.3

It won't happen if you remove the "endorsed.dirs" from the CLI.

I think endorsed is completely broken, there are many other problems
and leads to undeterministic behavior. We should just remove it and
add it back in JDK1.5 or when it is fixed.

My +1 to remove the "endorsed". There is no need to use a different
version of javax.xml or org.w3c.dom or org.xml - and if someone needs
a different one, he can use JDK1.3 or file a bug report on Sun site.


Costin



Remy Maucherat wrote:

> This one looks similar to the CL problems with commons-logging (that I
> don't get). If JK 2 is enabled, I get a CL error during its
> initialization:
> 
> java.lang.reflect.InvocationTargetException
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at
> 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>  at
> 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  at java.lang.reflect.Method.invoke(Method.java:324)
>  at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:262)
>  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:395)
> Caused by: java.lang.NoClassDefFoundError:
> javax/management/MBeanRegistration
>  at java.lang.ClassLoader.findBootstrapClass(Native Method)
>  at
>  java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
>  at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at
>  java.lang.ClassLoader.loadClass(ClassLoader.java:292) at
>  sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at
>  java.lang.ClassLoader.loadClass(ClassLoader.java:255) at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)
>  at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
>  at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)
>  at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
>  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
>  at java.lang.ClassLoader.defineClass0(Native Method)
>  at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
>  at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
>  at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
>  at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
>  at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
>  at java.security.AccessController.doPrivileged(Native Method)
>  at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
>  at
> 
org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:520)
>  at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
>  at
> 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
>  at
> 
org.apache.coyote.tomcat5.CoyoteConnector.initialize(CoyoteConnector.java:983)
>  at
> 
org.apache.catalina.core.StandardService.initialize(StandardService.java:579)
>  at
> 
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2347)
>  at org.apache.catalina.startup.Catalina.load(Catalina.java:503)
>  at org.apache.catalina.startup.Catalina.load(Catalina.java:521)
>  ... 6 more
> 
> Somehow, if JMX is in endorsed, the error does not happen, as for some
> odd reason, the CL thinks it is a good idea to look for the class in the
> system classloader.
> I did look very briefly at the problem, but can't find an explanation yet.
> 
> (like Costin, I hate classloaders)
> 
> Remy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Session de-serialization problem (with patch)

[Eriksson, Michael]

Just a short follup:

Will you apply the patch I sent?
(Or provide an other solution with
the same effect?)

If not, please send a response so that
we can adapt correspondingly.

Grüsse,

Michael

> -Original Message-
> From: Eriksson, Michael 
> Sent: Monday, December 16, 2002 12:04 PM
> To: [EMAIL PROTECTED]
> Cc: Eriksson, Michael
> Subject: Session de-serialization problem (with patch)
> 
> 
> Hi,
> 
> during work on session serialization my colleagues run into
> a problem with the startup order of the session manager vs
> listeners/filters.
> 
> During startup the session manager is started before the
> listeners and filters.  This implies that objects that
> depend on parts of the application can not be properly
> deserialized. (Apparently, a re-write to remove such
> dependencies is not feasible in our case.)
> 
> Further this behaviour is inconsistent with the reload
> behaviour, which was previously changed due to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=3733.
> 
> We have patched this behaviour (see attachment) to start
> listeners/filters immediately _befor_ the session manager.
> This patch solves our problem and does not seem to cause any
> new issues with our application.  However, due to the
> triviality of the patch, we have not made a thorough
> examination of the workings of o.a.c.core.StandardContext.
> Also, the patch is focused on one specific issue. It does
> not (unless by coincidence) ensure consistency in the
> reload/start behaviours.
> 
> The patch is against 4.1.16, since 4.1.17 was released after
> the patch was written.
> 
> Sincerely,
> 
> Michael Eriksson
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Martin Algesten]

Remy,

once again we agree :)

M

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: 17 January 2003 14:19
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT 
>  i?id=16001>.
> 
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE 
> COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added


 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:19
--- Your tag does not comply with the JSP specification, and, as a
result it may or may not work. This issue WILL NOT be fixed in Tomcat.
Thanks, and DO NOT REOPEN THIS BUG.

--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

getRequestURI after forward

[Eriksson, Michael]

Hallo Remy,

I have noted that request.getRequestURI in an error page
delivers the URI of the request page whereas getRequestURL
refers to the originally called resource. This is probably
the same (much more general) case described in
http://issues.apache.org/bugzilla/show_bug.cgi?id=8409.

This bug report was marked as invalid by you with the
indication that getRequestURI delivers a path element, which
according to section 8.4 in the servlet spec should be
altered accordingly when forwarding.

I am not quite sure if this interpretation is true. For one
thing section 4.4 (request path elements) explicitly lists
the methods accessing path elements
(getContextPath/ServletPath/PathInfo), but makes no mention
of getRequestURI.

It does however say:
requestURI = contextPath + servletPath + pathInfo

Further the corresponding java doc comment
(http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html#getRequestURI())
leads the reader to believe that the original request URI is
meant.

My interpretation would be that requestURI as an abstract
concept should be considered a path element that changes
with a forward. However, the _method_ getRequestURI should
(strangely inconsistent) deliver the pre-forward value.

What is your take on this?


Grüsse,

Michael

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16205] - org.apache.naming.factory.BeanFactory bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16205

org.apache.naming.factory.BeanFactory bugs





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:48 ---
Created an attachment (id=4475)
BeanFactory.java with fixed getObjectInstance method

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16205] New: - org.apache.naming.factory.BeanFactory bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16205

org.apache.naming.factory.BeanFactory bugs

   Summary: org.apache.naming.factory.BeanFactory bugs
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


1) The howto examples used the newer  inplace of . Problem is that BeanFactory does not work with . It 
just returns null.

2) BeanFactory checks for instances of a ResourceRef object, if the object 
passed isn't one BeanFactory just returns null. No error is logged or exception 
thrown. This made debugging more difficult than it should have been. It later 
casts the object to a Reference not a ResourceRef.

3) BeanFactory tries to put the value from  element into the 
object as a parameter. If it can't find a setDescription method it throws a 
NamingException.


Fixed BeanFactory.getObjectInstance() below
=

public Object getObjectInstance(Object obj, Name name, Context nameCtx,
Hashtable environment)
throws NamingException {

if (!(obj instanceof Reference)) 
throw new NamingException("Object must be instanceof 
javax.naming.Reference");

try {

Reference ref = (Reference) obj;
String beanClassName = ref.getClassName();
Class beanClass = null;
ClassLoader tcl = 
 Thread.currentThread().getContextClassLoader();
if (tcl != null) {
try {
beanClass = tcl.loadClass(beanClassName);
} catch(ClassNotFoundException e) {
}
} else {
try {
beanClass = Class.forName(beanClassName);
} catch(ClassNotFoundException e) {
e.printStackTrace();
}
}
if (beanClass == null) {
throw new NamingException
("Class not found: " + beanClassName);
}

BeanInfo bi = Introspector.getBeanInfo(beanClass);
PropertyDescriptor[] pda = bi.getPropertyDescriptors();

Object bean = beanClass.newInstance();

Enumeration e = ref.getAll();
while (e.hasMoreElements()) {

RefAddr ra = (RefAddr) e.nextElement();
String propName = ra.getType();

if (propName.equals(Constants.FACTORY) ||
propName.equals("scope") || 
propName.equals("auth") || 
propName.equals("description")) {
continue;
}

String value = (String)ra.getContent();

Object[] valueArray = new Object[1];

int i = 0;
for (i = 0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:37 ---
Ismael,

Please take a look at section 10.5 in the 1.2 spec and section 12.4 in the 2.0
spec :

"Below is a somewhat complete example of the way one JSP container could
choose to do some tag handler management. There are many other strategies that
could be followed, with different pay offs.
The example is as below. In this example, we are assuming that x:iterate is an
iterative tag, while x:doit and x:foobar are simple tag. We will also assume that
x:iterate and x:foobar implement the TryCatchFinally interface, while x:doit does
not.

” />

” />

” />
The particular code shown below assumes there is some pool of tag handlers
that are managed (details not described, although pool managing is simpler when
there are no optional attributes), and attemps to reuse tag handlers if
possible. The
code also “hoists” setting of properties to reduce the cost when appropriate, e.g.
inside an iteration."

As you can see pooling IS Mentioned. If you take a look at the example code that
follows this section you will see that release() is NOT called between tag
invocations. 

The only thing that the spec says has to happen is that release() is called
before the tag is gc'd. This could potentialy only occur when an webcontainer is
shutdown. 

I would suggest you take a look at a custom tag library like struts that
demontrates how custom tags should cleanup when used in a pooled environment.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

FW: dead links ...

[Pier Fumagalli]

> -- Forwarded Message
> From: "Adam Ferguson" <[EMAIL PROTECTED]>
> Date: Fri, 17 Jan 2003 00:29:06 -0800
> To: <[EMAIL PROTECTED]>
> Subject: dead links ...
> 

> Hello ...
>  
> I was interested in downloading the newest version of Tomcat and all the links
> I tried were dead.  Here's where it sent me:
> http://www.apache.org/dist/jakarta/jakarta-tomcat-4.0/release/v4.1.17/
>  
> Just wanted to let you know ...
> Adam Ferguson
> 


-- End of Forwarded Message

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:19 ---
Your tag does not comply with the JSP specification, and, as a result it may or
may not work. This issue WILL NOT be fixed in Tomcat.
Thanks, and DO NOT REOPEN THIS BUG.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[GUMP] Build Failure - jakarta-tomcat-5

[bobh]

This email is autogenerated from the output from:



Buildfile: build.xml

prepare-release:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes

deploy-static:

deploy:
 [echo] Target: Servlet API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr154/build
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar

dist:
 [echo] Target: JSP API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr152/build
  [jar] Building jar: 
/home/rubys/jakarta/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar

dist:
 [echo] Target: Catalina - Deploy ...

deploy-prepare:

deploy-static:

deploy-catalina:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=on
 [echo] compile.deprecation=off
 [echo] compile.optimize=on
 [echo] --- Ant Flags ---
 [echo] 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CookieTools.java

[costin]

costin  2003/01/16 21:55:41

  Modified:catalina/src/share/org/apache/catalina/util CookieTools.java
  Log:
  I am not very sure this is the right fix - but from the spec it seems
  to be ok.
  
  It seems some browsers ( some versions of IE on Mac ) have trouble parsing
  the cookie in HTTPS mode. That happens because we send
  "...path=/foo;Secure"
  
  The spec on netscape site has all examples with a space after ;, and
  aparently IE uses the space as delimiter.
  
  I'll investigate further, this is very strange...
  
  Revision  ChangesPath
  1.2   +11 -11
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CookieTools.java
  
  Index: CookieTools.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CookieTools.java  18 Jul 2002 16:47:45 -  1.1
  +++ CookieTools.java  17 Jan 2003 05:55:41 -  1.2
  @@ -122,11 +122,11 @@
   // add version 1 specific information
   if (version == 1) {
   // Version=1 ... required
  -buf.append (";Version=1");
  +buf.append ("; Version=1");
   
   // Comment=comment
   if (cookie.getComment() != null) {
  -buf.append (";Comment=");
  +buf.append ("; Comment=");
   maybeQuote (version, buf, cookie.getComment());
   }
   }
  @@ -134,14 +134,14 @@
   // add domain information, if present
   
   if (cookie.getDomain() != null) {
  -buf.append(";Domain=");
  +buf.append("; Domain=");
   maybeQuote (version, buf, cookie.getDomain());
   }
   
   // Max-Age=secs/Discard ... or use old "Expires" format
   if (cookie.getMaxAge() >= 0) {
   if (version == 0) {
  -buf.append (";Expires=");
  +buf.append ("; Expires=");
   if (cookie.getMaxAge() == 0)
   DateTool.oldCookieFormat.format(new Date(1), buf,
   new FieldPosition(0));
  @@ -151,21 +151,21 @@
  cookie.getMaxAge() *1000L), buf,
new FieldPosition(0));
   } else {
  -buf.append (";Max-Age=");
  +buf.append ("; Max-Age=");
   buf.append (cookie.getMaxAge());
   }
   } else if (version == 1)
  -  buf.append (";Discard");
  +  buf.append ("; Discard");
   
   // Path=path
   if (cookie.getPath() != null) {
  -buf.append (";Path=");
  +buf.append ("; Path=");
   maybeQuote (version, buf, cookie.getPath());
   }
   
   // Secure
   if (cookie.getSecure()) {
  -  buf.append (";Secure");
  +  buf.append ("; Secure");
   }
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/bin catalina.xml

[remm]

remm2003/01/17 02:17:30

  Modified:catalina/src/bin catalina.xml
  Log:
  - Remove stuff from the classpath.
  - Update in-process target.
  
  Revision  ChangesPath
  1.8   +4 -2  jakarta-tomcat-catalina/catalina/src/bin/catalina.xml
  
  Index: catalina.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/catalina.xml,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- catalina.xml  5 Dec 2002 15:42:13 -   1.7
  +++ catalina.xml  17 Jan 2003 10:17:29 -  1.8
  @@ -37,9 +37,11 @@
   
 
   
  +
   

cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.bat setclasspath.sh

[remm]

remm2003/01/17 02:07:21

  Modified:catalina/src/bin setclasspath.bat setclasspath.sh
  Log:
  - Port patch.
  
  Revision  ChangesPath
  1.8   +2 -2  jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat
  
  Index: setclasspath.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- setclasspath.bat  1 Apr 2002 19:51:31 -   1.7
  +++ setclasspath.bat  17 Jan 2003 10:07:21 -  1.8
  @@ -33,7 +33,7 @@
   :okBasedir
   
   rem Set the default -Djava.endorsed.dirs argument
  -set JAVA_ENDORSED_DIRS=%BASEDIR%\bin;%BASEDIR%\common\endorsed
  +set JAVA_ENDORSED_DIRS=%BASEDIR%\common\endorsed
   
   rem Set standard CLASSPATH
   rem Note that there are no quotes as we do not want to introduce random
  
  
  
  1.8   +2 -2  jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh
  
  Index: setclasspath.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- setclasspath.sh   1 Apr 2002 19:51:31 -   1.7
  +++ setclasspath.sh   17 Jan 2003 10:07:21 -  1.8
  @@ -27,7 +27,7 @@
   fi
   
   # Set the default -Djava.endorsed.dirs argument
  -JAVA_ENDORSED_DIRS="$BASEDIR"/bin:"$BASEDIR"/common/endorsed
  +JAVA_ENDORSED_DIRS="$BASEDIR"/common/endorsed
   
   # Set standard CLASSPATH
   CLASSPATH="$JAVA_HOME"/lib/tools.jar
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2003/01/16 16:51:35

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  Fixed 16181: JspWriter not restored properly when exception thrown in a tag's body 
content
  
  Revision  ChangesPath
  1.149 +48 -7 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.148
  retrieving revision 1.149
  diff -u -r1.148 -r1.149
  --- Generator.java15 Jan 2003 22:46:29 -  1.148
  +++ Generator.java17 Jan 2003 00:51:34 -  1.149
  @@ -706,6 +706,7 @@
   
private Hashtable tagVarNumbers;
private String parent;
  + private String pushBodyCount;
private String simpleTagHandlerVar;
private boolean isSimpleTagHandler;
private boolean isFragment;
  @@ -1489,6 +1490,7 @@
  n.getShortName());
String tagEvalVar = "_jspx_eval_" + baseVar;
String tagHandlerVar = "_jspx_th_" + baseVar;
  + String tagPushBodyCountVar = "_jspx_push_body_count_" + baseVar;
   
// If the tag contains no scripting element, generate its codes
// to a method.
  @@ -1551,18 +1553,30 @@
 * Classic tag handler: Generate code for start element, body,
 * and end element
 */
  - generateCustomStart(n, handlerInfo, tagHandlerVar, tagEvalVar);
  + generateCustomStart(n, handlerInfo, tagHandlerVar, tagEvalVar,
  + tagPushBodyCountVar);
   
// visit body
String tmpParent = parent;
parent = tagHandlerVar;
  + String tmpPushBodyCount = null;
  + if (n.implementsTryCatchFinally()) {
  + tmpPushBodyCount = pushBodyCount;
  + pushBodyCount = tagPushBodyCountVar;
  + }
boolean tmpIsSimpleTagHandler = isSimpleTagHandler;
isSimpleTagHandler = false;
  +
visitBody(n);
  +
parent = tmpParent;
  + if (n.implementsTryCatchFinally()) {
  + pushBodyCount = tmpPushBodyCount;
  + }
isSimpleTagHandler = tmpIsSimpleTagHandler;
   
  - generateCustomEnd(n, tagHandlerVar, tagEvalVar);
  + generateCustomEnd(n, tagHandlerVar, tagEvalVar,
  +   tagPushBodyCountVar);
}
   
if (ci.isScriptless() && !ci.hasScriptingVars()) {
  @@ -1911,7 +1925,8 @@
private void generateCustomStart(Node.CustomTag n,
 TagHandlerInfo handlerInfo,
 String tagHandlerVar,
  -  String tagEvalVar)
  +  String tagEvalVar,
  +  String tagPushBodyCountVar)
throws JasperException {
   
Class tagHandlerClass = handlerInfo.getTagHandlerClass();
  @@ -1946,6 +1961,9 @@
generateSetters(n, tagHandlerVar, handlerInfo, false);

   if (n.implementsTryCatchFinally()) {
  + out.printin("int ");
  + out.print(tagPushBodyCountVar);
  + out.println(" = 0;");
   out.printil("try {");
   out.pushIndent();
   }
  @@ -1977,6 +1995,13 @@
// Assume EVAL_BODY_BUFFERED
out.pushIndent();
out.printil("out = pageContext.pushBody();");
  + if (n.implementsTryCatchFinally()) {
  + out.printin(tagPushBodyCountVar);
  + out.println("++;");
  + } else if (pushBodyCount != null) {
  + out.printin(pushBodyCount);
  + out.println("++;");
  + }
out.printin(tagHandlerVar);

out.println(".setBodyContent((javax.servlet.jsp.tagext.BodyContent) out);");
out.printin(tagHandlerVar);
  @@ -2003,7 +2028,8 @@

private void generateCustomEnd(Node.CustomTag n,
   String tagHandlerVar,
  -String tagEvalVar) {
  +String tagEvalVar,
  +String tagPushBodyCountVar) {
   
if (!n.hasEmptyBody()) {
if (n.implementsIterationTag()) {
  @@ -2032,6 +2058,13 @@
out.println(" != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)");
out.pushIndent();
   out.printil("out

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2003/01/16 16:51:23

  Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java
  Log:
  Fixed 16181: JspWriter not restored properly when exception thrown in a tag's body 
content
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.35.2.16 +49 -7 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.35.2.15
  retrieving revision 1.35.2.16
  diff -u -r1.35.2.15 -r1.35.2.16
  --- Generator.java15 Jan 2003 00:20:46 -  1.35.2.15
  +++ Generator.java17 Jan 2003 00:51:23 -  1.35.2.16
  @@ -545,6 +545,7 @@
   
private Hashtable tagVarNumbers;
private String parent;
  + private String pushBodyCount;
   
private ServletWriter out;
private MethodsBuffer methodsBuffer;
  @@ -1106,6 +1107,7 @@
  n.getShortName());
String tagEvalVar = "_jspx_eval_" + baseVar;
String tagHandlerVar = "_jspx_th_" + baseVar;
  + String tagPushBodyCountVar = "_jspx_push_body_count_" + baseVar;
   
// If the tag contains no scripting element, generate its codes
// to a method.
  @@ -1170,14 +1172,26 @@
}
   
// Generate code for start tag, body, and end tag
  - generateCustomStart(n, handlerInfo, tagHandlerVar, tagEvalVar);
  + generateCustomStart(n, handlerInfo, tagHandlerVar, tagEvalVar,
  + tagPushBodyCountVar);
   
String tmpParent = parent;
parent = tagHandlerVar;
  + String tmpPushBodyCount = null;
  + if (n.implementsTryCatchFinally()) {
  + tmpPushBodyCount = pushBodyCount;
  + pushBodyCount = tagPushBodyCountVar;
  + }
  +
visitBody(n);
   
parent = tmpParent;
  - generateCustomEnd(n, tagHandlerVar, tagEvalVar);
  + if (n.implementsTryCatchFinally()) {
  + pushBodyCount = tmpPushBodyCount;
  + }
  +
  + generateCustomEnd(n, tagHandlerVar, tagEvalVar,
  +   tagPushBodyCountVar);
   
if (n.isScriptless() && !n.hasScriptingVars()) {
// Generate end of method
  @@ -1302,7 +1316,8 @@
private void generateCustomStart(Node.CustomTag n,
 TagHandlerInfo handlerInfo,
 String tagHandlerVar,
  -  String tagEvalVar)
  +  String tagEvalVar,
  +  String tagPushBodyCountVar)
throws JasperException {
   
Class tagHandlerClass = handlerInfo.getTagHandlerClass();
  @@ -1337,9 +1352,13 @@
generateSetters(n, tagHandlerVar, handlerInfo);

   if (n.implementsTryCatchFinally()) {
  + out.printin("int ");
  + out.print(tagPushBodyCountVar);
  + out.println(" = 0;");
   out.printil("try {");
   out.pushIndent();
   }
  +
out.printin("int ");
out.print(tagEvalVar);
out.print(" = ");
  @@ -1368,6 +1387,13 @@
// Assume EVAL_BODY_BUFFERED
out.pushIndent();
out.printil("javax.servlet.jsp.tagext.BodyContent _bc = 
pageContext.pushBody();");
  + if (n.implementsTryCatchFinally()) {
  + out.printin(tagPushBodyCountVar);
  + out.println("++;");
  + } else if (pushBodyCount != null) {
  + out.printin(pushBodyCount);
  + out.println("++;");
  + }
out.printil("out = _bc;");
   
out.printin(tagHandlerVar);
  @@ -1396,7 +1422,8 @@

private void generateCustomEnd(Node.CustomTag n,
   String tagHandlerVar,
  -String tagEvalVar) {
  +String tagEvalVar,
  +String tagPushBodyCountVar) {
   
VariableInfo[] varInfos = n.getVariableInfos();
TagVariableInfo[] tagVarInfos = n.getTagVariableInfos();
  @@ -1428,6 +1455,13 @@
out.println(" != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)");
out.pushIndent();
   out.printil("out = pageContext.popBody();");
  + if (n.implementsTryCatchFinally()) {
  + out.pr

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2003/01/16 17:21:06

  Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java
  Log:
  Fixed 16181: JspWriter not restored properly when exception thrown in a tag's body 
content
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.35.2.17 +12 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.35.2.16
  retrieving revision 1.35.2.17
  diff -u -r1.35.2.16 -r1.35.2.17
  --- Generator.java17 Jan 2003 00:51:23 -  1.35.2.16
  +++ Generator.java17 Jan 2003 01:21:06 -  1.35.2.17
  @@ -545,7 +545,7 @@
   
private Hashtable tagVarNumbers;
private String parent;
  - private String pushBodyCount;
  + private String pushBodyCountVar;
   
private ServletWriter out;
private MethodsBuffer methodsBuffer;
  @@ -1177,17 +1177,17 @@
   
String tmpParent = parent;
parent = tagHandlerVar;
  - String tmpPushBodyCount = null;
  + String tmpPushBodyCountVar = null;
if (n.implementsTryCatchFinally()) {
  - tmpPushBodyCount = pushBodyCount;
  - pushBodyCount = tagPushBodyCountVar;
  + tmpPushBodyCountVar = pushBodyCountVar;
  + pushBodyCountVar = tagPushBodyCountVar;
}
   
visitBody(n);
   
parent = tmpParent;
if (n.implementsTryCatchFinally()) {
  - pushBodyCount = tmpPushBodyCount;
  + pushBodyCountVar = tmpPushBodyCountVar;
}
   
generateCustomEnd(n, tagHandlerVar, tagEvalVar,
  @@ -1390,8 +1390,8 @@
if (n.implementsTryCatchFinally()) {
out.printin(tagPushBodyCountVar);
out.println("++;");
  - } else if (pushBodyCount != null) {
  - out.printin(pushBodyCount);
  + } else if (pushBodyCountVar != null) {
  + out.printin(pushBodyCountVar);
out.println("++;");
}
out.printil("out = _bc;");
  @@ -1458,8 +1458,8 @@
if (n.implementsTryCatchFinally()) {
out.printin(tagPushBodyCountVar);
out.println("--;");
  - } else if (pushBodyCount != null) {
  - out.printin(pushBodyCount);
  + } else if (pushBodyCountVar != null) {
  + out.printin(pushBodyCountVar);
out.println("--;");
}
out.popIndent();
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2003/01/16 17:21:16

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  Fixed 16181: JspWriter not restored properly when exception thrown in a tag's body 
content
  
  Revision  ChangesPath
  1.150 +12 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.149
  retrieving revision 1.150
  diff -u -r1.149 -r1.150
  --- Generator.java17 Jan 2003 00:51:34 -  1.149
  +++ Generator.java17 Jan 2003 01:21:16 -  1.150
  @@ -706,7 +706,7 @@
   
private Hashtable tagVarNumbers;
private String parent;
  - private String pushBodyCount;
  + private String pushBodyCountVar;
private String simpleTagHandlerVar;
private boolean isSimpleTagHandler;
private boolean isFragment;
  @@ -1559,10 +1559,10 @@
// visit body
String tmpParent = parent;
parent = tagHandlerVar;
  - String tmpPushBodyCount = null;
  + String tmpPushBodyCountVar = null;
if (n.implementsTryCatchFinally()) {
  - tmpPushBodyCount = pushBodyCount;
  - pushBodyCount = tagPushBodyCountVar;
  + tmpPushBodyCountVar = pushBodyCountVar;
  + pushBodyCountVar = tagPushBodyCountVar;
}
boolean tmpIsSimpleTagHandler = isSimpleTagHandler;
isSimpleTagHandler = false;
  @@ -1571,7 +1571,7 @@
   
parent = tmpParent;
if (n.implementsTryCatchFinally()) {
  - pushBodyCount = tmpPushBodyCount;
  + pushBodyCountVar = tmpPushBodyCountVar;
}
isSimpleTagHandler = tmpIsSimpleTagHandler;
   
  @@ -1998,8 +1998,8 @@
if (n.implementsTryCatchFinally()) {
out.printin(tagPushBodyCountVar);
out.println("++;");
  - } else if (pushBodyCount != null) {
  - out.printin(pushBodyCount);
  + } else if (pushBodyCountVar != null) {
  + out.printin(pushBodyCountVar);
out.println("++;");
}
out.printin(tagHandlerVar);
  @@ -2061,8 +2061,8 @@
if (n.implementsTryCatchFinally()) {
out.printin(tagPushBodyCountVar);
out.println("--;");
  - } else if (pushBodyCount != null) {
  - out.printin(pushBodyCount);
  + } else if (pushBodyCountVar != null) {
  + out.printin(pushBodyCountVar);
out.println("--;");
}
out.popIndent();
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/bin setclasspath.bat setclasspath.sh

[remm]

remm2003/01/17 02:05:40

  Modified:catalina/src/bin setclasspath.bat setclasspath.sh
  Log:
  - The main problem with all the CL failures (including the one I reported a couple
of hours ago), was that bin was added as endorsed. While it is ok to do so
with bootstrap and the laucher, tomcat-jni.jar was the one causing the
problems, as its manifest include a lot of other JARs, which will end up in
the system CL (which is wrong).
  - Instead, bootstrap will be added to the system CL by the startup script, and
its manifest will add the laucher.
  - This should also fix all the CL problems which were reported with commons-logging.
  - If there was a reason why bin was endorsed, this could be reverted but 
tomcat-jni.jar
has to be moved somewhere else.
  
  Revision  ChangesPath
  1.4   +2 -2  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat
  
  Index: setclasspath.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.bat,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- setclasspath.bat  4 Aug 2002 18:19:43 -   1.3
  +++ setclasspath.bat  17 Jan 2003 10:05:40 -  1.4
  @@ -33,7 +33,7 @@
   :okBasedir
   
   rem Set the default -Djava.endorsed.dirs argument
  -set JAVA_ENDORSED_DIRS=%BASEDIR%\bin;%BASEDIR%\common\endorsed
  +set JAVA_ENDORSED_DIRS=%BASEDIR%\common\endorsed
   
   rem Set standard CLASSPATH
   rem Note that there are no quotes as we do not want to introduce random
  
  
  
  1.4   +2 -2  jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh
  
  Index: setclasspath.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- setclasspath.sh   4 Aug 2002 18:19:43 -   1.3
  +++ setclasspath.sh   17 Jan 2003 10:05:40 -  1.4
  @@ -27,7 +27,7 @@
   fi
   
   # Set the default -Djava.endorsed.dirs argument
  -JAVA_ENDORSED_DIRS="$BASEDIR"/bin:"$BASEDIR"/common/endorsed
  +JAVA_ENDORSED_DIRS="$BASEDIR"/common/endorsed
   
   # Set standard CLASSPATH
   CLASSPATH="$JAVA_HOME"/lib/tools.jar
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF

[remm]

remm2003/01/17 01:55:22

  Modified:catalina/etc bootstrap.MF
  Log:
  - Fix manifest for bootstrap.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-tomcat-catalina/catalina/etc/bootstrap.MF
  
  Index: bootstrap.MF
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/etc/bootstrap.MF,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- bootstrap.MF  18 Jul 2002 16:48:14 -  1.1
  +++ bootstrap.MF  17 Jan 2003 09:55:22 -  1.2
  @@ -1,5 +1,5 @@
   Manifest-Version: 1.0
   Main-Class: org.apache.catalina.startup.Bootstrap
  -Class-Path: commons-daemon.jar
  +Class-Path: commons-launcher.jar
   Specification-Title: Catalina
   Specification-Version: 1.0
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt

[remm]

remm2003/01/17 02:09:29

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Status update.
  
  Revision  ChangesPath
  1.50  +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.49
  retrieving revision 1.50
  diff -u -r1.49 -r1.50
  --- RELEASE-NOTES-4.1.txt 15 Jan 2003 08:22:17 -  1.49
  +++ RELEASE-NOTES-4.1.txt 17 Jan 2003 10:09:29 -  1.50
  @@ -232,6 +232,11 @@
   [4.1.19] Administration Webapp:
Add a check for empty validation query before setting it.
   
  +[4.1.20] Startup scripts:
  + Fix classloading failures on JDK 1.4 related to commons-logging, 
  + which were caused by JARs being set as endorsed and added to the
  + system classloader.
  +
   
   --
   Catalina Bug Fixes:
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Problem with JSTL on W2k

[Holger Brozio]

Hi,

i have found the reason for my problems. The main exception, which is thrown
has the following stacktrace:

java.io.IOException: Access is denied
 at java.io.Win32FileSystem.createFileExclusively(Native Method)
 at java.io.File.checkAndCreate(File.java:1162)
 at java.io.File.createTempFile(File.java:1247)
 at java.io.File.createTempFile(File.java:1284)
 at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:143)
 at java.security.AccessController.doPrivileged(Native Method)
 at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:138)
 at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:43)
 at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:61)
 at
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:88)
 at
sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:7
2)
 at
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:906)
 at
org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868)
 at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
 at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:
243)
 at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor
t.java:166)
 at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3567)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
 at org.apache.catalina.startup.Embedded.start(Embedded.java:994)

I have started an embedded tomcat 4.1.18 instance with my own NT Service. In
the ContextConfig class
tomcat tries to take a look inside of the jar files in /WEB-INF/lib. For
this issue tomcat needs a temporary
folder. This seems to be c:\winnt in the case of a service. The temp dir is
defined by the java property "java.io.tmpdir".
Because i have started the service as a generic user, i got the exception
access denied.
I have now set the property "java.io.tmpdir" to a directory within the
tomcat installation and now everything works
fine. Maybe this should be done by default?!

Cheers

Holger
- Original Message -
From: "Holger Brozio" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Cc: "Tomcat Development" <[EMAIL PROTECTED]>
Sent: Thursday, January 16, 2003 12:07 PM
Subject: Problem with JSTL on W2k


> Hello,
>
> i have a problem with the JSTL on W2k. If i start tomcat i get the
follwoing
> exception:
>
> javax.servlet.ServletException: Exception processing JAR at resource path
> /WEB-INF/lib/jaxen-full.jar
>  at
>
org.apache.catalina.startup.ContextConfig.tldScanJar(ContextConfig.java:930)
>  at
> org.apache.catalina.startup.ContextConfig.tldScan(ContextConfig.java:868)
>  at
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:647)
>  at
>
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:
> 243)
>  at
>
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor
> t.java:166)
>  at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3493)
>  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>  at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
>  at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>  at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
>  at org.apache.catalina.startup.Embedded.start(Embedded.java:994)
>  at
>
com.intershop.beehive.core.internal.startup.EmbeddedTomcatMgr.startTomcat(Em
> beddedTomcatMgr.java:393)
>  at
>
com.intershop.beehive.core.internal.startup.EmbeddedTomcatMgr.onReadyHook(Em
> beddedTomcatMgr.java:333)
>  at
>
com.intershop.beehive.core.internal.startup.AdminServer.start(AdminServer.ja
> va:70)
>  at
>
com.intershop.beehive.core.internal.startup.AdminServer.main(AdminServer.jav
> a:264)
>
> I have debugged the ContextConfig class and found out, that an exception
is
> thrown at the line 930, which has "Access is denied" as description. It
> seems that tomcat tries to open an URLConnection with the url
> "jndi:/ /WEB-INF/lib/jaxen-full.jar!/".
> My user on W2k is a normal user. If i add the user to the administrators
or
> power user group, there are no problems. I have also tried
> to change the file permissions of the jar file without an effect.
> So it seems to be a permission problem. Does anybody know, which
permission
> on W2k is missing for my user or group, which doesn't allow a normal user
to
> get the jar informations?
>
> Thanx in advance.
>
> Holger
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[GUMP] Build Failure - jakarta-tomcat-5

[bobh]

This email is autogenerated from the output from:



Buildfile: build.xml

prepare-release:
[mkdir] Created dir: /home/bodewig/dev/gump/jakarta-tomcat-5/release
[mkdir] Created dir: /home/bodewig/dev/gump/jakarta-tomcat-5/release/v5.0
[mkdir] Created dir: /home/bodewig/dev/gump/jakarta-tomcat-5/release/v5.0/bin
[mkdir] Created dir: /home/bodewig/dev/gump/jakarta-tomcat-5/release/v5.0/src

init:
[mkdir] Created dir: /home/bodewig/dev/gump/jakarta-tomcat-5/build
[mkdir] Created dir: /home/bodewig/dev/gump/jakarta-tomcat-5/build/classes

deploy-static:

deploy:
 [echo] Target: Servlet API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/bodewig/dev/gump/jakarta-servletapi-5/jsr154/build
  [jar] Building jar: 
/home/bodewig/dev/gump/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar

dist:
 [echo] Target: JSP API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/bodewig/dev/gump/jakarta-servletapi-5/jsr152/build
  [jar] Building jar: 
/home/bodewig/dev/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar

dist:
 [echo] Target: Catalina - Deploy ...

deploy-prepare:

deploy-static:

deploy-catalina:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=on
 [echo] compile.deprecation=off
 [echo] compile.optimize=on
 [echo] --- Ant Flags ---
 [echo] 

[5.0] Return of the CL bug

[Remy Maucherat]

This one looks similar to the CL problems with commons-logging (that I 
don't get). If JK 2 is enabled, I get a CL error during its initialization:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:262)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:395)
Caused by: java.lang.NoClassDefFoundError: 
javax/management/MBeanRegistration
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClass0(ClassLoader.java:723)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:292)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:840)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at 
org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoader.java:520)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:857)
at 
org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoader.java:756)
at 
org.apache.coyote.tomcat5.CoyoteConnector.initialize(CoyoteConnector.java:983)
at 
org.apache.catalina.core.StandardService.initialize(StandardService.java:579)
at 
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2347)
at org.apache.catalina.startup.Catalina.load(Catalina.java:503)
at org.apache.catalina.startup.Catalina.load(Catalina.java:521)
... 6 more

Somehow, if JMX is in endorsed, the error does not happen, as for some 
odd reason, the CL thinks it is a good idea to look for the class in the 
system classloader.
I did look very briefly at the problem, but can't find an explanation yet.

(like Costin, I hate classloaders)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Q] Where was vulnerability fixed?

[Henri Gomez]

Sam wrote:

http://online.securityfocus.com/archive/1/302169/2002-12-03/2002-12-09/2

This vulnerability was reported last month.  The report
says mod_jk 1.2.1 as fixing the vulnerability.
Yet I have searched Bugzilla for reference to this vuln.
as well as looking at mod_jk.c to see what revision was
changed, but I have not been able to locate this change.

Can anyone shed some light as to whether this vuln. was fixed
or not, and if so, and what source file(s) were changed?  
I cannot seem to find it.

jk 1.2.1 should have fixed this, and we're today at jk 1.2.2 release.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 08:13 ---
As I understand the api, it does not talk about custom tag pools, it only speaks
about tags, if you use a pool, it should be transparent.

And in other servers it works as we think it should work.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16181] - JspWriter not restored properly when exception thrown in a tag's body content

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16181

JspWriter not restored properly when exception thrown in a tag's body content

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16200] New: - isThreadSafe does not work !!

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16200

isThreadSafe does not work !!

   Summary: isThreadSafe does not work !!
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


<%@page isThreadSafe = "false" %>

The above statement should make the servlet to implement SingleThreadModel. 
But there seems to be a bug in Jasper. The following files contain the bug(s) :

1. org.apache.jasper.compiler.Validator.java - Line number 203 : isThreadSafe 
is isthreadSafe here i.e the "t" is in lowercase 

2. org.apache.jasper.compiler.Generator.java - Line number 363 : After fixing 
the first bug, a jsp compilation error was generated. There was no space 
between the servlet class name and the "implements" keyword !!

Kindly let me know if you need more info.

thanks,
saravanan

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16178] - Unix process does not get killed when Tomcat is shutdown

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16178

Unix process does not get killed when Tomcat is shutdown

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 01:43 ---
The shutdown.sh script only signals the running tomcat 4 instance to shutdown.
It can take tomcat a while to shutdown depending on the request load.
On a production system I have had to wait 10-30 seconds sometime for tomcat
to complete its shutdown. Do a tail on the log for the Connector you are using
and check for Processor stopping messages.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16189] - Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16189

Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 08:50 ---
This has been fixed in 4.1.19.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: