Re: Problems with stress tested apps

[Henri Gomez]

Bill Barker wrote:
- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 06, 2004 5:08 AM
Subject: Re: Problems with stress tested apps


Henri Gomez wrote:


Henri Gomez wrote:


Hi to all,

I've got problems with some highly stressed applications using jk or
jk2

and tomcat 3.3.2 (same thing with TC 5.0.x).

I see many errors like these in log :

in TC 3.3.2 and 5.0.19 :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0
in 5.0.19 I've got also :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest
decodeRequest

WARNING: Error registering request

There is something weird in jtc, since the INFO: Unknown message 0
indicate that there is an invalid command on the AJP13 link.
The problem appears with both jk and jk2, so I suspect the problem
to be on the java side.
I'm investigating the problem.


While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the
INFO: Unknown message 0 but got some :
6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket
processConnection

GRAVE: Error, releasing connection
java.lang.NullPointerException
   at
org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)
   at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427)

   at

org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659)

   at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807)

   at

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
   at java.lang.Thread.run(Thread.java:534)
With the latest TC 3.3.3-dev, I didn't get the :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0


This is BZ #27881.  With 3.3.2 (unless you JMX-register the CoyoteConnector
yourself :) it doesn't do anything except fill up your log file when threads
die.  Of course, you can always swap in the JK jar from 5.0.21 if you don't
want to see the message.
Thanks Bill.

I made a TC 3.3.3-dev from the CVS and it seems to works great (add 
since it has been build with common-modeler, more JMX support is included).

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

DO NOT REPLY [Bug 28245] New: - Enhancement: the order of the attribute!

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28245

Enhancement: the order of the attribute!

   Summary: Enhancement: the order of the attribute!
   Product: Tomcat 5
   Version: 5.0.19
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jspx code:


http://java.sun.com/JSP/Page"; 
xmlns:fo="http://www.w3.org/1999/XSL/Format";>
 
  
   9pt
   red
   bold
   Hello World
  
 


The output of Resin 3.0.7 is:
 
 
same order as Template text.

and the Tomcat 5.0.19 is:
 
reversed order as Template text.
 
not the same order as jsp:attribute, the order of generated attributes 
depend on the hashcode of the attribute name.

Regards.

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

DO NOT REPLY [Bug 28244] New: - XML Comment between jsp:attribute cause attribute after comment was ignored

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28244

XML Comment between jsp:attribute cause attribute after comment was ignored

   Summary: XML Comment between jsp:attribute cause attribute after
comment was ignored
   Product: Tomcat 5
   Version: 5.0.19
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The jspx code:


http://java.sun.com/JSP/Page"; 
xmlns:fo="http://www.w3.org/1999/XSL/Format";>
 
  
   9pt
   
   red
   bold
   Hello World
  
 


the output of resion 3.0.7 is:
Hello 
World

and the tomcat 5.0.19 is:
Hello World

Regards

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java

[luehe]

luehe   2004/04/06 19:31:08

  Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
  Log:
  JspServlet (global or webapp-specific) must always be preloaded,
  because its instance is used during registerJMX (when registering the
  JSP monitoring mbean)
  
  Revision  ChangesPath
  1.41  +11 -3 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
  
  Index: StandardWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
  retrieving revision 1.40
  retrieving revision 1.41
  diff -u -r1.40 -r1.41
  --- StandardWrapper.java  20 Mar 2004 01:35:02 -  1.40
  +++ StandardWrapper.java  7 Apr 2004 02:31:08 -   1.41
  @@ -378,8 +378,16 @@
*/
   public int getLoadOnStartup() {
   
  -return (this.loadOnStartup);
  -
  +if (isJspServlet && loadOnStartup < 0) {
  +/*
  + * JspServlet must always be preloaded, because its instance is
  + * used during registerJMX (when registering the JSP
  + * monitoring mbean)
  + */
  + return Integer.MAX_VALUE;
  +} else {
  +return (this.loadOnStartup);
  +}
   }
   
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

[luehe]

luehe   2004/04/06 19:27:47

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Fixed problem where when replacing global JspServlet with
  webapp-specific one, the wrapper for the global JspServlet (which had
  already been stopped and marked unavailable) was still being
  registered with JMX, because even though the wrapper had been removed
  from the context's children, it was never removed from the "wrappers"
  instance field.
  
  Replaced all occurrences of "wrappers" with the result of
  "findChildren()", so that we don't need to maintain two lists of
  wrapper children.
  
  Revision  ChangesPath
  1.124 +18 -18
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.123
  retrieving revision 1.124
  diff -u -r1.123 -r1.124
  --- StandardContext.java  5 Apr 2004 22:40:07 -   1.123
  +++ StandardContext.java  7 Apr 2004 02:27:47 -   1.124
  @@ -569,8 +569,6 @@
*/
   private transient DirContext webappResources = null;
   
  -private ArrayList wrappers=new ArrayList();
  -
   private long startupTime;
   private long startTime;
   private long tldScanTime;
  @@ -2315,7 +2313,6 @@
   public Wrapper createWrapper() {
   //log.info( "Create wrapper" );
   Wrapper wrapper = new StandardWrapper();
  -wrappers.add(wrapper);
   
   synchronized (instanceListeners) {
   for (int i = 0; i < instanceListeners.length; i++) {
  @@ -3105,9 +3102,10 @@
*/
   public void removeChild(Container child) {
   
  -if (!(child instanceof Wrapper))
  +if (!(child instanceof Wrapper)) {
   throw new IllegalArgumentException
   (sm.getString("standardContext.notWrapper"));
  +}
   
   super.removeChild(child);
   
  @@ -4416,8 +4414,6 @@
   
   // Reset application context
   context = null;
  -
  -wrappers = new ArrayList();
   }
   
   /**
  @@ -4523,8 +4519,6 @@
   // Reset application context
   context = null;
   
  -wrappers = new ArrayList();
  -
   // This object will no longer be visible or used. 
   try {
   resetContext();
  @@ -5251,16 +5245,23 @@
   }
   
   
  -/** JSR77 servlets attribute
  +/**
  + * JSR77 servlets attribute
*
* @return list of all servlets ( we know about )
*/
   public String[] getServlets() {
  -int size=wrappers.size();
  -String result[]=new String[size];
  -for( int i=0; i< size; i++ ) {
  -result[i]=((StandardWrapper)wrappers.get(i)).getObjectName();
  +
  +String[] result = null;
  +
  +Container[] children = findChildren();
  +if (children != null) {
  +result = new String[children.length];
  +for( int i=0; i< children.length; i++ ) {
  +result[i] = ((StandardWrapper)children[i]).getObjectName();
  +}
   }
  +
   return result;
   }
   
  @@ -5325,10 +5326,9 @@
   broadcaster.sendNotification(notification);
   }
   }
  -for (Iterator it = wrappers.iterator(); it.hasNext() ; ) {
  -StandardWrapper wrapper=(StandardWrapper)it.next();
  -// XXX prevent duplicated registration
  -wrapper.registerJMX( this );
  +Container children[] = findChildren();
  +for (int i=0; children!=null && i

Re: Losing line numbers in stracktraces

[David Rees]

Hans Verschoor wrote:
>
> I have a problem reading stacktrace info when Tomcat throws an exception
> caused by a servlet or a class calld by a servlet
> I have my classes compiled into in the . WEB-INF/classes directory and
> (so far) I use no war or jar.
> When an exception is thrown the stacktrace does not show line numbers but
> "Unknown source", which is "not so handy".
> The classes are compiled correctly, in other circumstances the line
> numbers DO appear in stacktraces using the same classes.
> I am a relative newbie, so my questions are:
> 1. Do I need to configure the webapploader explicitly ?
> 2. Do I need some switch on de java statement when starting tomcat ?

Make sure you compile your classes with the -g flag to javac.  Otherwise,
line numbers will be optimized out.

-Dave

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

Losing line numbers in stracktraces

[Hans Verschoor]

Hello

I have a problem reading stacktrace info when Tomcat throws an exception caused by a 
servlet or a class calld by a servlet
I have my classes compiled into in the . WEB-INF/classes directory and (so far) I 
use no war or jar.
When an exception is thrown the stacktrace does not show line numbers but "Unknown 
source", which is "not so handy".
The classes are compiled correctly, in other circumstances the line numbers DO appear 
in stacktraces using the same classes.
I am a relative newbie, so my questions are:
1. Do I need to configure the webapploader explicitly ?
2. Do I need some switch on de java statement when starting tomcat ?

Kind regards,
Hans

DO NOT REPLY [Bug 28236] - org.apache.jasper.runtime.BodyContentImpl buffer is too small

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28236

org.apache.jasper.runtime.BodyContentImpl buffer is too small

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime BodyContentImpl.java

[remm]

remm2004/04/06 16:05:39

  Modified:jasper2/src/share/org/apache/jasper/runtime
BodyContentImpl.java
  Log:
  - Bug 28236: when reallocating, make the buffer grow faster (512 bytes at a
time was not sufficient).
  - Remove main method.
  
  Revision  ChangesPath
  1.12  +2 -11 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java
  
  Index: BodyContentImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/BodyContentImpl.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- BodyContentImpl.java  17 Mar 2004 19:23:04 -  1.11
  +++ BodyContentImpl.java  6 Apr 2004 23:05:39 -   1.12
  @@ -547,15 +547,6 @@
}
   }
   
  -public static void main (String[] args) throws Exception {
  - char[] buff = {'f','o','o','b','a','r','b','a','z','y'};
  - BodyContentImpl bodyContent
  - = new BodyContentImpl(new JspWriterImpl(null, 100, false));
  - bodyContent.println (buff);
  - System.out.println (bodyContent.getString ());
  - bodyContent.writeOut (new PrintWriter (System.out));
  -}
  -
   /**
* Sets the writer to which all output is written.
*/
  @@ -595,8 +586,8 @@
   return;
   }
   
  -if (len < Constants.DEFAULT_TAG_BUFFER_SIZE) {
  -len = Constants.DEFAULT_TAG_BUFFER_SIZE;
  +if (len < cb.length) {
  +len = cb.length;
   }
   
   bufferSize = cb.length + len;
  
  
  

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

RE: 5.0.22 tag ?

[Filip Hanik \(lists\)]

sounds good!

Filip

-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004 5:48 PM
To: Tomcat Developers List
Subject: 5.0.22 tag ?


I plan to tag 5.0.22 tomorrow. Any objections ?

Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004


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

5.0.22 tag ?

[Remy Maucherat]

I plan to tag 5.0.22 tomorrow. Any objections ?

Rémy

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

Re: Coyote's ServerSocketFactory problem

[Anton Ushakov]

Ok, I decided to modify the Http11Processor, since the SSL trick is
kindof too hacky for my taste. It sets the attribute, and it's fine now.

Another issue came up though with flushing the OutputStream - and this
is something unrelated to the previous conversation.

So in org.apache.coyote.http11.InternalOutputBuffer when endRequest() is
called - on line 442 socketBuffer.flushBuffer() will in turn call
realWriteBytes which does a write on the actual outputStream, but
nothing will ever call flush() on the outputStream. This is not
noticeable in case of the normal java.net.SocketOutputStream (it's
unbuffered from what i can tell), but since I have overriden the
outputstream and my class needs to be either flush()'ed or close()'ed,
as a result my stuff is never sent back to the client, hanging the
requests.

I would think it's reasonable to expect a flush at some point on the
OutputStream when ending the request, no? This lack of flushing in not
present in the HttpConnector, in tomcat 4.

thank you
-anton



On Fri, 2004-04-02 at 17:14, Bill Barker wrote:
> - Original Message -
> From: "Anton Ushakov" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Friday, April 02, 2004 10:46 AM
> Subject: Re: Coyote's ServerSocketFactory problem
> 
> 
> > First I must say you've been extremely helpful, thank you for your
> > prompt responses!  I hate to bug you but I had another implementation
> > question. I looked at JSSESocketFactory and how SSL is done in the
> > connector, but it doesnt address one particular issue I'm having.
> >
> > Basically I have JAAS (GSSAPI) authentication done inside the Socket
> > that my SocketFactory makes. Let's call it GssSocket, and it uses
> > GssInputStream GssOutputStream for the authenticated & encrypted
> > communication.   Inside the GssSocket I establish the identity
> > (principal) of the incoming request, but have no way to set it into the
> > CoyoteRequest so it can get passed to the target Servlets through the
> > HttpServletRequest. Since all the servlet sees is the
> > CoyoteRequestFacade, I cannot get access to either the GssSocket, or the
> > GssStreams - the only places where the principal of the user is known.
> >
> > It looks like I can't avoid extending one of the Coyote classes after
> > all. What would you suggest to override to be able to extract a string
> > from the Socket and set it as an attribute for the servlets to get at?
> > I'm sorry if this is getting too hairy, but any advice would be great.
> >
> 
> It's probably possible to do what you want without much, if any, modifying
> of Tomcat code.  If you were to setup a full "SSLImplementation" to
> implement your socket factory, then you could have your code return the
> identity information in response to
> 'request.getAttribute("org.apache.coyote.request.X509Certificate")'.  This
> should work because nothing in Tomcat outside of the SSLImplementation
> understands anything about SSL, so it won't really care that you aren't
> implementing real SSL.  This method is a little hackish, but it has the
> advantage that you don't have to modify any of Tomcat's code to get it to
> work.  The downside is that you have to implement a minimum of three
> classes, even if you can make most of the methods to be dummies.  You'd also
> need to worry about the scheme getting set to "https", but I could be talked
> into modifying that.
> 
> Otherwise, you'd probably have to modify Http11Processor (about the only
> class that has access to both the Request and the Socket :) to set the
> attributes you want on the Request.
> 



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

DO NOT REPLY [Bug 28236] - org.apache.jasper.runtime.BodyContentImpl buffer is too small

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28236

org.apache.jasper.runtime.BodyContentImpl buffer is too small





--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 22:05 ---
Anyway, why don't you suggest len = 2 * cb.length ?

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

Custom session tracking method?

[Sandy McArthur]

Hi all,

Is there a way to implement custom session tracking at the container 
level?

I'm trying to figure out how to implement a custom session tracking 
method. I have a legacy client that interacts with a set of cgi scripts 
and I'd like to port those scripts to servlets. I'm running into a 
problem because the client passes session ids as a query parameter 
named 'session-num' (e.g.: /update?session-num=TOKEN). The client does 
not support cookies and there is no way to tell it use a JSESSIONID 
encoded in the path.

I've followed the code as best as I can starting at 
org.apache.coyote.tomcat5.CoyoteAdapter parses the JSESSIONID from the 
request/cookies to where the org.apache.catalina.Manager fetches the 
org.apache.catalina.Session and I don't see anyway to directly override 
the session tracking behavior.

The best idea I currently have is to use a Valve and a custom Manager 
and hope none of the Manager.{create,find}Session() methods are called 
before my Valve can parse the request and stuff the "session-num" in a 
ThreadLocal that Manager can use when returning a Session.

That feels ugly and fragile to me. Does anyone have a better solution?

Sandy McArthur


PGP.sig
Description: This is a digitally signed message part

Adding me

[Torsten Fohrer]

subscribe

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

Re: Problems with stress tested apps

[Bill Barker]

- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, April 06, 2004 5:08 AM
Subject: Re: Problems with stress tested apps


> Henri Gomez wrote:
>
> > Henri Gomez wrote:
> >
> >> Hi to all,
> >>
> >> I've got problems with some highly stressed applications using jk or
jk2
> >> and tomcat 3.3.2 (same thing with TC 5.0.x).
> >>
> >> I see many errors like these in log :
> >>
> >> in TC 3.3.2 and 5.0.19 :
> >>
> >> Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
> >> INFO: Unknown message 0
> >>
> >>
> >> in 5.0.19 I've got also :
> >>
> >> Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest
decodeRequest
> >> WARNING: Error registering request
> >>
> >>
> >> There is something weird in jtc, since the INFO: Unknown message 0
> >> indicate that there is an invalid command on the AJP13 link.
> >>
> >> The problem appears with both jk and jk2, so I suspect the problem
> >> to be on the java side.
> >>
> >> I'm investigating the problem.
> >>
> >>
> >
> > While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the
> > INFO: Unknown message 0 but got some :
> >
> > 6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket
processConnection
> > GRAVE: Error, releasing connection
> > java.lang.NullPointerException
> > at
> > org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)
> > at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427)
> > at
> >
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659)
> >
> > at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807)
> > at
> >
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:644)
> >
> > at java.lang.Thread.run(Thread.java:534)
>
> With the latest TC 3.3.3-dev, I didn't get the :
>
> Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
> INFO: Unknown message 0
>

This is BZ #27881.  With 3.3.2 (unless you JMX-register the CoyoteConnector
yourself :) it doesn't do anything except fill up your log file when threads
die.  Of course, you can always swap in the JK jar from 5.0.21 if you don't
want to see the message.

> And didn't see either the java.lang.NullPointerException in
> org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)
>
> Good for TC 5.0.22 ;)
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

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

[funkman]

funkman 2004/04/06 10:58:59

  Modified:jasper2/src/share/org/apache/jasper JspC.java
  Log:
  Allow disable tag pooling for ant task (and command line option)
  also detabbed
  
  Revision  ChangesPath
  1.69  +97 -85
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
  
  Index: JspC.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
  retrieving revision 1.68
  retrieving revision 1.69
  diff -u -r1.68 -r1.69
  --- JspC.java 17 Mar 2004 19:23:03 -  1.68
  +++ JspC.java 6 Apr 2004 17:58:59 -   1.69
  @@ -1,12 +1,12 @@
   /*
* Copyright 1999,2004 The Apache Software Foundation.
  - * 
  + *
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
  - * 
  + *
*  http://www.apache.org/licenses/LICENSE-2.0
  - * 
  + *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  @@ -108,6 +108,7 @@
   private static final String SWITCH_TRIM_SPACES = "-trimSpaces";
   private static final String SWITCH_CLASSPATH = "-classpath";
   private static final String SWITCH_DIE = "-die";
  +private static final String SWITCH_POOLING = "-poolingEnabled";
   private static final String SHOW_SUCCESS ="-s";
   private static final String LIST_ERRORS = "-l";
   private static final int NO_WEBXML = 0;
  @@ -116,19 +117,20 @@
   private static final int DEFAULT_DIE_LEVEL = 1;
   private static final int NO_DIE_LEVEL = 0;
   
  -private static final String[] insertBefore = 
  -{ "", "", "", 
  +private static final String[] insertBefore =
  +{ "", "", "",
 "", "", "", "",
 "", "", "",
  -  "", "", "", "", 
  +  "", "", "", "",
 "" };
   
  -private static int die; 
  +private static int die;
   private String classPath = null;
   private URLClassLoader loader = null;
   private boolean trimSpaces = false;
   private boolean xpoweredBy;
   private boolean mappedFile = false;
  +private boolean poolingEnabled = true;
   private File scratchDir;
   private String ieClassId = DEFAULT_IE_CLASS_ID;
   private String targetPackage;
  @@ -261,6 +263,13 @@
   die = dieLevel;
   } else if (tok.equals(SWITCH_HELP)) {
   helpNeeded = true;
  +} else if (tok.equals(SWITCH_POOLING)) {
  +tok = nextArg();
  +if ("false".equals(tok)) {
  +poolingEnabled = false;
  +} else {
  +poolingEnabled = true;
  +}
   } else {
   if (tok.startsWith("-")) {
   throw new JasperException("Unrecognized option: " + tok +
  @@ -296,7 +305,11 @@
   }
   
   public boolean isPoolingEnabled() {
  -return true;
  +return poolingEnabled;
  +}
  +
  +public void setPoolingEnabled(boolean poolingEnabled) {
  +this.poolingEnabled = poolingEnabled;
   }
   
   public boolean isXpoweredBy() {
  @@ -312,19 +325,19 @@
   }
   
   public int getTagPoolSize() {
  - return Constants.MAX_POOL_SIZE;
  +return Constants.MAX_POOL_SIZE;
   }
   
   /**
* Are we supporting HTML mapped servlets?
*/
   public boolean getMappedFile() {
  - return mappedFile;
  +return mappedFile;
   }
   
   // Off-line compiler, no need for security manager
   public Object getProtectionDomain() {
  - return null;
  +return null;
   }
   
   public boolean getSendErrorToClient() {
  @@ -366,14 +379,14 @@
* Is the generation of SMAP info for JSR45 debuggin suppressed?
*/
   public boolean isSmapSuppressed() {
  - return true;
  +return true;
   }
   
  /**
* Should SMAP info for JSR45 debugging be dumped to a file?
*/
   public boolean isSmapDumped() {
  - return false;
  +return false;
   }
   
   /**
  @@ -413,7 +426,7 @@
   }
   
   public TldLocationsCache getTldLocationsCache() {
  - return tldLocationsCache;
  +return tldLocationsCache;
   }
   
   /**
  @@ -423,14 +436,14 @@
* @return String The encoding
*/
   public String getJavaEncoding() {
  - return javaEncoding;
  +return javaEncoding;
   }
   
   /**
* Sets the encoding to use for
* java files.
*
  - * @param encodingName The name, e.g. "UTF-8" 
  + * @param encodingName The name, e.g. "UTF-8"
*/
   public void se

DO NOT REPLY [Bug 28147] - JasperException for jsp files that are symbolic links

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28147

JasperException for jsp files that are symbolic links

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 17:28 ---
This will not be fixed. If you care, please submit a fix.

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

DO NOT REPLY [Bug 15278] - [PATCH] mod_jk2 for IIS, Bugfix corrupted data ]

[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://issues.apache.org/bugzilla/show_bug.cgi?id=15278

[PATCH] mod_jk2 for IIS, Bugfix corrupted data ]





--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 17:20 ---
Hi Mladen,

That build seems to work for me; thanks for posting it!
The systems I tested it with were:

-w2k machines
-IIS v5.xxx
-Tomcat 4.1.29
-J2sdk 1.4.2_03 (and 1.4.2_01, I believe)

Cheers,

Geoff

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

DO NOT REPLY [Bug 28236] New: - org.apache.jasper.runtime.BodyContentImpl buffer is too small

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28236

org.apache.jasper.runtime.BodyContentImpl buffer is too small

   Summary: org.apache.jasper.runtime.BodyContentImpl buffer is too
small
   Product: Tomcat 5
   Version: 5.0.19
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Well actually in reAllocBuff() method the policy is to incriment it by a 
constant (512 bytes). In my case with a BIG  tag 99% of CPU is 
used just to increment the buffer. 

The suggestion is to use

***
len = Math.max(Constants.DEFAULT_TAG_BUFFER_SIZE, cb.length);
***
instead of
***
if (len < Constants.DEFAULT_TAG_BUFFER_SIZE) {
len = Constants.DEFAULT_TAG_BUFFER_SIZE;
}
***

In my case (I'm using JSF RI 1.0) the change is from ~26 min to 2 sec.

Sincerely,

unknown

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

cvs commit: jakarta-tomcat-connectors/jk/native build.xml

[mmanders]

mmanders2004/04/06 09:40:57

  Modified:jk/native build.xml
  Log:
  Updated build rev for NetWare modules.
  
  Revision  ChangesPath
  1.40  +4 -4  jakarta-tomcat-connectors/jk/native/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/build.xml,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- build.xml 22 Jul 2003 21:45:38 -  1.39
  +++ build.xml 6 Apr 2004 16:40:57 -   1.40
  @@ -126,7 +126,7 @@
 
 
 
  -  
  +  
 
 
 
  @@ -220,7 +220,7 @@
 
 
 
  -  
  +  
 
 
 
  @@ -302,7 +302,7 @@
 
 
 
  -  
  +  
 
 
 
  @@ -436,7 +436,7 @@
 
 
 
  -  
  +  
 
 
 
  
  
  

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

DO NOT REPLY [Bug 28234] New: - uri: worker property does not exist any more

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28234

uri: worker property does not exist any more

   Summary: uri: worker property does not exist any more
   Product: Tomcat 5
   Version: 5.0.19
  Platform: Other
   URL: http://jakarta.apache.org/tomcat/tomcat-4.1-
doc/jk2/jk2/configwebex.html
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The documentation still lists the 'worker' property in the examples. I guess
this should be replaced by 'group'.

Plus:
Why does the URL read tomcat-4.1 BTW if I browse the 5.0 documentation? Very
confusing.
More comprehensive examples of how to use the context property would be nice.
All in all documentation seems too fuzzy to me. It would definitely nice to have
good documentation on all the parameters of the JK2 configuration.

Cheers

Ortwin Glück

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteOutputStream.java CoyoteReader.java CoyoteRequest.java CoyoteWriter.java

[Jeanfrancois Arcand]

Remy Maucherat wrote:

Bill Barker wrote:

I'm -0 on this.  The classes modified are all internal to the Tomcat 5.x
CoyoteConnector, so there is no good reason to make them public.
The way that Coyote is designed, this should always be unnecessary.  
The way
to build a new connector is to define a new ProtocolHandler that 
deals with
the transport.


I agree, but right now the access declarations were inconsistent. I 
know Jean-François used this for pretty advanced embedding, so being 
able to extend doesn't hurt.
Exactly. I agree re-writting a Protocolhandler was the solution (and I 
did it), but I was still looking to extends CoyoteAdapter. As an 
example, if cookie are already parsed by the NSAPI, I don't want to call 
CoyoteAdapter.parseSessionId(..), but I still want to re-use the 
remaining of the class.

-- Jeanfrancois


Rémy

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



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

Re: Hi

[Costin . Manolache]

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

RE: TC Cluster: does SmartQueue fit into DeltaManager

[Filip Hanik \(lists\)]

no, smart queue does not belong with the delta manager. it could never work
that way, and never will :)

Filip

-Original Message-
From: Rainer Jung [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004 1:35 AM
To: [EMAIL PROTECTED]
Subject: TC Cluster: does SmartQueue fit into DeltaManager


Hi,

I opened Bug 28161 last week. I found out yesterday, that the problem comes
from using the SmartQueue together with DeltaManager and asynchronous
replication (see Bug-Report for details).

What are the plans now? If I knew, that a fix will take several days I might
substitute the SmartQueue by an improvised FIFO to proceed with further
tests on our application.

Any comments are welcome, especially your opinion on the problem and on what
to expect technically and with respect to time frame from a fix.

Thank you for the important and very good work you all do on Tomcat.

Sincerely

Rainer Jung
kippdata informationstechnologie



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004


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

hey you

[stefano]

Norton AntiVirus gelöscht1.txt
Description: plain/text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems with stress tested apps

[Remy Maucherat]

Henri Gomez wrote:

Henri Gomez wrote:

Henri Gomez wrote:

Hi to all,

I've got problems with some highly stressed applications using jk or jk2
and tomcat 3.3.2 (same thing with TC 5.0.x).
I see many errors like these in log :

in TC 3.3.2 and 5.0.19 :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0
in 5.0.19 I've got also :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest 
decodeRequest
WARNING: Error registering request

There is something weird in jtc, since the INFO: Unknown message 0
indicate that there is an invalid command on the AJP13 link.
The problem appears with both jk and jk2, so I suspect the problem
to be on the java side.
I'm investigating the problem.


While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the 
INFO: Unknown message 0 but got some :

6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection
GRAVE: Error, releasing connection
java.lang.NullPointerException
at 
org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)
at 
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) 

at 
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) 

at java.lang.Thread.run(Thread.java:534)


With the latest TC 3.3.3-dev, I didn't get the :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0
The logging has been adjusted.

And didn't see either the java.lang.NullPointerException in 
org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)
AFAIK, this was a race condition issue.

Good for TC 5.0.22 ;)
Rémy

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

Re: Problems with stress tested apps

[Henri Gomez]

Henri Gomez wrote:

Henri Gomez wrote:

Hi to all,

I've got problems with some highly stressed applications using jk or jk2
and tomcat 3.3.2 (same thing with TC 5.0.x).
I see many errors like these in log :

in TC 3.3.2 and 5.0.19 :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0
in 5.0.19 I've got also :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest decodeRequest
WARNING: Error registering request
There is something weird in jtc, since the INFO: Unknown message 0
indicate that there is an invalid command on the AJP13 link.
The problem appears with both jk and jk2, so I suspect the problem
to be on the java side.
I'm investigating the problem.


While playing with TC 3.3.3-dev and JTC-dev, I didn't see (yet), the 
INFO: Unknown message 0 but got some :

6 avr. 2004 08:46:37 org.apache.jk.common.ChannelSocket processConnection
GRAVE: Error, releasing connection
java.lang.NullPointerException
at 
org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:427)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:659) 

at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:807)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:644) 

at java.lang.Thread.run(Thread.java:534)
With the latest TC 3.3.3-dev, I didn't get the :

Mar 19, 2004 1:47:51 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 0
And didn't see either the java.lang.NullPointerException in 
org.apache.coyote.RequestInfo.setGlobalProcessor(RequestInfo.java:52)

Good for TC 5.0.22 ;)



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

DO NOT REPLY [Bug 28154] - setting of mappedfile in web.xml doesn't 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://issues.apache.org/bugzilla/show_bug.cgi?id=28154

setting of mappedfile in web.xml doesn't work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 10:19 ---
The changelog here:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/changelog.html
says "mappedFile"

Interestingly, our dev box which I've just upgraded to 5.0.19 does work as 
expected, merging template text with \n in the strings, whereas tomcat 5.0.14 on 
our live server doesn't... but the web.xml in our live server does mention 
mappedfile and release notes say mappedfile came in with v5.0.7.

Anyway, I shall try and get our live server upgraded...
thanks
Paul

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

DO NOT REPLY [Bug 28123] - ClientAbortException should default to the description of the wrapped exception

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28123

ClientAbortException should default to the description of the wrapped exception

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 09:20 ---
I agree with Bill.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java CoyoteOutputStream.java CoyoteReader.java CoyoteRequest.java CoyoteWriter.java

[Remy Maucherat]

Bill Barker wrote:
I'm -0 on this.  The classes modified are all internal to the Tomcat 5.x
CoyoteConnector, so there is no good reason to make them public.
The way that Coyote is designed, this should always be unnecessary.  The way
to build a new connector is to define a new ProtocolHandler that deals with
the transport.
I agree, but right now the access declarations were inconsistent. I know 
Jean-François used this for pretty advanced embedding, so being able to 
extend doesn't hurt.

Rémy

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

DO NOT REPLY [Bug 28196] - forEach throws with arrays (${header}, ${param}, etc.)

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28196

forEach throws with arrays (${header}, ${param}, etc.)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 09:12 ---
This works for me. Please don't reopen this bug, and, more importantly, stop
using tag plugins.

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

DO NOT REPLY [Bug 28219] - Dolar sign in password of JNDI-Datasource disappears

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28219

Dolar sign in password of JNDI-Datasource disappears

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Catalina|Webapps:Administration



--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 09:08 ---
At worst, this will only occur when you save your server.xml through the admin
webapp.

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

DO NOT REPLY [Bug 28221] - "scratchdir" Can Break Virtual Hosts

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28221

"scratchdir" Can Break Virtual Hosts

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 08:51 ---
Yes, you indeed cannot set this globally.

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

DO NOT REPLY [Bug 28129] - Classloading for the security-constraint / Realm

[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://issues.apache.org/bugzilla/show_bug.cgi?id=28129

Classloading for the security-constraint / Realm





--- Additional Comments From [EMAIL PROTECTED]  2004-04-06 08:32 ---
I tested some more, and i'm somehow a little bit stupid.
The problem is that i try to load the xml as URL (http://...) , which doesn't 
work because the URL is secured via the security-constraint and the Parser has 
no access to the xml, and tries to parse the login2.jsp, which in this case 
isn't a valid xml and he throws the Fatal Error. So its not a real bug, but now 
the question is, how can i give the Parser a role to get the access to the xml 
via URL ?

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

cvs commit: jakarta-tomcat build.properties.sample

[hgomez]

hgomez  2004/04/06 00:29:48

  Modified:.build.properties.sample
  Log:
  Correct jmxtools.jar for this example bp
  
  Revision  ChangesPath
  1.5   +2 -2  jakarta-tomcat/build.properties.sample
  
  Index: build.properties.sample
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.properties.sample,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- build.properties.sample   1 Jan 2004 23:20:46 -   1.4
  +++ build.properties.sample   6 Apr 2004 07:29:48 -   1.5
  @@ -48,7 +48,7 @@
   jmx.home=../mx4j-1.1.1
   jmx.lib=${jmx.home}/lib
   jmx.jar=${jmx.lib}/mx4j-jmx.jar
  -jmx-tools.jar=${jmx.lib}/mx4j-tools.jar
  +jmxtools.jar=${jmx.lib}/mx4j-tools.jar
   
   # - Commons Modeler, version 1.1 or later -
   commons-modeler.home=../commons-modeler-1.1
  
  
  

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

cvs commit: jakarta-tomcat build.xml

[hgomez]

hgomez  2004/04/06 00:12:31

  Modified:.build.xml
  Log:
  We're now on 3.3.3-dev
  
  Revision  ChangesPath
  1.204 +1 -1  jakarta-tomcat/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/build.xml,v
  retrieving revision 1.203
  retrieving revision 1.204
  diff -u -r1.203 -r1.204
  --- build.xml 3 Mar 2004 06:15:55 -   1.203
  +++ build.xml 6 Apr 2004 07:12:31 -   1.204
  @@ -25,7 +25,7 @@
 
   
 
  -  
  +  
 
 
 
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote RequestInfo.java

[hgomez]

hgomez  2004/04/06 00:01:08

  Modified:coyote/src/java/org/apache/coyote RequestInfo.java
  Log:
  Tab policies
  
  Revision  ChangesPath
  1.10  +2 -2  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java
  
  Index: RequestInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/RequestInfo.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- RequestInfo.java  6 Apr 2004 06:59:54 -   1.9
  +++ RequestInfo.java  6 Apr 2004 07:01:08 -   1.10
  @@ -50,8 +50,8 @@
   global.addRequestProcessor( this );
   } else {
if (this.global != null) {
  - this.global.removeRequestProcessor( this ); 
  - this.global = null;
  +this.global.removeRequestProcessor( this ); 
  +this.global = null;
   }
   }
   }
  
  
  

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