Re: server port at the command line

[rf]

--- Bill Barker <[EMAIL PROTECTED]> wrote:
> 
> - Original Message - 
> From: "rf" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 05, 2003 10:32 PM
> Subject: server port at the command line
> 
> 
> > while distributing a tomcat+application to people
> who
> > want to run tomcat on a port different than the
> > default, it would be more easy if we can supply
> the
> > port at the command line, like
> > bin/startup.bat 9002
> > than change the port in the server.xml
> > 
> > Also, I would like to supply some parameters to my
> > web-application from the command line to tomcat,
> is it
> > possible?
> 
> Not in the current release, but patches are always
> welcome :-).
> 

I thought there are some technical issues why you guys
have not already implemented these...

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

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

Re: server port at the command line

[Bill Barker]

- Original Message - 
From: "rf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 05, 2003 10:32 PM
Subject: server port at the command line


> while distributing a tomcat+application to people who
> want to run tomcat on a port different than the
> default, it would be more easy if we can supply the
> port at the command line, like
> bin/startup.bat 9002
> than change the port in the server.xml
> 
> Also, I would like to supply some parameters to my
> web-application from the command line to tomcat, is it
> possible?

Not in the current release, but patches are always welcome :-).

> 
> Thank you
> 
> ~rf
> 
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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

Re: [TOMCAT 4.1.18] StandardSession.setId() found incohesive

[Tom Anderson]

I'm not quite sure why it does but I am finding the implementation of 
this class in particular to be somewhat flawed.   For example, the 
recycle() method doesn't remove a session from memory (via the Manager) 
but expire() does.   So, when something is recycled, it is actually 
left on the list of sessions too.

What does this have to do with setId().   Well, I only found all of the 
above problems because I am trying to fix my copy of JDBCStore to 
retain the session ID when it calls setId() (the problem I'm trying to 
fix is that I discovered a Session "leak" related to the fact that a 
loaded session has a different ID than what's in the database).   But 
the JDBCStore.load() method calls ManagerBase.createSession() which 
ALSO calls Session.setId()... my head is spinning.   So if I fix 
JDBCStore.load() then setId() gets fired twice with the undesired 
side-effects.

I'm not exactly answering your question but hopefully re-affirming that 
there is a problem here.   My opinion is that the StandardSession class 
should have no knowledge of the Manager that created it.  Then maybe 
these circular calls would be eliminated.   But what do I know?

~Tom


On Wednesday, February 5, 2003, at 04:33 PM, Daniel Rall wrote:

Developers, I'd like your input on why setId() has the side effects
that it does, and your suggestions on what solution I should implement
which would be acceptable to both Tomcat 4 and 5, and cleanly usable
by myself.  The issue I filed includes the Valve implementation which
excercises the setId() method, and hacks around its side effects.



TRACKING ISSUE: http://issues.apache.org/bugzilla/show_bug.cgi?id=16822


OBSERVED BEHAVIOR: ManagerBase.createSession() calls
StandardSession.setId() as the last thing it does before returning a
newly created session.  StandardSession.setId() exhibits the
undocumented side effect of firing a session creation event, iterating
over all HttpSessionListeners registered with the current web context
and notifying them of its "creation":

public void setId(String id) {

if ((this.id != null) && (manager != null))
manager.remove(this);

this.id = id;

if (manager != null)
manager.add(this);

// Notify interested session event listeners
fireSessionEvent(Session.SESSION_CREATED_EVENT, null);

// Notify interested application event listeners
Context context = (Context) manager.getContainer();
Object listeners[] = context.getApplicationListeners();
if (listeners != null) {
HttpSessionEvent event =
new HttpSessionEvent(getSession());
for (int i = 0; i < listeners.length; i++) {
if (!(listeners[i] instanceof HttpSessionListener))
continue;
HttpSessionListener listener =
(HttpSessionListener) listeners[i];
try {
fireContainerEvent(context,
   "beforeSessionCreated",
   listener);
listener.sessionCreated(event);
fireContainerEvent(context,
   "afterSessionCreated",
   listener);
} catch (Throwable t) {
try {
fireContainerEvent(context,
   "afterSessionCreated",
   listener);
} catch (Exception e) {
;
}
// FIXME - should we do anything besides log these?
log(sm.getString("standardSession.sessionEvent"), 
t);
}
}
}

}

A second call to setId() will again fire a session creation event for
the existing session.  Here's some trace from making a single request
when calling setId() explicitly:

2003-02-03 17:46:43,113 [Ajp13Processor[17025][4]] INFO  default - 
Adding
session org.apache.catalina.session.StandardSessionFacade@4977e2 with 
id of
2EA4840C7D4D6C7F3FF76F1F95C575D5
2003-02-03 17:46:43,175 [Ajp13Processor[17025][4]] INFO  default - 
Adding
session org.apache.catalina.session.StandardSessionFacade@4977e2 with 
id of
C6C908E127E6230CC81AE70E10D914A4

My web application's list of active sessions (stored as a Map of
StandardSessionFacade objects keyed by session ID) will look as
follows:

Session creation event fired as ManagerBase sets the initial ID by
calling StandardSession.setId() during its createSession() method
  |
  |
  v
.__.
| Key  | Value |
`--'
| ID A | Facade A --> Session A (ID A) |
`--'
  |
  |
Second session creation event fired as SessionIdValve resets the ID

server port at the command line

[rf]

while distributing a tomcat+application to people who
want to run tomcat on a port different than the
default, it would be more easy if we can supply the
port at the command line, like
bin/startup.bat 9002
than change the port in the server.xml

Also, I would like to supply some parameters to my
web-application from the command line to tomcat, is it
possible?

Thank you

~rf

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

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

org.apache.catalina.loader.WebappClassLoader cacheing

[Martin Schulz]

Hi,

I would like to know whether I can control the cacheing
behavior of org.apache.catalina.loader.WebappClassLoader
somehow.

For the purpose of developing a server application, I would
like to be able to drop in config files and other resource
files such as scripts and be able to reload them
programmatically through
myclass.class.getResourceAsStream(myResource).

Since WebappClassLoader diligently caches all resources
in a HashMap, the resource file can never be reloaded.

Subclassing WebappClassLoader is an option, but I'd like to
avoid modifying the tomcat jar if possible.

Are there any workarounds this restriction
e.g. by using getResource URL et al. which will not ultimately
wind up accessing the same cache?

Thanks!

   Martin

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/01/2003
 


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

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[Larry Isaacs]

Thanks.  The restored mod_jk behavior is the same as
Tomcat 3.3.x with ,
the default.  Unsafe escapes give 403's.  We can
add a similar option to mod_jk to turn off the checking.
Though, I can't image a situation where it would make
sense to accept the risks to gain access to these escapes.  

Cheers,
Larry

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, February 05, 2003 5:02 PM
> To: 'Tomcat Developers List'
> Subject: RE: cvs commit: 
> jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
> 
> 
> Larry,
> 
> > 
> > I wouldn't see it as a step forward where we increase
> > the vulnerability of the majority, and the effort needed
> > to deal with that, in favor of satisfying a small minority
> > that insist on using inherently unsafe escape sequences.
> > 
> > Maybe this new behavior should be an option like it is in
> > Tomcat 3.3.x.  The default is to err on the side of safety.
> > Operating in this less safe envrionment could be specifically
> > requested via an option, and the user is responsible for
> > dealing with the impact.  How does that sound?
> > 
> 
> Ok, no problem, but there must be a middle ground.
> 
> Perhaps the tests (jk_req_util.c/jk_requtil_unescapeUrl) now 
> overreact a
> bit, maybe we can tone down the code, just now it barfs on 
> any embedded
> '/' %2F, tomcat deals without problems with this issues, and 
> later there
> is an agressive uri filtering on ./ and combinations.. maybe is better
> to let this pass without problems to tc, and let tomcat deal with it..
> tested and it works very well..
> 
> How about this way?
> 
> In the mean time i'll revert the change.. 
> 
> Saludos, 
> Ignacio J. Ortega 
> 
> 

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

RE: class loading issue/bug 4.1.17

[Filip Hanik]

absolutely correct :)

Filip

-Original Message-
From: shawn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 5:40 PM
To: Tomcat Developers List
Subject: RE: class loading issue/bug 4.1.17


So this is something that can not be changed and either we have to 

1) include the class in distributions (outside the jar) for placement in
common/classes

or 

2) store and retrieve bytes and marshal it in a servlet

Correct?

On Thu, 2003-02-06 at 10:28, Filip Hanik wrote:
> The problem you are experiencing is a fundamental issue on how classloaders 
>hierarchy works when using servlet container. documented here
> 
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
> 
> 
> Filip
> 
> 
> 
> -Original Message-
> From: shawn [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 05, 2003 5:08 PM
> To: Tomcat Developers List
> Subject: RE: class loading issue/bug 4.1.17
> 
> 
> On Thu, 2003-02-06 at 09:42, Filip Hanik wrote:
> > 1. you could also move the mysql.jar into your WEB-INF/lib and you should resove 
>the same problem too.
> > 
> >From Tomcat docs on DBCP
> 
> These jar files along with your the jar file for your JDBC driver should
> be installed in $CATALINA_HOME/common/lib.
>  
> NOTE: Do not install these jarfiles in your /WEB-INF/lib, or
> $JAVA_HOME/jre/lib/ext, or anywhere else. You will experience
> problems if you install them anyplace other than
> $CATALINA_HOME/common/lib.
> 
> > 2. You could just get the bytes (instead of getObject) store/retrieve bytes and do 
>the marshalling in your servlet code.
> > 
> > 
> Fine but if this is a limitation of Tomcat, shouldn't it be documented?
> Maybe even in the section on DBCP...one side of effect of this
> requirement is that...
> 
> (As you may know as is sometimes the case in OpenSource, Junior
> developers have a tough time getting Sr ones to do things differently
> without sufficient justification...)
> 
> I do greatly appreciate the response and apologize for being fiesty this
> morning.  This in no way should be interpreted as any form of complaint.
> 
> 
> Shawn
>  
> 
> 
> -
> 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]
-- 
shawn <[EMAIL PROTECTED]>


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


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

RE: class loading issue/bug 4.1.17

[shawn]

So this is something that can not be changed and either we have to 

1) include the class in distributions (outside the jar) for placement in
common/classes

or 

2) store and retrieve bytes and marshal it in a servlet

Correct?

On Thu, 2003-02-06 at 10:28, Filip Hanik wrote:
> The problem you are experiencing is a fundamental issue on how classloaders 
>hierarchy works when using servlet container. documented here
> 
> http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html
> 
> 
> Filip
> 
> 
> 
> -Original Message-
> From: shawn [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 05, 2003 5:08 PM
> To: Tomcat Developers List
> Subject: RE: class loading issue/bug 4.1.17
> 
> 
> On Thu, 2003-02-06 at 09:42, Filip Hanik wrote:
> > 1. you could also move the mysql.jar into your WEB-INF/lib and you should resove 
>the same problem too.
> > 
> >From Tomcat docs on DBCP
> 
> These jar files along with your the jar file for your JDBC driver should
> be installed in $CATALINA_HOME/common/lib.
>  
> NOTE: Do not install these jarfiles in your /WEB-INF/lib, or
> $JAVA_HOME/jre/lib/ext, or anywhere else. You will experience
> problems if you install them anyplace other than
> $CATALINA_HOME/common/lib.
> 
> > 2. You could just get the bytes (instead of getObject) store/retrieve bytes and do 
>the marshalling in your servlet code.
> > 
> > 
> Fine but if this is a limitation of Tomcat, shouldn't it be documented?
> Maybe even in the section on DBCP...one side of effect of this
> requirement is that...
> 
> (As you may know as is sometimes the case in OpenSource, Junior
> developers have a tough time getting Sr ones to do things differently
> without sufficient justification...)
> 
> I do greatly appreciate the response and apologize for being fiesty this
> morning.  This in no way should be interpreted as any form of complaint.
> 
> 
> Shawn
>  
> 
> 
> -
> 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]
-- 
shawn <[EMAIL PROTECTED]>


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

RE: class loading issue/bug 4.1.17

[Filip Hanik]

The problem you are experiencing is a fundamental issue on how classloaders hierarchy 
works when using servlet container. documented here

http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html


Filip



-Original Message-
From: shawn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 5:08 PM
To: Tomcat Developers List
Subject: RE: class loading issue/bug 4.1.17


On Thu, 2003-02-06 at 09:42, Filip Hanik wrote:
> 1. you could also move the mysql.jar into your WEB-INF/lib and you should resove the 
>same problem too.
> 
>From Tomcat docs on DBCP

These jar files along with your the jar file for your JDBC driver should
be installed in $CATALINA_HOME/common/lib.
 
NOTE: Do not install these jarfiles in your /WEB-INF/lib, or
$JAVA_HOME/jre/lib/ext, or anywhere else. You will experience
problems if you install them anyplace other than
$CATALINA_HOME/common/lib.

> 2. You could just get the bytes (instead of getObject) store/retrieve bytes and do 
>the marshalling in your servlet code.
> 
> 
Fine but if this is a limitation of Tomcat, shouldn't it be documented?
Maybe even in the section on DBCP...one side of effect of this
requirement is that...

(As you may know as is sometimes the case in OpenSource, Junior
developers have a tough time getting Sr ones to do things differently
without sufficient justification...)

I do greatly appreciate the response and apologize for being fiesty this
morning.  This in no way should be interpreted as any form of complaint.


Shawn
 


-
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: class loading issue/bug 4.1.17

[shawn]

On Thu, 2003-02-06 at 09:42, Filip Hanik wrote:
> 1. you could also move the mysql.jar into your WEB-INF/lib and you should resove the 
>same problem too.
> 
>From Tomcat docs on DBCP

These jar files along with your the jar file for your JDBC driver should
be installed in $CATALINA_HOME/common/lib.
 
NOTE: Do not install these jarfiles in your /WEB-INF/lib, or
$JAVA_HOME/jre/lib/ext, or anywhere else. You will experience
problems if you install them anyplace other than
$CATALINA_HOME/common/lib.

> 2. You could just get the bytes (instead of getObject) store/retrieve bytes and do 
>the marshalling in your servlet code.
> 
> 
Fine but if this is a limitation of Tomcat, shouldn't it be documented?
Maybe even in the section on DBCP...one side of effect of this
requirement is that...

(As you may know as is sometimes the case in OpenSource, Junior
developers have a tough time getting Sr ones to do things differently
without sufficient justification...)

I do greatly appreciate the response and apologize for being fiesty this
morning.  This in no way should be interpreted as any form of complaint.


Shawn
 


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

RE: class loading issue/bug 4.1.17

[Filip Hanik]

1. you could also move the mysql.jar into your WEB-INF/lib and you should resove the 
same problem too.

2. You could just get the bytes (instead of getObject) store/retrieve bytes and do the 
marshalling in your servlet code.


Filip

-Original Message-
From: shawn [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 05, 2003 4:39 PM
To: tomcat developer
Subject: class loading issue/bug 4.1.17


Using Tomcat 4.1.17 to upload a servlet I get a Class not found error
when the class is there.

Notice that the error stems from my driver in jakarta_home/common/lib while
the class it can not find is loaded from a jar in my app's WEB-INF/lib.

If I put the class into jakarta_home/common/classes it works fine.

ERROR [Thread-4] (SqlUtil.java:360) - ::logSqlExceptionSQL - exception
> java.sql.SQLException: Class not found:
> java.lang.ClassNotFoundException: org.dbforms.util.FileHolder while
> reading serialized object
>   at com.mysql.jdbc.ResultSet.getObject(Unknown Source)
>   at org.dbforms.util.ResultSetVector.(ResultSetVector.java:93)

A FileHolder holds data saved from a
com.oreilly.servlet.multipart.FilePart as byteArray 

I would think this is not by design or it would be documented.

I realize maybe this has already been solved but just wanted to point it out in case.
-- 
shawn <[EMAIL PROTECTED]>


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


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

class loading issue/bug 4.1.17

[shawn]

Using Tomcat 4.1.17 to upload a servlet I get a Class not found error
when the class is there.

Notice that the error stems from my driver in jakarta_home/common/lib while
the class it can not find is loaded from a jar in my app's WEB-INF/lib.

If I put the class into jakarta_home/common/classes it works fine.

ERROR [Thread-4] (SqlUtil.java:360) - ::logSqlExceptionSQL - exception
> java.sql.SQLException: Class not found:
> java.lang.ClassNotFoundException: org.dbforms.util.FileHolder while
> reading serialized object
>   at com.mysql.jdbc.ResultSet.getObject(Unknown Source)
>   at org.dbforms.util.ResultSetVector.(ResultSetVector.java:93)

A FileHolder holds data saved from a
com.oreilly.servlet.multipart.FilePart as byteArray 

I would think this is not by design or it would be documented.

I realize maybe this has already been solved but just wanted to point it out in case.
-- 
shawn <[EMAIL PROTECTED]>


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

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

[nacho]

nacho   2003/02/05 16:33:16

  Modified:jk/native2 build.xml
  Log:
  Honor use.jni, needed to fix gump builds..
  Fixed resources location for apache13 win32 builds
  
  Revision  ChangesPath
  1.38  +2 -2  jakarta-tomcat-connectors/jk/native2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/build.xml,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- build.xml 11 Jun 2002 22:50:24 -  1.37
  +++ build.xml 6 Feb 2003 00:33:16 -   1.38
  @@ -328,7 +328,7 @@
   
 
 
  -  
  +  
   
   
   
  @@ -467,7 +467,7 @@

 
   
  -  
  +  
   
 
 
  
  
  

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

DO NOT REPLY [Bug 16822] - StandardSession.setId() found incohesive

[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=16822

StandardSession.setId() found incohesive

[EMAIL PROTECTED] changed:

   What|Removed |Added

URL||http://archives.apache.org/e
   ||yebrowse/ReadMsg?listName=to
   ||mcat-
   ||[EMAIL PROTECTED]&msgNo
   ||=55548

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

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

[luehe]

luehe   2003/02/05 15:41:19

  Modified:jasper2/src/share/org/apache/jasper/compiler JspConfig.java
  Log:
  fixed typo
  
  Revision  ChangesPath
  1.9   +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java
  
  Index: JspConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JspConfig.java5 Feb 2003 23:39:21 -   1.8
  +++ JspConfig.java5 Feb 2003 23:41:19 -   1.9
  @@ -208,7 +208,7 @@
   }
   
   /**
  - * Find a property that best match the supplied resource.
  + * Find a property that best matches the supplied resource.
* @param uri the resource supplied.
* @return a JspProperty if a match is found, null otherwise
*/
  
  
  

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

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

[luehe]

luehe   2003/02/05 15:39:21

  Modified:jasper2/src/share/org/apache/jasper/compiler
ErrorDispatcher.java Generator.java JspConfig.java
  Log:
  Undid changes that were not supposed to be committed with previous putback
  
  Revision  ChangesPath
  1.11  +3 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ErrorDispatcher.java
  
  Index: ErrorDispatcher.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ErrorDispatcher.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ErrorDispatcher.java  5 Feb 2003 23:35:21 -   1.10
  +++ ErrorDispatcher.java  5 Feb 2003 23:39:20 -   1.11
  @@ -303,7 +303,6 @@
*/
   public void javacError(String errMsg, String fname, Node.Nodes page)
throws JasperException, IOException {
  - System.out.println("LLL: " + errMsg);
JavacErrorDetail[] errDetails = parseJavacMessage(errMsg, fname, page);
errHandler.javacError(errDetails);
   }
  
  
  
  1.160 +3 -5  
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.159
  retrieving revision 1.160
  diff -u -r1.159 -r1.160
  --- Generator.java5 Feb 2003 23:35:21 -   1.159
  +++ Generator.java5 Feb 2003 23:39:20 -   1.160
  @@ -3123,8 +3123,6 @@
   out.printil( "throw (java.io.IOException) t;" );
   out.printil( "if( t instanceof javax.servlet.jsp.JspException )" );
   out.printil( "throw (javax.servlet.jsp.JspException) t;" );
  -out.printil( "if( t instanceof IllegalArgumentException )" );
  -out.printil( "throw (IllegalArgumentException) t;" );
   out.printil("throw new javax.servlet.jsp.JspException(t);" );
   out.popIndent();
   out.printil( "} finally {" );
  
  
  
  1.8   +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java
  
  Index: JspConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- JspConfig.java5 Feb 2003 23:35:21 -   1.7
  +++ JspConfig.java5 Feb 2003 23:39:21 -   1.8
  @@ -208,7 +208,7 @@
   }
   
   /**
  - * Find a property that best matches the supplied resource.
  + * Find a property that best match the supplied resource.
* @param uri the resource supplied.
* @return a JspProperty if a match is found, null otherwise
*/
  
  
  

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

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

[luehe]

luehe   2003/02/05 15:35:22

  Modified:jasper2/src/share/org/apache/jasper/compiler
ErrorDispatcher.java Generator.java JspConfig.java
TagFileProcessor.java
  Log:
  Changed default for rtexprvalue for tag files from 'false' to 'true',
  as agreed by JSR-152-EG
  
  Revision  ChangesPath
  1.10  +4 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ErrorDispatcher.java
  
  Index: ErrorDispatcher.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ErrorDispatcher.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- ErrorDispatcher.java  22 Jan 2003 20:08:24 -  1.9
  +++ ErrorDispatcher.java  5 Feb 2003 23:35:21 -   1.10
  @@ -303,6 +303,7 @@
*/
   public void javacError(String errMsg, String fname, Node.Nodes page)
throws JasperException, IOException {
  + System.out.println("LLL: " + errMsg);
JavacErrorDetail[] errDetails = parseJavacMessage(errMsg, fname, page);
errHandler.javacError(errDetails);
   }
  
  
  
  1.159 +5 -3  
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.158
  retrieving revision 1.159
  diff -u -r1.158 -r1.159
  --- Generator.java31 Jan 2003 03:34:44 -  1.158
  +++ Generator.java5 Feb 2003 23:35:21 -   1.159
  @@ -3123,6 +3123,8 @@
   out.printil( "throw (java.io.IOException) t;" );
   out.printil( "if( t instanceof javax.servlet.jsp.JspException )" );
   out.printil( "throw (javax.servlet.jsp.JspException) t;" );
  +out.printil( "if( t instanceof IllegalArgumentException )" );
  +out.printil( "throw (IllegalArgumentException) t;" );
   out.printil("throw new javax.servlet.jsp.JspException(t);" );
   out.popIndent();
   out.printil( "} finally {" );
  
  
  
  1.7   +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java
  
  Index: JspConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspConfig.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- JspConfig.java22 Jan 2003 20:08:24 -  1.6
  +++ JspConfig.java5 Feb 2003 23:35:21 -   1.7
  @@ -208,7 +208,7 @@
   }
   
   /**
  - * Find a property that best match the supplied resource.
  + * Find a property that best matches the supplied resource.
* @param uri the resource supplied.
* @return a JspProperty if a match is found, null otherwise
*/
  
  
  
  1.39  +6 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- TagFileProcessor.java 28 Jan 2003 00:13:37 -  1.38
  +++ TagFileProcessor.java 5 Feb 2003 23:35:21 -   1.39
  @@ -179,8 +179,11 @@
   String attrName = n.getAttributeValue("name");
   boolean required = JspUtil.booleanValue(
n.getAttributeValue("required"));
  +boolean rtexprvalue = true;
   String rtexprvalueString = n.getAttributeValue("rtexprvalue");
  -boolean rtexprvalue = JspUtil.booleanValue( rtexprvalueString );
  + if (rtexprvalueString != null) {
  + rtexprvalue = JspUtil.booleanValue( rtexprvalueString );
  + }
   boolean fragment = JspUtil.booleanValue(
n.getAttributeValue("fragment"));
String type = n.getAttributeValue("type");
  
  
  

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

DO NOT REPLY [Bug 16822] - StandardSession.setId() found incohesive

[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=16822

StandardSession.setId() found incohesive





--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 23:31 ---
Created an attachment (id=4749)
SessionIdValve -- calls setId() and hacks around its side effects

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

DO NOT REPLY [Bug 16822] New: - StandardSession.setId() found incohesive

[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=16822

StandardSession.setId() found incohesive

   Summary: StandardSession.setId() found incohesive
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


OBSERVED BEHAVIOR: ManagerBase.createSession() calls
StandardSession.setId() as the last thing it does before returning a
newly created session.  StandardSession.setId() exhibits the
undocumented side effect of firing a session creation event, iterating
over all HttpSessionListeners registered with the current web context
and notifying them of its "creation".

A second call to setId() will again fire a session creation event for
the existing session.  Here's some trace from making a single request
when calling setId() explicitly:

2003-02-03 17:46:43,113 [Ajp13Processor[17025][4]] INFO  default - Adding
session org.apache.catalina.session.StandardSessionFacade@4977e2 with id of
2EA4840C7D4D6C7F3FF76F1F95C575D5
2003-02-03 17:46:43,175 [Ajp13Processor[17025][4]] INFO  default - Adding
session org.apache.catalina.session.StandardSessionFacade@4977e2 with id of
C6C908E127E6230CC81AE70E10D914A4

My web application's list of active sessions (stored as a Map of
StandardSessionFacade objects keyed by session ID) will look as
follows:

Session creation event fired as ManagerBase sets the initial ID by
calling StandardSession.setId() during its createSession() method
  |
  |
  v
.__.
| Key  | Value |
`--'
| ID A | Facade A --> Session A (ID A) |
`--'
  |
  |
Second session creation event fired as SessionIdValve resets the ID,
calling setId() for a second time (this time explicitly).
  |
  |
  v
.__.
| Key  | Value |
`--'
| ID A | Facade A --> Session A (ID A) |
| ID B | Facade A --> Session A (ID B) |
`--'

The entry keyed by session ID A will not be removed from our list of
active sessions when Session A expires, as the session now has an ID
of B.


USE CASE: When creating a new session, I must set the session
identifier (or manipulate it after the initial generation from a
Valve) using request-specific inputs.

Specifically, I must re-use any session identifier supplied by the
client via its JSESSIONID cookie if that session identifier is not
already in use.  Because the Servlet API dictates that the session
cookie is always named JSESSIONID, this is a must have for support of
wildcard cookie domains across hosts which share a common base domain
name.

For instance, if I have host1.domain.com and host2.domain.com, and set
the cookie domain of sessions cookie to the wildcard ".domain.com"
(some pathetic browsers only support two part wildcard domains), the
cookie will apply to both hosts.  This is problematic when a client
which has established a session on host1 tries to establish a second
session on host2 -- host2 will assign the client a new session ID,
wiping the client's memory of its session ID for host1.  Now, if host1
and host2 are gracious enough to use the same session ID, they can
effectively share the JSESSIONID cookie, allowing the client to enjoy
simultaneous sessions on both host1 and host2 while working within the
Servlet API.


PROBLEM: Tomcat's Manager interface has no API for accessing
contextual information specific to a request.  Combining a Valve which
provides this request-specific context via thread-local storage with
my own custom manager is hacky at best, and would require that I
completely re-implement the code in StandardSession (due to its
package-private scoping).

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

cvs commit: jakarta-tomcat-4.0/webapps/admin/logger loggers.jsp

[amyroh]

amyroh  2003/02/05 15:24:47

  Modified:webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm
SaveJNDIRealmAction.java
   webapps/admin/logger loggers.jsp
  Log:
  Fix to look up the correct attribute name for JNDIRealm page.
  Also, background color for delete loggers page was missing.
  
  Revision  ChangesPath
  1.10  +6 -6  
jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm/SaveJNDIRealmAction.java
  
  Index: SaveJNDIRealmAction.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/realm/SaveJNDIRealmAction.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- SaveJNDIRealmAction.java  16 Aug 2002 00:30:45 -  1.9
  +++ SaveJNDIRealmAction.java  5 Feb 2003 23:24:46 -   1.10
  @@ -332,11 +332,11 @@
   new Attribute("roleName",  roleName));
   }
   
  -attribute = "rolePattern";
  +attribute = "roleSearch";
   String rolePattern = rform.getRolePattern();
   if ((rolePattern != null) && (rolePattern.length()>0)) {
   mBServer.setAttribute(roname,
  -new Attribute("rolePattern",  rolePattern));
  +new Attribute("roleSearch",  rolePattern));
   }
   
   attribute = "roleSubtree";
  
  
  
  1.4   +1 -1  jakarta-tomcat-4.0/webapps/admin/logger/loggers.jsp
  
  Index: loggers.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/admin/logger/loggers.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- loggers.jsp   15 Jan 2003 22:25:19 -  1.3
  +++ loggers.jsp   5 Feb 2003 23:24:46 -   1.4
  @@ -10,7 +10,7 @@
   <%@ include file="../users/header.jsp" %>
   
   
  -
  +
   
   
   
  
  
  

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

DO NOT REPLY [Bug 16821] New: - Unable to compile JSP pages with jstl tag libraries.

[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=16821

Unable to compile JSP pages with jstl tag libraries.

   Summary: Unable to compile JSP pages with jstl tag libraries.
   Product: Tomcat 4
   Version: 4.1.12
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I can reproduce this easily. For any JSP pages that uses the standard tag lib
with the following line.
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>
I will run into errors when using JspC to compile from command line. I use the
following command line to compile Jsp pages:
java org.apache.jasper.JspC -d output_dir -p my.package -uriroot jsp 

I also need to put standard.jar under jsp/WEB-INF/lib for JspC to find it. An
error will occur. 

I also did a bit digging to see why the same Jasper library compiles Jsp fine
for a web-app, but not from command line. The following is what I found.The
culprit is the following line of code in the constructor of TagLibraryInfoImpl.java

   if(ctxt.getClassLoader() != null &&
 
java.net.URLClassLoader.class.equals(ctxt.getClassLoader().getClass())
  && path.startsWith("/"))
   {
   path = path.substring(1,path.length()) ;
   }
   url = ctxt.getResource(path);

When running from the web-app. The ctxt object is JspEngineContext (I am looking
at a Jetty class). Its class loader is different from java.net.URLClassLoader,
so it will not trigger the action to strip out the "/".

When running JspC to compile the JSP pages, the ctxt object is
JspCompilationContext. Its class loader is URLClassLoader, so it will trigger
the stripping action.

However both context objects do not use class loader to getResource. Instead
both use javax.servlet.ServletContext.getResource, which requires the string to
be started with "/" according to Servlet spec. So the check for the class loader
here makes no sense here. It is clearly a bug that the code strips out the
starting "/" prior to calling ctxt.getResource. 

I would suggest to take out the above code that checks for class loader and
remove the starting "/".

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader StandardClassLoader.java

[costin]

costin  2003/02/05 14:44:52

  Modified:catalina/src/share/org/apache/catalina/loader Tag:
tomcat_40_branch StandardClassLoader.java
  Log:
  Apply classloader fix to branch.
  Original comment:
  
  While most JDK's on Windows are very tolerant of backslashes in file:
  URLs, they are not consisent in exactly WHEN they make the transition
  to spec compliant URLs.  In this case, the url was constructed in
  org.apache.catalina.startup.ClassLoaderFactory.createClassLoader using
  File.separator and extracted using toString().
  
  Submitted by: [EMAIL PROTECTED]
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.24.2.2  +7 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
  
  Index: StandardClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
  retrieving revision 1.24.2.1
  retrieving revision 1.24.2.2
  diff -u -r1.24.2.1 -r1.24.2.2
  --- StandardClassLoader.java  16 Nov 2001 01:21:51 -  1.24.2.1
  +++ StandardClassLoader.java  5 Feb 2003 22:44:52 -   1.24.2.2
  @@ -693,7 +693,7 @@
   
   // Re-locate the class ourselves to track modifications if possible
   for (int i = 0; i < repositories.length; i++) {
  -if (!repositories[i].endsWith("/"))
  +if (!repositories[i].endsWith("/"))
   continue;
   String pathname =
   repositories[i].substring(0, repositories[i].length() - 1);
  @@ -1197,7 +1197,8 @@
   streamHandler = factory.createURLStreamHandler(protocol);
   
   // Validate the manifest of a JAR file repository
  -if (!repository.endsWith(File.separator)) {
  +if (!repository.endsWith(File.separator) &&
  +!repository.endsWith(File.separator)) {
   try {
   JarFile jarFile = null;
   Manifest manifest = null;
  
  
  

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

DO NOT REPLY [Bug 16759] - ISAPI_REDIRECTOR Handles %2F improperly

[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=16759

ISAPI_REDIRECTOR Handles %2F improperly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 22:15 ---
Reverted the prior Fix, as it opens a security hole with source disclosure, 
looking for another safer solution ..

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[nacho]

nacho   2003/02/05 14:10:51

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Revert latest Fix for Bug#16759
  
  Revision  ChangesPath
  1.55  +7 -11 
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- jk_isapi_plugin.c 4 Feb 2003 20:45:49 -   1.54
  +++ jk_isapi_plugin.c 5 Feb 2003 22:10:51 -   1.55
  @@ -2,7 +2,7 @@
*   *
* The Apache Software License,  Version 1.1 *
*   *
  - *  Copyright (c) 1999-2003 The Apache Software Foundation.  *
  + *  Copyright (c) 1999-2002 The Apache Software Foundation.  *
*   All rights reserved.*
*   *
* = *
  @@ -316,24 +316,20 @@
   
   rc = jk_requtil_unescapeUrl(uri);
   if (rc == BAD_REQUEST) {
  -env->l->jkLog(env, env->l,  JK_LOG_INFO, 
  +env->l->jkLog(env, env->l,  JK_LOG_ERROR, 
  "HttpFilterProc [%s] contains one or more invalid escape 
sequences.\n", 
  uri);
  -// XXX: Let any other filter process the request, 
  -//  if they take any security measure or not doesnt matter.
  -//  write_error_response(pfc,"400 Bad Request", HTML_ERROR_400);
  +write_error_response(pfc,"400 Bad Request", HTML_ERROR_400);
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
  -return SF_STATUS_REQ_NEXT_NOTIFICATION;
  +return SF_STATUS_REQ_FINISHED;
   }
   else if(rc == BAD_PATH) {
  -env->l->jkLog(env, env->l,  JK_LOG_INFO, 
  +env->l->jkLog(env, env->l,  JK_LOG_EMERG, 
  "HttpFilterProc [%s] contains forbidden escape 
sequences.\n", 
  uri);
  -// XXX: Let any other filter process the request, 
  -//  if they take any security measure or not doesnt matter.
  -//  write_error_response(pfc,"403 Forbidden", HTML_ERROR_403);
  +write_error_response(pfc,"403 Forbidden", HTML_ERROR_403);
   workerEnv->globalEnv->releaseEnv( workerEnv->globalEnv, env );
  -return SF_STATUS_REQ_NEXT_NOTIFICATION;
  +return SF_STATUS_REQ_FINISHED;
   }
   jk_requtil_getParents(uri);
   
  
  
  

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

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[Ignacio J. Ortega]

Larry,

> 
> I wouldn't see it as a step forward where we increase
> the vulnerability of the majority, and the effort needed
> to deal with that, in favor of satisfying a small minority
> that insist on using inherently unsafe escape sequences.
> 
> Maybe this new behavior should be an option like it is in
> Tomcat 3.3.x.  The default is to err on the side of safety.
> Operating in this less safe envrionment could be specifically
> requested via an option, and the user is responsible for
> dealing with the impact.  How does that sound?
> 

Ok, no problem, but there must be a middle ground.

Perhaps the tests (jk_req_util.c/jk_requtil_unescapeUrl) now overreact a
bit, maybe we can tone down the code, just now it barfs on any embedded
'/' %2F, tomcat deals without problems with this issues, and later there
is an agressive uri filtering on ./ and combinations.. maybe is better
to let this pass without problems to tc, and let tomcat deal with it..
tested and it works very well..

How about this way?

In the mean time i'll revert the change.. 

Saludos, 
Ignacio J. Ortega 


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

DO NOT REPLY [Bug 15693] - Network hangs when running as NT service

[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=15693

Network hangs when running as NT service

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Network hangs when running  |Network hangs when running
   |as NT service (with patch)  |as NT service



--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 21:09 
---
An update --

I don't have any confidence that the patch does anything at all for JDK's >= 
1.3.1.  It did fix the problem for IBM's 1.3.0 JDK, but our other production 
JDK - Sun 1.4.1 - continued to hang.

We _think_ it might be a TCP/IP bug in Windows since we've had similar kinds 
of hangs in Apache2 and Sybase on Windows 2000 SP3 in particular - that was 
the opinion of Sybase support anyway, but we're not too confident on that 
score either.

The only other thing we could think of is that it is somehow related to some 
remote control software (Remote Administrator) we also use.  The machines in 
question are pretty much bare otherwise.

It is a real problem with some Windows configurations (although apparently not 
the vast majority or there would be many more bug reports), but darned if 
we've been able to figure it out.

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

DO NOT REPLY [Bug 15693] - Network hangs when running as NT service (with patch)

[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=15693

Network hangs when running as NT service (with patch)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 20:39 ---
I am using Sun JDK1.4.1_01, Windows NT SP6, and Apache Tomcat/4.1.18-LE-jdk14 
installed as a service (during installation.)

I wanted to CONFIRM that the apache service does hang after serving an 
arbitrary ammount of requests. Nothing is written to the log files, yet 
tomcat.exe continues to run. The connections seem to be accepted, but no data 
is ever returned, and thus the http request just hangs. 

The only way to fix this is to stop and then start the apache service. I have 
no tried out the above patch, but I will be tempted to if there is no 
explaination for this. 

Thanks,
Min

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

Re: bean with jsp

[Kin-Man Chung]

You should try to get answers to questions like this on tmcat-users alias.

You'll need to put whatever you import in a package.  This is a new
in JDK1.4.

> Date: Wed, 05 Feb 2003 17:39:07 +0530
> From: Sachin Chowdhary <[EMAIL PROTECTED]>
> Subject: bean with jsp
> To: [EMAIL PROTECTED]
> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> Importance: Normal
> X-Priority: 3 (Normal)
> X-MSMail-priority: Normal
> X-OriginalArrivalTime: 05 Feb 2003 12:09:09.0271 (UTC) 
FILETIME=[63397A70:01C2CD0F]
> 
> 
> I am trying to use a class by using useBean tag in jsp but i am not able to
> do it so remove all coding and just using import class name syntax but still
> i am not able to do that on tomcat4.1.18 .so what i am doing wrong
> 
> can you suggest me
> 
> 
> C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\jsp
> <%@ page import="MyClass" %>
> 
> 
> 
> Meet a Bean!
>
> 
> 
> //MyClass.java
> 
> 
> C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\WEB-INF\classes
> public class MyClass
> {
>  public String val;
> }
> 
> 
> 
> HTTP Status 500 -
> 
> type Exception report
> message
> description The server encountered an internal error () that prevented it
> from fulfilling this request.
> exception
> org.apache.jasper.JasperException: Unable to compile class for JSP
> 
> An error occurred at line: -1 in the jsp file: null
> 
> Generated servlet error:
> [javac] Compiling 1 source file
> 
> C:\Program Files\Apache Group\Tomcat
> 4.1\work\Standalone\localhost\examples\jsp\MyJsp_jsp.java:7: '.' expected
> import MyClass;
>   ^
> 1 error
> 
> 
> 
> 
> -
> 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]

DO NOT REPLY [Bug 16808] New: - Jasper makes calls to tag setters that 1.2 spec says it doesn't have to

[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=16808

Jasper makes calls to tag setters that 1.2 spec says it doesn't have to

   Summary: Jasper makes calls to tag setters that 1.2 spec says it
doesn't have to
   Product: Tomcat 4
   Version: 4.1.8
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The JSP 1.2 specification, in section JSP.10.1, titled "Simple Tag Handlers", in
a subsection titled "Properties", has the following statement:

Once properly set, all properties are expected to be persistent, so that if the
JSP container ascertains that a property has already been set on a given tag
handler instance, it needs not set it again. User code can access property
information and access and modify tag handler internal state starting with the
first action method (doStartTag) up until the last action method (doEndTag or
doFinally for tag handlers implementing TryCatchFinally).

I've discoverered Tomcat is not taking advantage of the fact that it doesn't
need to call the setter method again on the reused tag handler.

Following this is a simple excerpt from my test case, using Struts and
Struts-EL.  I find that the "setValue()" method is called on the first
iteration, which is expected, but it is also called on the second iteration,
which is not necessary.

  
   

   
  

This might be considered just an optimization issue, but the lack of this
optimization led me down an unfortunate road, due to a mistake I made.

I wrote all of the tag classes in the Struts-EL library under the mistaken
assumption that I could safely modify attribute values.  Making this assumption
made it very convenient, as I could subclass from the Struts tag classes, and
just use the getter/setter methods for the attributes in the base class, without
having to add redundant attributes to the derived class.  After the container
calls the setter on the attribute (say with a value of "${foo}"), in the
"doStartTag()" of the Struts-EL tags, I use the JSTL EL engine to evaluate the
attribute value and send it back to the setter method of the attribute.

This works fine in Tomcat, which made me confident that I had followed all the
rules, as I know that Tomcat is the reference implementation of the specification.

Unfortunately, the Resin web container takes advantage of this optimization, so
that reused tag handlers won't get the setter methods called, so the attribute
values will be the same as what I got from running the EL engine on the initial
instance, making the page and tag library quite broken.

I know how to fix this in my tag library, but it will require a lot of
straightforward coding.

>From one point of view, this should only be considered an enhancement, but I
think this is a little different from other optimization opportunities.

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

New build error

[Dianne Jiao]

Jeanfrancois,

This is the build error I just got for tomcat 5 when running "ant download":

compile:
[javac] Compiling 56 source files to 
/usr/djiao/jakarta-tomcat-5/commons-el/target/classes
[javac] 
/usr/djiao/jakarta-tomcat-5/commons-el/src/java/org/apache/commons/el/ExpressionEvaluatorImpl.java:125:
 no interface expected here
[javac]   extends ExpressionEvaluator
[javac]   ^
[javac] 
/usr/djiao/jakarta-tomcat-5/commons-el/src/java/org/apache/commons/el/ExpressionEvaluatorImpl.java:541:
 no interface expected here
[javac] extends javax.servlet.jsp.el.Expression
[javac] ^
[javac] 
/usr/djiao/jakarta-tomcat-5/commons-el/src/java/org/apache/commons/el/NamedValue.java:125:
 resolveVariable(java.lang.String,java.lang.Object) in 
javax.servlet.jsp.el.VariableResolver cannot be applied to (java.lang.String)
[javac]   return pResolver.resolveVariable (mName);
[javac]   ^
[javac] 
/usr/djiao/jakarta-tomcat-5/commons-el/src/java/org/apache/commons/el/VariableResolverImpl.java:72:
 org.apache.commons.el.VariableResolverImpl should be declared abstract; it does not 
define resolveVariable(java.lang.String,java.lang.Object) in 
org.apache.commons.el.VariableResolverImpl
[javac] public class VariableResolverImpl
[javac]^
[javac] 4 errors

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

Re: [PATCH] Root cause lost in Jsp and ServletException

[Costin Manolache]

Jeanfrancois Arcand wrote:

> Oups. I tested the patch using 1.4 (having the impression Costin was
> working with 1.3). I will revert the patch.

Sorry for that...

Both servletapi-4 and 5 need to be reverted.

I'll try to find an alternative solution. The problem is that debugging some
errors is difficult without the real trace. I sent Ceki a patch to log4j -
but for various reasons he believe it belongs to the application.
I'll try to incorporate it in the code that displays the stack trace ( it's 
what 3.3 uses - introspection and some patterns to find the root cause ).

Costin


> 
> Thanks,
> 
> -- Jeanfrancois
> 
> Glenn Nielsen wrote:
> 
>> BTW, this does not build with JDK's < 1.4 and if you use a servlet.jar
>> built with 1.4 in a JVM <1.4 you get a NoSuchMethodError.
>>
>> This change for jakarta-servletapi-4 need to reverted for now.
>>
>> Glenn
>>
>>
>> Costin Manolache wrote:
>>
>>> this is for servetapi_4.
>>>
>>> Same applies to servletapi_5 ( I already sent a patch few weeks ago ).
>>>
>>> The problem is that JDK1.4 stack traces can't find the root cause.
>>>
>>> AFAIK nothing in the servlet or JSP specs requires breaking the normal
>>> contract for exceptions - which is to pass the root cause to the parent.
>>>
>>> Costin
>>>
>>> Index: src/share/javax/servlet/ServletException.java
>>> ===
>>> RCS file:
>>>
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/ServletException.java,v
>>> retrieving revision 1.1.1.1
>>> diff -u -r1.1.1.1 ServletException.java
>>> --- src/share/javax/servlet/ServletException.java   9 Jan 2001
>>> 03:24:16 -
>>> 1.1.1.1
>>> +++ src/share/javax/servlet/ServletException.java   4 Feb 2003
>>> 19:00:30 -
>>> @@ -129,7 +129,7 @@
>>>   */
>>>   public ServletException(String message, Throwable rootCause) {
>>> -   super(message);
>>> +   super(message, rootCause);
>>> this.rootCause = rootCause;
>>>  }
>>>  
>>> @@ -158,7 +158,7 @@
>>>   */
>>>  
>>>  public ServletException(Throwable rootCause) {
>>> -   super(rootCause.getLocalizedMessage());
>>> +   super(rootCause.getLocalizedMessage(), rootCause);
>>> this.rootCause = rootCause;
>>>  }
>>>Index: src/share/javax/servlet/jsp/JspException.java
>>> ===
>>> RCS file:
>>>
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/jsp/JspException.java,v
>>> retrieving revision 1.1.1.1
>>> diff -u -r1.1.1.1 JspException.java
>>> --- src/share/javax/servlet/jsp/JspException.java   9 Jan 2001
>>> 03:24:20 -
>>> 1.1.1.1
>>> +++ src/share/javax/servlet/jsp/JspException.java   4 Feb 2003
>>> 19:00:31 -
>>> @@ -106,7 +106,7 @@
>>>   */
>>>   public JspException(String message, Throwable rootCause) {
>>> -   super(message);
>>> +   super(message, rootCause);
>>> this.rootCause = rootCause;
>>>  }
>>>  
>>> @@ -132,7 +132,7 @@
>>>   */
>>>  
>>>  public JspException(Throwable rootCause) {
>>> -   super(rootCause.getLocalizedMessage());
>>> +   super(rootCause.getLocalizedMessage(), rootCause);
>>> this.rootCause = rootCause;
>>>  }
>>>  
>>>
>>>
>>> -
>>> 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]
>>
>>



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

Tomcat 4.1: Problem/Bug with authentication - Please inform

[Richard Backhouse]

Return Receipt
   
Your  Tomcat 4.1: Problem/Bug with authentication - Please inform  
document   
:  
   
was   Richard Backhouse/Raleigh/Contr/IBM  
received   
by:
   
at:   02/05/2003 10:30:06 EST  
   





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

Tomcat 4.1: Problem/Bug with authentication - Please inform

[Danny Adaimy]

Hi,
 
I would very much appreciate your rapid response in the matter:
 
I am using Tomcat 4.1 and I have configured a certain area as protected:
I am using JDBCRealm "org.apache.catalina.realm.JDBCRealm" and a MYSQL
driver.
 
I have the configuration setup such that requests to the protected area
get redirected to a login.jsp which is accompanied by an error.jsp in
case of authentication failure.
The process works very well if a user enters an invalid username and/or
password (i.e. authentication failure results in redirection to
error.jsp); however, if the username and password are both valid but
role assigned to the user is not allowed in the protected area, NO
redirection to error.jsp takes place and instead a status 403 is
returned to the WebServer.
 
I have tried forums and newsgroups but no one seems to have a solution.
Please note that the problem was not present in Tomcat 3.3.
 
 
Your attention to the matter is greatly appreciated,
 
Thank you,
 
Danny Adaimy
Software Developer

Re: [PATCH] Root cause lost in Jsp and ServletException

[Costin Manolache]

Ops...

Sorry - you're right. 

There is a way to make it compatible with both 1.3- and 1.4 - but it would
require changing the interface, so probably need to send feedback to the
jcp...

( adding a Throwable getCause() to the interface would make the stack traces
work again ).



Costin

Glenn Nielsen wrote:

> BTW, this does not build with JDK's < 1.4 and if you use a servlet.jar
> built with 1.4 in a JVM <1.4 you get a NoSuchMethodError.
> 
> This change for jakarta-servletapi-4 need to reverted for now.
> 
> Glenn
> 
> 
> Costin Manolache wrote:
>> this is for servetapi_4.
>> 
>> Same applies to servletapi_5 ( I already sent a patch few weeks ago ).
>> 
>> The problem is that JDK1.4 stack traces can't find the root cause.
>> 
>> AFAIK nothing in the servlet or JSP specs requires breaking the normal
>> contract for exceptions - which is to pass the root cause to the parent.
>> 
>> Costin
>> 
>> Index: src/share/javax/servlet/ServletException.java
>> ===
>> RCS file:
>>
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/ServletException.java,v
>> retrieving revision 1.1.1.1
>> diff -u -r1.1.1.1 ServletException.java
>> --- src/share/javax/servlet/ServletException.java   9 Jan 2001
>> 03:24:16 - 1.1.1.1
>> +++ src/share/javax/servlet/ServletException.java   4 Feb 2003
>> 19:00:30 - @@ -129,7 +129,7 @@
>>   */
>>  
>>  public ServletException(String message, Throwable rootCause) {
>> -   super(message);
>> +   super(message, rootCause);
>> this.rootCause = rootCause;
>>  }
>>  
>> @@ -158,7 +158,7 @@
>>   */
>>  
>>  public ServletException(Throwable rootCause) {
>> -   super(rootCause.getLocalizedMessage());
>> +   super(rootCause.getLocalizedMessage(), rootCause);
>> this.rootCause = rootCause;
>>  }
>>
>> Index: src/share/javax/servlet/jsp/JspException.java
>> ===
>> RCS file:
>>
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/jsp/JspException.java,v
>> retrieving revision 1.1.1.1
>> diff -u -r1.1.1.1 JspException.java
>> --- src/share/javax/servlet/jsp/JspException.java   9 Jan 2001
>> 03:24:20 - 1.1.1.1
>> +++ src/share/javax/servlet/jsp/JspException.java   4 Feb 2003
>> 19:00:31 - @@ -106,7 +106,7 @@
>>   */
>>  
>>  public JspException(String message, Throwable rootCause) {
>> -   super(message);
>> +   super(message, rootCause);
>> this.rootCause = rootCause;
>>  }
>>  
>> @@ -132,7 +132,7 @@
>>   */
>>  
>>  public JspException(Throwable rootCause) {
>> -   super(rootCause.getLocalizedMessage());
>> +   super(rootCause.getLocalizedMessage(), rootCause);
>> this.rootCause = rootCause;
>>  }
>>  
>> 
>> 
>> -
>> 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]

cvs commit: jakarta-servletapi-5/jsr154/src/share/javax/servlet ServletException.java

[jfarcand]

jfarcand2003/02/05 07:22:19

  Modified:jsr154/src/share/javax/servlet ServletException.java
  Log:
  Revert patch
  
  Revision  ChangesPath
  1.3   +2 -2  
jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletException.java
  
  Index: ServletException.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletException.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ServletException.java 5 Feb 2003 03:11:28 -   1.2
  +++ ServletException.java 5 Feb 2003 15:22:19 -   1.3
  @@ -129,7 +129,7 @@
*/
   
   public ServletException(String message, Throwable rootCause) {
  - super(message, rootCause);
  + super(message);
this.rootCause = rootCause;
   }
   
  @@ -158,7 +158,7 @@
*/
   
   public ServletException(Throwable rootCause) {
  - super(rootCause.getLocalizedMessage(), rootCause);
  + super(rootCause.getLocalizedMessage());
this.rootCause = rootCause;
   }
 
  
  
  

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

cvs commit: jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp JspException.java

[jfarcand]

jfarcand2003/02/05 07:20:25

  Modified:jsr152/src/share/javax/servlet/jsp JspException.java
  Log:
  Revert patch
  
  Revision  ChangesPath
  1.4   +2 -2  
jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspException.java
  
  Index: JspException.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/src/share/javax/servlet/jsp/JspException.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspException.java 5 Feb 2003 03:09:45 -   1.3
  +++ JspException.java 5 Feb 2003 15:20:25 -   1.4
  @@ -106,7 +106,7 @@
*/
   
   public JspException(String message, Throwable rootCause) {
  - super(message, rootCause);
  + super(message);
this.rootCause = rootCause;
   }
   
  @@ -132,7 +132,7 @@
*/
   
   public JspException(Throwable rootCause) {
  - super(rootCause.getLocalizedMessage(), rootCause);
  + super(rootCause.getLocalizedMessage());
this.rootCause = rootCause;
   }
   
  
  
  

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

cvs commit: jakarta-servletapi-4/src/share/javax/servlet/jsp JspException.java

[jfarcand]

jfarcand2003/02/05 07:18:57

  Modified:src/share/javax/servlet/jsp JspException.java
  Log:
  Revert patch since doesn't work with vm < 1.4
  
  Revision  ChangesPath
  1.3   +2 -2  
jakarta-servletapi-4/src/share/javax/servlet/jsp/JspException.java
  
  Index: JspException.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/jsp/JspException.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JspException.java 5 Feb 2003 03:07:44 -   1.2
  +++ JspException.java 5 Feb 2003 15:18:57 -   1.3
  @@ -106,7 +106,7 @@
*/
   
   public JspException(String message, Throwable rootCause) {
  -super(message, rootCause);
  +super(message);
   this.rootCause = rootCause;
   }
   
  @@ -132,7 +132,7 @@
*/
   
   public JspException(Throwable rootCause) {
  -   super(rootCause.getLocalizedMessage(), rootCause);
  +   super(rootCause.getLocalizedMessage());
  this.rootCause = rootCause;
   }
   
  
  
  

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

cvs commit: jakarta-servletapi-4/src/share/javax/servlet ServletException.java

[jfarcand]

jfarcand2003/02/05 07:17:47

  Modified:src/share/javax/servlet ServletException.java
  Log:
  Revert patch seems doesn't works with vm < 1.4
  
  Revision  ChangesPath
  1.3   +2 -2  
jakarta-servletapi-4/src/share/javax/servlet/ServletException.java
  
  Index: ServletException.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/ServletException.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ServletException.java 5 Feb 2003 03:06:33 -   1.2
  +++ ServletException.java 5 Feb 2003 15:17:47 -   1.3
  @@ -129,7 +129,7 @@
*/
   
   public ServletException(String message, Throwable rootCause) {
  -   super(message, rootCause);
  +   super(message);
  this.rootCause = rootCause;
   }
   
  @@ -158,7 +158,7 @@
*/
   
   public ServletException(Throwable rootCause) {
  -   super(rootCause.getLocalizedMessage(), rootCause);
  +   super(rootCause.getLocalizedMessage());
  this.rootCause = rootCause;
   }
 
  
  
  

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

Re: [PATCH] Root cause lost in Jsp and ServletException

[Jeanfrancois Arcand]

Oups. I tested the patch using 1.4 (having the impression Costin was 
working with 1.3). I will revert the patch.

Thanks,

-- Jeanfrancois

Glenn Nielsen wrote:

BTW, this does not build with JDK's < 1.4 and if you use a servlet.jar
built with 1.4 in a JVM <1.4 you get a NoSuchMethodError.

This change for jakarta-servletapi-4 need to reverted for now.

Glenn


Costin Manolache wrote:


this is for servetapi_4.

Same applies to servletapi_5 ( I already sent a patch few weeks ago ).

The problem is that JDK1.4 stack traces can't find the root cause.

AFAIK nothing in the servlet or JSP specs requires breaking the normal
contract for exceptions - which is to pass the root cause to the parent.

Costin

Index: src/share/javax/servlet/ServletException.java
===
RCS file:
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/ServletException.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ServletException.java
--- src/share/javax/servlet/ServletException.java   9 Jan 2001 
03:24:16 -
1.1.1.1
+++ src/share/javax/servlet/ServletException.java   4 Feb 2003 
19:00:30 -
@@ -129,7 +129,7 @@
  */
  public ServletException(String message, Throwable rootCause) {
-   super(message);
+   super(message, rootCause);
this.rootCause = rootCause;
 }
 
@@ -158,7 +158,7 @@
  */
 
 public ServletException(Throwable rootCause) {
-   super(rootCause.getLocalizedMessage());
+   super(rootCause.getLocalizedMessage(), rootCause);
this.rootCause = rootCause;
 }
   Index: src/share/javax/servlet/jsp/JspException.java
===
RCS file:
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/jsp/JspException.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspException.java
--- src/share/javax/servlet/jsp/JspException.java   9 Jan 2001 
03:24:20 -
1.1.1.1
+++ src/share/javax/servlet/jsp/JspException.java   4 Feb 2003 
19:00:31 -
@@ -106,7 +106,7 @@
  */
  public JspException(String message, Throwable rootCause) {
-   super(message);
+   super(message, rootCause);
this.rootCause = rootCause;
 }
 
@@ -132,7 +132,7 @@
  */
 
 public JspException(Throwable rootCause) {
-   super(rootCause.getLocalizedMessage());
+   super(rootCause.getLocalizedMessage(), rootCause);
this.rootCause = rootCause;
 }
 


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





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

Re: [PATCH] Root cause lost in Jsp and ServletException

[Glenn Nielsen]

BTW, this does not build with JDK's < 1.4 and if you use a servlet.jar
built with 1.4 in a JVM <1.4 you get a NoSuchMethodError.

This change for jakarta-servletapi-4 need to reverted for now.

Glenn


Costin Manolache wrote:

this is for servetapi_4.

Same applies to servletapi_5 ( I already sent a patch few weeks ago ).

The problem is that JDK1.4 stack traces can't find the root cause.

AFAIK nothing in the servlet or JSP specs requires breaking the normal
contract for exceptions - which is to pass the root cause to the parent.

Costin

Index: src/share/javax/servlet/ServletException.java
===
RCS file:
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/ServletException.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ServletException.java
--- src/share/javax/servlet/ServletException.java   9 Jan 2001 03:24:16 -
1.1.1.1
+++ src/share/javax/servlet/ServletException.java   4 Feb 2003 19:00:30 -
@@ -129,7 +129,7 @@
  */
 
 public ServletException(String message, Throwable rootCause) {
-   super(message);
+   super(message, rootCause);
this.rootCause = rootCause;
 }
 
@@ -158,7 +158,7 @@
  */
 
 public ServletException(Throwable rootCause) {
-   super(rootCause.getLocalizedMessage());
+   super(rootCause.getLocalizedMessage(), rootCause);
this.rootCause = rootCause;
 }
   
Index: src/share/javax/servlet/jsp/JspException.java
===
RCS file:
/home/cvs/jakarta-servletapi-4/src/share/javax/servlet/jsp/JspException.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 JspException.java
--- src/share/javax/servlet/jsp/JspException.java   9 Jan 2001 03:24:20 -
1.1.1.1
+++ src/share/javax/servlet/jsp/JspException.java   4 Feb 2003 19:00:31 -
@@ -106,7 +106,7 @@
  */
 
 public JspException(String message, Throwable rootCause) {
-   super(message);
+   super(message, rootCause);
this.rootCause = rootCause;
 }
 
@@ -132,7 +132,7 @@
  */
 
 public JspException(Throwable rootCause) {
-   super(rootCause.getLocalizedMessage());
+   super(rootCause.getLocalizedMessage(), rootCause);
this.rootCause = rootCause;
 }
 


-
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: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[Larry Isaacs]

I've haven't looked at the full source in a while, so I'm
somewhat guessing at the exact impact.  I'm working on a
Tomcat 3.3.2 release plan which will need to integrate
use of the J-T-C connectors.  I should be able to take a
more in depth look at this as part of that.

I wouldn't see it as a step forward where we increase
the vulnerability of the majority, and the effort needed
to deal with that, in favor of satisfying a small minority
that insist on using inherently unsafe escape sequences.

Maybe this new behavior should be an option like it is in
Tomcat 3.3.x.  The default is to err on the side of safety.
Operating in this less safe envrionment could be specifically
requested via an option, and the user is responsible for
dealing with the impact.  How does that sound?

Cheers,
Larry

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, February 05, 2003 4:04 AM
> To: 'Tomcat Developers List'
> Subject: RE: cvs commit: 
> jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
> 
> 
> Larry,
> 
> > 
> > Sorry, Clicked the wrong button. :)
> > 
> 
> No problem, :), i undertands the concerns, and the change 
> seems a little
> daring i know.. anyway, reviewing by peers works, thanks god.. :)
> 
> > To finish the thought, with the change below, does
> > 
> > http://localhost/test%2F/test.jsp
> > 
> > still go to Tomcat?  Or is it blocked from going
> > to Tomcat because it is a "bad" URL.  If it doesn't
> > go to Tomcat, how do we know some other filter in the
> > chain isn't going to serve it statically?
> > 
> 
> take into account that to be able to map we first need to unescape the
> url. it's the unescaping function the one that gives this 
> errors, so we
> can only block these url prior to do the mapping, so we 
> really dont know
> if the url should go to tomcat or not at this point.. 
> 
> And It's almost the same case that in apache you need to explicitely
> block WEB-INF, if you want block people from look at there 
> when using a
> configuration where tomcat context it's directly configured 
> as an apache
> served directory.. something that needs to be tweaked to be secure..
> 
> I think this is the same case, it's an advanced 
> configuration, there are
> posible source disclosures, but it's a risk you can sort out.. like in
> the apache WEB-INF case..
> 
> And the casual and default configuration, doesnt have this "advance"
> features..
> 
> Do you see other way to fix 16759?
> 
> Saludos, 
> Ignacio J. Ortega 
> 
> 
> 

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

DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.

[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=14261

JNDI data source not configured correctly.





--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 13:14 ---
Yes, as global resources classes are resolved in the server classloader
(otherwise, they would be local), they would need to be located in common/lib or
common/classes.

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

DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.

[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=14261

JNDI data source not configured correctly.





--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 13:03 ---
I came to use the default context because I could not get the global resources
to work. It does work with a standard DataSource but not with my special one. 
It's probably a classloading problem, as the classes for the Datasource and the
factory are located within the webapplication war. (wild guess :-).

The point is, that using the DefaultContext is apparently only _mostly_ the same
as defining resources in every context. It _does_ work if you define them in
every context.

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

Re: Fwd: tomcat's serlvet container and http

[Remy Maucherat]

rf wrote:


Hello
I have some questions related to how tomcat's servlet
container handles some HTTP/1.1 issues. Understanding
these, I think, would be beneficial in improving the
performance of my web-application. Here they go



1. How can my servlet respond with transfer encoding
as chunked? When is my serlvet's OutputStream
committed? I dont have all my data ready, I want send
it out in chunks - how do I do it?


This is not your servlet's problem (it's the container's problem).


2. How can I use "100 Continue" response header? This
is usually used on slow links, but I want to use it
when my processing is slow. My servlet is doing some
processing and is going to take some more time - how
do I inform this to my client? Can I just set
HttpServletResponse.setStatus (SC_CONTINUE)? (Can this
response be sent more than once?) If this method is
not right for the scenario, what is the recommended
way of informing the client to patiently wait for some
more time?


You cannot use 100 with the Servlet API. As Tomcat is already using 100 
(it is sent just before invoking the servlet if it has been requested by 
the client), you actually shouldn't try doing anything with it.
Again, it is a protocol feature, and your servlet should nt try to do 
anything with it.

3. The response in HTTP/1.1 can have "footers" in
addition to "headers", how do I set a "footer"? I
guess we cannot use HttpServletResponse.setHeader
because the servlet spec says setting a header has no
effect if the response is already committed.


This is not supported by the Servlet API.


4. Persistant connections - is this configurable in a
tomcat? It might be the case that this is not
something a user should bother about, the servlet
container will take care of it. What does tomcat do?
Whenever needed, I want to recommend my client to use
a persistant connection for following requests. Can I
do it? An IE question: what factors determine that IE
should use a persistant connection?


Same here, it is a protocol feature.


5. If-modified-since header. There is a
getLastModified method in the servlet interface, this
returns a long(for date). I guess I should implement
this method for tomcat to respect the
if-modified-since header. I recently implemented a
caching filter, which intelligently uses the default
servlet to serve cached static content. But since the
former method is simple and more effective, I would
like to know when IE uses this header. Since this
header is optional, how do I recommend IE to use it?


That's one of the few things your servlet should handle. There are 
examples in the Tomcat code if you need some.

Remy


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

bean with jsp

[Sachin Chowdhary]

I am trying to use a class by using useBean tag in jsp but i am not able to
do it so remove all coding and just using import class name syntax but still
i am not able to do that on tomcat4.1.18 .so what i am doing wrong

can you suggest me


C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\jsp
<%@ page import="MyClass" %>



Meet a Bean!
   


//MyClass.java


C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\WEB-INF\classes
public class MyClass
{
 public String val;
}



HTTP Status 500 -

type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
org.apache.jasper.JasperException: Unable to compile class for JSP

An error occurred at line: -1 in the jsp file: null

Generated servlet error:
[javac] Compiling 1 source file

C:\Program Files\Apache Group\Tomcat
4.1\work\Standalone\localhost\examples\jsp\MyJsp_jsp.java:7: '.' expected
import MyClass;
  ^
1 error




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

Fwd: tomcat's serlvet container and http

[rf]

Hello
I have some questions related to how tomcat's servlet
container handles some HTTP/1.1 issues. Understanding
these, I think, would be beneficial in improving the
performance of my web-application. Here they go:

1. How can my servlet respond with transfer encoding
as chunked? When is my serlvet's OutputStream
committed? I dont have all my data ready, I want send
it out in chunks - how do I do it?

2. How can I use "100 Continue" response header? This
is usually used on slow links, but I want to use it
when my processing is slow. My servlet is doing some
processing and is going to take some more time - how
do I inform this to my client? Can I just set
HttpServletResponse.setStatus (SC_CONTINUE)? (Can this
response be sent more than once?) If this method is
not right for the scenario, what is the recommended
way of informing the client to patiently wait for some
more time?

3. The response in HTTP/1.1 can have "footers" in
addition to "headers", how do I set a "footer"? I
guess we cannot use HttpServletResponse.setHeader
because the servlet spec says setting a header has no
effect if the response is already committed.

4. Persistant connections - is this configurable in a
tomcat? It might be the case that this is not
something a user should bother about, the servlet
container will take care of it. What does tomcat do?
Whenever needed, I want to recommend my client to use
a persistant connection for following requests. Can I
do it? An IE question: what factors determine that IE
should use a persistant connection?

5. If-modified-since header. There is a
getLastModified method in the servlet interface, this
returns a long(for date). I guess I should implement
this method for tomcat to respect the
if-modified-since header. I recently implemented a
caching filter, which intelligently uses the default
servlet to serve cached static content. But since the
former method is simple and more effective, I would
like to know when IE uses this header. Since this
header is optional, how do I recommend IE to use it?

Thank you,
~rf



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

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

DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.

[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=14261

JNDI data source not configured correctly.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 11:44 ---
No, you are confusing diffrent things. Using the default context is mostly the
same as defining a data source in each context (= it is not global). Due to
limitations in the default context model, I don't think this can be made to work
in your situation, and you should use the global resources instead (I improved
it as much as I could).

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

DO NOT REPLY [Bug 14261] - JNDI data source not configured correctly.

[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=14261

JNDI data source not configured correctly.





--- Additional Comments From [EMAIL PROTECTED]  2003-02-05 11:15 ---
I have run into something what seems like this bug as well. I have a DataSource
with a selfwritten JNDI ObjectFactory configured in the DefaultContext:


  
  

  factory
  de.cegedim.iss.naming.OracleConnectionCacheFactory

...
  


I have a ServletContextListener registered. In the #contextInitialized method
and during Servlet#init the DataSource returned if of type BasicDataSource and
the driverName is null.

But when the first request comes, everything works as intended. A JNDI Lookup
returns a OracleXAConnectionCacheTyrexImpl.

when I put the same Resource definition into a  tag for a single
webapplication, it does work even in the
ServletContextListener#contextInitialized method. It seems like the binding of
Global Resources to the context happens to late.

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

RE: cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[Ignacio J. Ortega]

Larry,

> 
> Sorry, Clicked the wrong button. :)
> 

No problem, :), i undertands the concerns, and the change seems a little
daring i know.. anyway, reviewing by peers works, thanks god.. :)

> To finish the thought, with the change below, does
> 
> http://localhost/test%2F/test.jsp
> 
> still go to Tomcat?  Or is it blocked from going
> to Tomcat because it is a "bad" URL.  If it doesn't
> go to Tomcat, how do we know some other filter in the
> chain isn't going to serve it statically?
> 

take into account that to be able to map we first need to unescape the
url. it's the unescaping function the one that gives this errors, so we
can only block these url prior to do the mapping, so we really dont know
if the url should go to tomcat or not at this point.. 

And It's almost the same case that in apache you need to explicitely
block WEB-INF, if you want block people from look at there when using a
configuration where tomcat context it's directly configured as an apache
served directory.. something that needs to be tweaked to be secure..

I think this is the same case, it's an advanced configuration, there are
posible source disclosures, but it's a risk you can sort out.. like in
the apache WEB-INF case..

And the casual and default configuration, doesnt have this "advance"
features..

Do you see other way to fix 16759?

Saludos, 
Ignacio J. Ortega 



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

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

[remm]

remm2003/02/05 00:44:09

  Modified:.build.properties.default
  Log:
  - Fix download target.
  
  Revision  ChangesPath
  1.66  +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.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- build.properties.default  4 Feb 2003 23:41:01 -   1.65
  +++ build.properties.default  5 Feb 2003 08:44:09 -   1.66
  @@ -76,7 +76,7 @@
   
   # - Commons Expression Language (EL) -
   commons-el.home=${base.path}/commons-el
  -commons-el.lib=${commons-el.home}
  +commons-el.lib=${commons-el.home}/dist
   commons-el.jar=${commons-el.lib}/commons-el.jar
   commons-el.loc=jakarta-commons/el
   commons-el.cvs.loc=jakarta-commons/el
  
  
  

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

cvs commit: jakarta-tomcat-jasper/jasper2/lib jsp20el.jar

[remm]

remm2003/02/05 00:43:30

  Removed: jasper2/lib jsp20el.jar
  Log:
  - Remove useless binary.

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

cvs commit: jakarta-tomcat-jasper/jasper2 build.xml

[remm]

remm2003/02/05 00:43:02

  Modified:jasper2  build.xml
  Log:
  - Fix Jasper build.
  
  Revision  ChangesPath
  1.20  +3 -4  jakarta-tomcat-jasper/jasper2/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/build.xml,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- build.xml 22 Jan 2003 23:07:38 -  1.19
  +++ build.xml 5 Feb 2003 08:43:02 -   1.20
  @@ -21,7 +21,6 @@
 
 
 
  -  
   
   
 
  @@ -33,11 +32,11 @@
   
   
   
  +
   
   
   
   
  -
 
   
 
  @@ -154,7 +153,7 @@
   
   
   
  -
  +
   
 
   
  @@ -244,7 +243,7 @@
   
   
   
  -
  +
   
 
   
  
  
  

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

disable log rotation - opinion

[Radek Wierzbicki]

I want to know your opinion on the topic of adding an
option to FileLogger to disable log rotation. Here is a
bug (enhancement) for that:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16596

Is it possible to build that into any next release of
Tomcat?

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