Re: NullPointerException from HttpSessionFacade.invalidate()

[Gokul Singh]

- Original Message -
From: Craig R. McClanahan
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]

Thanks for looking into the problem. I think the I was not able to convey
the problem properly. I have some clarifications below.

> The session object is valid for more than one request, but only up until
the time that it is invalidated.  After that, further access to the old
session object is illegal.

Agreed. But this is not what I am doing. The session is valid.
You can remove the lines of code
listed below from the code I posted and still you will get the Exception.
Remove the following two lines and follow the steps mentioned in the earlier
mail to reproduce the error.
==
if(objSession != null)
   objSession.invalidate();
==


> The reason you see a behavior difference is that Tomcat 3.1 did not
recycle session object instances, but Tomcat 3.2 does.


There lies the catch and the source of problem in my understanding.
 In different requests relating to
the same session, I may get referance to HttpSessionFacade instances which
are different, but I expect them to be same (although not guarantied by
specs but I thought it was a tacit agreement between container and servlet
developer). What I suggest is that tomcat should recycle the
HttpSessionFacade instance only when the HttpSession instance is
recycled.This might be more inefficient as it will result in N instances on
HttpSessionFacade if there are N valid sessions on the server, where as in
the present scenario, if my understanding is correct, there will be X
instances of HttpSessionFacade if there are X simultaneous requests. and X
is less than N.

To be more elaborate:
Lets us assume the following scenario.

1. A request comes which creates a new session. A HttpSession object (HS1)
is created and the Facade object (HSF1) wraps around it.
2. I store a referance to the session in the context that is a handle to
HSF1 which maps to the userid.
2. Another request comes from the same session . The object made available
to the request is not necessarily HSF1 and may be HSFx which wraps around
HS1.
3. At this point in time HSF1 may wrapped around another instance of HS or
nothing at all ( null).
4. I get the handle to the session which I want to invalidate from the
context which is HSF1. Now I am in trouble due to the point above.

In my opinion HSF1 should not refer to any other session till HS1 is
invalidated (or timed out).

What should I do to avoid this problem?

Why am I storing the referance of a session in context?
I want to prevent double login of the same user and on
the second login want to invalidate his previous login. The second login may
be from a different machine with no valid session.

Regds,
Gokul

>
> Craig McClanahan
>


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

Re: cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http SocketInputStream.java

[Thomas Butter]

[EMAIL PROTECTED] wrote:

> remm01/01/11 22:51:58
> 
>   Modified:catalina/src/share/org/apache/catalina/connector/http
> SocketInputStream.java
>   Log:
>   - Merge with some code inspired from code from BufferedInputStream.
>   - Removed some unnecessary synchronization (to be confirmed). If the
> sync was necessary, I suggest doing it in the RequestInputStream.read()
> instead.
>   
> 
> */
>   -public class SocketInputStream extends BufferedInputStream {
>   +public class SocketInputStream extends InputStream {
>

I think you should subclass FilterInputStream, because it will provide 
you default implementations for the read(xxx) methods by calling the 
read() method.

-- 
Thomas Butter <[EMAIL PROTECTED]>  ICQ: 891617

"Unix IS user friendly, it is just selective about who his friends are."


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

BugRat Report #750 has been filed.

[BugRat Mail System]

Bug report #750 has just been filed.

You can view the report at the following URL:

   

REPORT #750 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: low
Severity: critical
Confidence: public
Environment: 
   Release: 4.0-20010111
   JVM Release: JDK1.3
   Operating System: Win 2000 Pro
   OS Release: 5.00.2195
   Platform: Intel

Synopsis: 
webwork.war (webwork 0.9) fails in 4.0, ok in 3.2.1

Description:
Just wanted to let you know that the webwork system 
(http://sourceforge.net/projects/webwork/)
is not installable with the latest nightly build (20010111).
XML parsing error.
erik


Title: 
BugRat Report #
750





BugRat Report #
750




Project:
Tomcat


Release:
4.0-20010111




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
low


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 04:32:02 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

webwork.war (webwork 0.9) fails in 4.0, ok in 3.2.1


 Environment: (jvm, os, osrel, platform)

JDK1.3, Win 2000 Pro, 5.00.2195, Intel



Additional Environment Description:





Report Description:

Just wanted to let you know that the webwork system (http://sourceforge.net/projects/webwork/)
is not installable with the latest nightly build (20010111).
XML parsing error.
erik




View this report online...






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

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Ignacio J. Ortega]

Hola Hans , Marc:

You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks
ago , that seems to resolve this problem, were reports #619 #653 #513 ,
and i think this is resolved in CVS, please review it and i will revise
BugRat to close related bugs , if you agree it's already resolved..


Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans
> Bergsten
> Enviado el: viernes 12 de enero de 2001 8:46
> Para: [EMAIL PROTECTED]
> Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
> 
> 
> Marc Saegesser wrote:
> > 
> > Regarding BugReport #744.  I've been trying to duplicate it 
> on my Win2000
> > system and haven't had any luck.  I always get back the 
> executed page.  Has
> > anyone else been able to duplicate the problem behavior?
> 
> I actually tested it today (on a Red Hat 7 system, but I doubt that
> matters)
> and was able to reproduce it easily; just make a GET request 
> without the
> protocol. I haven't had a chance to try to figure out why yet though.
> 
> > [...]
> 
> Hans
> -- 
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software   http://www.gefionsoftware.com
> Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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

BugRat Report #166 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #166 was closed by Person #0

   Synopsis: When I start tomcat on Win2000 I get the following error message

 (logged in as: Ignacio Ortega)

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

BugRat Report #628 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #628 was closed by Person #0

   Synopsis: Will not run unless logged in as adminstrator

 (logged in as: Ignacio Ortega)

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

BugRat Report #722 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #722 was closed by Person #0

   Synopsis: Tomcat with Win 2000 ?

 (logged in as: Ignacio Ortega)

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

BugRat Report #725 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #725 was closed by Person #0

   Synopsis: segmentation violation at first http request

 (logged in as: Ignacio Ortega)

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

BugRat Report #721 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #721 was closed by Person #0

   Synopsis: a

 (logged in as: Ignacio Ortega)

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

JSP Forward forwarding back to itself

[Mary O'Grady]

Does anyone know how to get a JSP forward command to send you back to the
same back it was called from. We have tried this and it doesn't not appear
to work. Any ideas on workarounds.

Thanks
Mary


*

Privileged/Confidential Information may be contained in this message.  If you are not 
the recipient
addressee indicated in this message you may not copy or deliver this message to 
anyone.  In such
case, you should destroy this message and notify us immediately.  If you or your 
employer do not
consent to internet email messages of this kind, please advise us immediately.  
Opinions, conclusions
and other information expressed in this message are not given or endorsed by VISION 
Consulting
unless otherwise indicated by an authorised representative independent of this message.

*

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

patch against Tomcat-Workers-Howto

[Thom May]

Hi guys,
reading my way through the documentation, i've been
finding things that look "wrong"- I'm creating patches
for the obvious bits as I go, but I think this one needs to be done...
What do you think?
cheers,
-Thom


Index: src/doc/Tomcat-Workers-HowTo.html
===
RCS file: /home/cvspublic/jakarta-tomcat/src/doc/Tomcat-Workers-HowTo.html,v
retrieving revision 1.1
diff -u -r1.1 Tomcat-Workers-HowTo.html
--- src/doc/Tomcat-Workers-HowTo.html   2000/06/19 10:08:36 1.1
+++ src/doc/Tomcat-Workers-HowTo.html   2001/01/12 13:53:37
@@ -164,7 +164,7 @@
   worker.local.type=ajp12
   
   
-  Defines a worker named local that use the ajpv12 protocol
+  Defines a worker named "local" that uses the ajpv12 protocol
   to forward requests to a Tomcat process.
   
  
@@ -173,7 +173,7 @@
   worker.remote.type=ajp13
   
   
-  Defines a worker named local that use the ajpv12 protocol
+  Defines a worker named "remote" that uses the ajpv13 protocol
   to forward requests to a Tomcat process.
   
  
@@ -182,7 +182,7 @@
   worker.fast.type=jni
   
   
-  Defines a worker named local that use the ajpv12 protocol
+  Defines a worker named "fast" that uses JNI
   to forward requests to a Tomcat process.
   
  
@@ -191,8 +191,8 @@
   worker.loadbalancer.type=lb
   
   
-  Defines a worker named local that use the ajpv12 protocol
-  to forward requests to a Tomcat process.
+  Defines a worker named "loadbalancer" that 
+  loadbalances several Tomcat processes transparently.
   
  
 
@@ -600,4 +600,4 @@
 work.
 
 
-
\ No newline at end of file
+



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

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Marc Saegesser]

I cvsup and build from source several times a week to make sure none of the
changes going in have any detrimental effects on my application.  I'm
testing with the latest on the tomcat_32 branch.

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 12, 2001 5:03 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
>
>
> Hola Hans , Marc:
>
> You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks
> ago , that seems to resolve this problem, were reports #619 #653 #513 ,
> and i think this is resolved in CVS, please review it and i will revise
> BugRat to close related bugs , if you agree it's already resolved..
>
>
> Saludos ,
> Ignacio J. Ortega
>
>
> > -Mensaje original-
> > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans
> > Bergsten
> > Enviado el: viernes 12 de enero de 2001 8:46
> > Para: [EMAIL PROTECTED]
> > Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
> >
> >
> > Marc Saegesser wrote:
> > >
> > > Regarding BugReport #744.  I've been trying to duplicate it
> > on my Win2000
> > > system and haven't had any luck.  I always get back the
> > executed page.  Has
> > > anyone else been able to duplicate the problem behavior?
> >
> > I actually tested it today (on a Red Hat 7 system, but I doubt that
> > matters)
> > and was able to reproduce it easily; just make a GET request
> > without the
> > protocol. I haven't had a chance to try to figure out why yet though.
> >
> > > [...]
> >
> > Hans
> > --
> > Hans Bergsten   [EMAIL PROTECTED]
> > Gefion Software http://www.gefionsoftware.com
> > Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Ignacio J. Ortega]

So you cant found a buggy behavior, it's solved by the previously pathc
aplied , isn't it?

I will close that report , and declare it resolved, if nobody
complains..

Sorry i read exactly the inverse of your message, that is you can probe
the buggy behavior  :-), 

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Enviado el: viernes 12 de enero de 2001 15:12
> Para: [EMAIL PROTECTED]
> Asunto: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
> 
> 
> I cvsup and build from source several times a week to make 
> sure none of the
> changes going in have any detrimental effects on my application.  I'm
> testing with the latest on the tomcat_32 branch.
> 
> > -Original Message-
> > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 12, 2001 5:03 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has 
> been filed.]
> >
> >
> > Hola Hans , Marc:
> >
> > You are using 3.2 from CVS AFAIK i did apply a patch 2 
> oe 3 weeks
> > ago , that seems to resolve this problem, were reports #619 
> #653 #513 ,
> > and i think this is resolved in CVS, please review it and i 
> will revise
> > BugRat to close related bugs , if you agree it's already resolved..
> >
> >
> > Saludos ,
> > Ignacio J. Ortega
> >
> >
> > > -Mensaje original-
> > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans
> > > Bergsten
> > > Enviado el: viernes 12 de enero de 2001 8:46
> > > Para: [EMAIL PROTECTED]
> > > Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has 
> been filed.]
> > >
> > >
> > > Marc Saegesser wrote:
> > > >
> > > > Regarding BugReport #744.  I've been trying to duplicate it
> > > on my Win2000
> > > > system and haven't had any luck.  I always get back the
> > > executed page.  Has
> > > > anyone else been able to duplicate the problem behavior?
> > >
> > > I actually tested it today (on a Red Hat 7 system, but I 
> doubt that
> > > matters)
> > > and was able to reproduce it easily; just make a GET request
> > > without the
> > > protocol. I haven't had a chance to try to figure out why 
> yet though.
> > >
> > > > [...]
> > >
> > > Hans
> > > --
> > > Hans Bergsten [EMAIL PROTECTED]
> > > Gefion Software   http://www.gefionsoftware.com
> > > Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> > >
> > > 
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> > >
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Marc Saegesser]

I'd like to hear from Hans before we close the report.  He was able to
duplicate the problem but I wasn't.  If he's running tomcat_321_final then
that would be expected, if he's using tomcat_32 latest and still seeing the
problem then something else is wrong.

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 12, 2001 8:21 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
>
>
> So you cant found a buggy behavior, it's solved by the previously pathc
> aplied , isn't it?
>
> I will close that report , and declare it resolved, if nobody
> complains..
>
> Sorry i read exactly the inverse of your message, that is you can probe
> the buggy behavior  :-),
>
> Saludos ,
> Ignacio J. Ortega
>
>
> > -Mensaje original-
> > De: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> > Enviado el: viernes 12 de enero de 2001 15:12
> > Para: [EMAIL PROTECTED]
> > Asunto: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
> >
> >
> > I cvsup and build from source several times a week to make
> > sure none of the
> > changes going in have any detrimental effects on my application.  I'm
> > testing with the latest on the tomcat_32 branch.
> >
> > > -Original Message-
> > > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, January 12, 2001 5:03 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has
> > been filed.]
> > >
> > >
> > > Hola Hans , Marc:
> > >
> > > You are using 3.2 from CVS AFAIK i did apply a patch 2
> > oe 3 weeks
> > > ago , that seems to resolve this problem, were reports #619
> > #653 #513 ,
> > > and i think this is resolved in CVS, please review it and i
> > will revise
> > > BugRat to close related bugs , if you agree it's already resolved..
> > >
> > >
> > > Saludos ,
> > > Ignacio J. Ortega
> > >
> > >
> > > > -Mensaje original-
> > > > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Hans
> > > > Bergsten
> > > > Enviado el: viernes 12 de enero de 2001 8:46
> > > > Para: [EMAIL PROTECTED]
> > > > Asunto: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has
> > been filed.]
> > > >
> > > >
> > > > Marc Saegesser wrote:
> > > > >
> > > > > Regarding BugReport #744.  I've been trying to duplicate it
> > > > on my Win2000
> > > > > system and haven't had any luck.  I always get back the
> > > > executed page.  Has
> > > > > anyone else been able to duplicate the problem behavior?
> > > >
> > > > I actually tested it today (on a Red Hat 7 system, but I
> > doubt that
> > > > matters)
> > > > and was able to reproduce it easily; just make a GET request
> > > > without the
> > > > protocol. I haven't had a chance to try to figure out why
> > yet though.
> > > >
> > > > > [...]
> > > >
> > > > Hans
> > > > --
> > > > Hans Bergsten   [EMAIL PROTECTED]
> > > > Gefion Software http://www.gefionsoftware.com
> > > > Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
> > > >
> > > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, email: [EMAIL PROTECTED]
> > > >
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

possible problem with CLIENT-CERT login and security constraint on TOMCAT 4.0

[jerome . camilleri]

Hi,

I try to configure TOMCAT server to authenticate client with certificate on HTTPS protocol.

My connector is configure to accept request on 8443 port like this :
    
               port="8443" minProcessors="5" maxProcessors="75"
               acceptCount="10" debug="0" scheme="https" secure="true">
      
               clientAuth="true" protocol="TLS" keystorePass="password1"/>
    

My tomcat-user.xml file is configured with a new entry that match the getSubjectDN().getName() of client certificat used :
 
   
   
   
   
 

I also uncomment the security constraint on my web.xml file like this
  
    
      The Entire Web Application
      /*
    
    
      tomcat
    
  

  
    CLIENT-CERT
    Tomcat Supported Realm
  

  
    
      An example role defined in "conf/tomcat-users.xml"
    
    tomcat
  

My problem is when I try to connect on my tomcat serveur  I have always the same message : 
HTTP Error 403 - Forbidden

Possibly reasons :
I try to compare BASIC authenticator  and CLIENT-CERT authenticator.
    * BasicAuthenticator class register an MemoryRealmPrincipal object return by the MemoryRealm class 
    * SSLAuthenticator class register an Principal object with  is simply return by certs[0].getSubjectDN() method (and has no role associated)

When I modified a little bit the SSLAuthenticator class to find on the MemoryRealm the MemoryRealmPrincipal
associated with the username = certs[0].getSubjectDN().getName()  ( with no password) that seems run better...

Excuse me, if it's a know limitation, a bug already know or a bad settings ...


Jérôme

BugRat Report #751 has been filed.

[BugRat Mail System]

Bug report #751 has just been filed.

You can view the report at the following URL:

   

REPORT #751 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.3.0
   Operating System: Linux 2.2.16
   OS Release: Red Hat Linux 7.0
   Platform: x86

Synopsis: 
NullPointerException thrown in SessionInterceptor when debug logging is on

Description:
When embedding Tomcat into my application using EmbededTomcat, I started
seeing NullPointerException being thrown on every HTTP request to the
server.  On tracing through the source code, I found the problem
in line 136 of SessionInterceptor.java:

public int beforeBody( Request rrequest, Response response ) {
String reqSessionId = response.getSessionId();
==> if( debug>0 ) cm.log("Before Body " + reqSessionId );
if( reqSessionId==null)
return 0;

If response.getSessionId() returns null and debug logging is
turned on, the code attempts to concatenate a string with null,
resulting in the NullPointerException seen.


Title: 
BugRat Report #
751





BugRat Report #
751




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
medium


Severity:
serious




Confidence:
public





Submitter:
Kris Zaragoza ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 10:19:19 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

NullPointerException thrown in SessionInterceptor when debug logging is on


 Environment: (jvm, os, osrel, platform)

1.3.0, Linux 2.2.16, Red Hat Linux 7.0, x86



Additional Environment Description:





Report Description:

When embedding Tomcat into my application using EmbededTomcat, I started
seeing NullPointerException being thrown on every HTTP request to the
server.  On tracing through the source code, I found the problem
in line 136 of SessionInterceptor.java:

public int beforeBody( Request rrequest, Response response ) {
String reqSessionId = response.getSessionId();
==> if( debug>0 ) cm.log("Before Body " + reqSessionId );
if( reqSessionId==null)
return 0;

If response.getSessionId() returns null and debug logging is
turned on, the code attempts to concatenate a string with null,
resulting in the NullPointerException seen.




How To Reproduce:

null



Workaround:

null



View this report online...






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

3.2 cvs problems with ROOT context?

[Ignacio J. Ortega]

Hola a todos:

I dong a brief review of 3.2.2 from cvs this evening, only to give a
look over the latest ( big ) changes and so on...

But after a cvs update a "build all" and double checked everything
AFAIK, i can not get http://localhost:8080/ in my browser, i can access
examples context but it seems that i can not access ROOT context  @:( ,
so i'm really suprised and stucked, do a new check of everything , and
nope!! nothings works in the ROOT context 

IMHO i'm forgetting something, or i can fire my dev system or i'm mad (
as usual )...

Being addicted to debuggers,i did a try, a simple look inside, and whats
my surprise  ROOT context is mounted !!! but in "" path and
SimpleMapper1 is trying to map a path="/" . I recall that the
correct behavior the path as "" not "/" but... i've decided to ask
everybody, to test that nothing is bad on my side...

Everybody can access a freshly checkout of Tomcat 3.2.2 from cvs build
them and access http://localhost:8080 without problems??? 

Saludos ,
Ignacio J. Ortega

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

[PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x)

[Benoit Derouet]

Hi,

The load balancer worker fail to handle load balancing (with sticky
sessions) if the application uses custom cookies.

In some circumstances, the load balancer worker can't retreive the server
name from the JSessionID cookie and is not able to redirect to the good
server.

The algorithm parse the cookie header to extract the server name from the
JSessionID cookie. It find properly the end of the server name but fail to
cut the chars after.
So, it works fine if the cookie header contains only one cookie (or if
JSessionID is the last cookie) but If they are custom cookie, the server
name extracted will be: "servername;mycookieVal=myCookieValue .."

The bug is fixed around line 170.
(line id_end=NULL; replaced by id_end[0] = '\0'; )

'hope this will be integrated in future versions ! (as our customers need
sticky load balancing...)

regards.

Benoit

 jk_lb_worker.c

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

Re: possible problem with CLIENT-CERT login and security constraint on TOMCAT 4.0

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:
 
Hi,
I try to configure TOMCAT server
to authenticate client with certificate on HTTPS protocol.
My connector is configure to accept
request on 8443 port like this :
    
  
port="8443" minProcessors="5" maxProcessors="75"
  
acceptCount="10" debug="0" scheme="https" secure="true">
 

  
clientAuth="true" protocol="TLS" keystorePass="password1"/>
    
My tomcat-user.xml file is configured
with a new entry that match the getSubjectDN().getName() of client certificat
used :

  
  
  
  

I also uncomment the security
constraint on my web.xml file like this
  
    
 
The Entire Web Application
 
/*
    
    
 
tomcat
    
  
  
    CLIENT-CERT
    Tomcat
Supported Realm
  
  
    
 
An example role defined in "conf/tomcat-users.xml"
    
    tomcat
  
My problem is when I try to connect
on my tomcat serveur  I have always the same message :
HTTP Error 403 - Forbidden
Possibly reasons :
I try to compare BASIC authenticator 
and CLIENT-CERT authenticator.
    * BasicAuthenticator
class register an MemoryRealmPrincipal object return by the MemoryRealm
class
    * SSLAuthenticator
class register an Principal object with  is simply return by certs[0].getSubjectDN()
method (and has no role associated)
When I modified a little bit the
SSLAuthenticator class to find on the MemoryRealm the MemoryRealmPrincipal
associated with the username
= certs[0].getSubjectDN().getName()  ( with no password) that seems
run better...
Excuse me, if it's a know limitation,
a bug already know or a bad settings ...
 
Jérôme
In order to use CLIENT-CERT authentication, you *must* set up a user in
whatever Realm is used for authentication, with a username equal to certs[0].getSubjectDN(). 
This is needed for the following reasons:
* To know that this is a valid user for *this* application,
  (not just that the certificate is valid)
* To know what roles are assigned to this user for
  *this* application.
If you are using the default Realm implementation, this means you must
add an entry to $CATALINA_HOME/conf/tomcat-users.xml for this user.
Craig McClanahan
 

RE: An alternative to JSP

[Tomas Rokicki]

> Whatcha looking for: np.instantis.com ???

Just curious to see what's happening over there, nothing more.
That's what browsers are for.  What's the relevance to Tomcat?

-tom


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

BugRat Report #752 has been filed.

[BugRat Mail System]

Bug report #752 has just been filed.

You can view the report at the following URL:

   

REPORT #752 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: Tomcat 3.2.1
   JVM Release: 1.2.1_04
   Operating System: Solaris
   OS Release: ???
   Platform: SPARC

Synopsis: 
User Principal incorrectly Maintained

Description:
I'm using the JDBCRealm and everything seems to work OK, but I'm actually dynamically 
generating info not just on the Role (which works fine), but the user itself.  I'm 
getting the current user by calling request.getUserPrincipal().getName().  I have a 
user jim and jones both in the same role.  If I log in as jim first, then the 
principal returns jim even if I log out (change or close the browser) and then log in 
as jones.  You can see (below) that the realm is fine and shows the correct user 
logged in and authenticated with the correct role, but then at the bottom when I call 
request.getUserPrincipal().getName() I don't get the correct user.


2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for 
user jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( 
/bow + /reviewer/images/favB.gif + null) Ct ( )
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for 
user jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( 
/bow + /reviewer/images/bow.gif + null) Ct ( )
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Authentication successful for 
user jones
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, user=jones
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Controled access for jones R( 
/bow + /reviewer/review.do + null) Ct 
(action(org.apache.struts.action.ActionServlet/null) )
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer
*** Current User Principal: jim

Title: 
BugRat Report #
752





BugRat Report #
752




Project:
Tomcat


Release:
Tomcat 3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
David Winterfeldt ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 11:25:46 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

User Principal incorrectly Maintained


 Environment: (jvm, os, osrel, platform)

1.2.1_04, Solaris, ???, SPARC



Additional Environment Description:





Report Description:

I'm using the JDBCRealm and everything seems to work OK, but I'm actually dynamically generating info not just on the Role (which works fine), but the user itself.  I'm getting the current user by calling request.getUserPrincipal().getName().  I have a user jim and jones both in the same role.  If I log in as jim first, then the principal returns jim even if I log out (change or close the browser) and then log in as jones.  You can see (below) that the realm is fine and shows the correct user logged in and authenticated with the correct role, but then at the bottom when I call request.getUserPrincipal().getName() I don't get the correct user.


2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for user jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/images/favB.gif + null) Ct ( )
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Authentication successful for user jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, user=jones
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/images/bow.gif + null) Ct ( )
2001-01-12 11:36:26 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Authentication successful for user jones
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, user=jones
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Controled access for jones R( /bow + /reviewer/review.do + null) Ct (action(org.apache.struts.action.ActionServlet/null) )
2001-01-12 11:36:44 - ContextManager: JDBCHashRealm: Auth ok, first role=BOWReviewer
*** Current User Principal: jim



View this report online...






-
To unsubscribe, e-ma

Re: cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/connector/http SocketInputStream.java

[Remy Maucherat]

> I think you should subclass FilterInputStream, because it will provide
> you default implementations for the read(xxx) methods by calling the
> read() method.

InputStream.read(b[], off, len) and skip(n), which are the two that I didn't
implement (yet) look good enough to me (they both will end up calling
read()).
Or am I again making asumptions on how the InputStream class behaves ?

Remy


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

Re: Any solution for bug#696?

[Dan Milstein]

Tomcat 3.2.1 / mod_jk / ajp13 has a bug with File Upload which has been fixed and 
committed in the most recent 3.2 sources.  It *is* more likely to affect binary files, 
so I'm going to guess that that's what you're seeing (assuming you're using ajp13).

You can check out the most recent version of the 3.2 branch from cvs (see the website 
for details), or you can patch the file:

src/share/org/apache/tomcat/service/connector/Ajp13ConnectorRequest.java

I *think* patching that file will capture the whole fix -- you may want to get an 
updated version of the mod_jk files as well.

-Dan

Jin-Ling Kwang wrote:
> 
> Dear TomCat Bugs Team,
> 
> I also encountered the same problem as described in bug#696.
> (Actually it also happened to '.doc' and '.ppt' and '.ps' file types
> too.)
> 
> Could you please advise if you have any soluation for that problem
> so far?
> 
> Please advise.
> 
> Thanks,
> 
> Best Regards,
> Jin-Ling
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

-- 

Dan Milstein // [EMAIL PROTECTED]

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

Re: [PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x)

[Dan Milstein]

Benoit,

Thanks -- I actually just fixed this in the 3.2 branch.

-Dan

Benoit Derouet wrote:
> 
> Hi,
> 
> The load balancer worker fail to handle load balancing (with sticky
> sessions) if the application uses custom cookies.
> 
> In some circumstances, the load balancer worker can't retreive the server
> name from the JSessionID cookie and is not able to redirect to the good
> server.
> 
> The algorithm parse the cookie header to extract the server name from the
> JSessionID cookie. It find properly the end of the server name but fail to
> cut the chars after.
> So, it works fine if the cookie header contains only one cookie (or if
> JSessionID is the last cookie) but If they are custom cookie, the server
> name extracted will be: "servername;mycookieVal=myCookieValue .."
> 
> The bug is fixed around line 170.
> (line id_end=NULL; replaced by id_end[0] = '\0'; )
> 
> 'hope this will be integrated in future versions ! (as our customers need
> sticky load balancing...)
> 
> regards.
> 
> Benoit
-- 

Dan Milstein // [EMAIL PROTECTED]

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

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

[larryi]

larryi  01/01/12 10:04:24

  Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
PrefixMapper.java
  Log:
  Reimplement the last fix so the root context (i.e. "") doesn't have problems.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.2   +7 -4  
jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java
  
  Index: PrefixMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v
  retrieving revision 1.3.2.1
  retrieving revision 1.3.2.2
  diff -u -r1.3.2.1 -r1.3.2.2
  --- PrefixMapper.java 2001/01/04 21:28:33 1.3.2.1
  +++ PrefixMapper.java 2001/01/12 18:04:20 1.3.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.3.2.1 
2001/01/04 21:28:33 marcsaeg Exp $
  - * $Revision: 1.3.2.1 $
  - * $Date: 2001/01/04 21:28:33 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v 1.3.2.2 
2001/01/12 18:04:20 larryi Exp $
  + * $Revision: 1.3.2.2 $
  + * $Date: 2001/01/12 18:04:20 $
*
* 
*
  @@ -215,11 +215,14 @@
if( container!=null ) return container;
}

  - while (s.length() > 0) {
  + while (s.length() >= 0) {
//if(debug>8) context.log( "Prefix: " + s  );
container = myMap.prefixMappedServlets.get(s);

if (container == null) {
  + // if empty string didn't map, time to give up
  + if ( s.length() == 0 )
  +break;
s=URLUtil.removeLast( s );
}  else {
if( myMap.mapCacheEnabled ) {
  
  
  

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

RE: 3.2 cvs problems with ROOT context?

[Larry Isaacs]

The recent patch to PrefixMapper.java should fix this problem.
Without it you will not be able to access the root context.

Cheers,
Larry

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 12, 2001 11:25 AM
> To: 'tomcat-dev'
> Subject: 3.2 cvs problems with ROOT context?
> 
> 
> Hola a todos:
> 
> I dong a brief review of 3.2.2 from cvs this evening, only to give a
> look over the latest ( big ) changes and so on...
> 
> But after a cvs update a "build all" and double checked everything
> AFAIK, i can not get http://localhost:8080/ in my browser, i 
> can access
> examples context but it seems that i can not access ROOT 
> context  @:( ,
> so i'm really suprised and stucked, do a new check of everything , and
> nope!! nothings works in the ROOT context 
> 
> IMHO i'm forgetting something, or i can fire my dev system or 
> i'm mad (
> as usual )...
> 
> Being addicted to debuggers,i did a try, a simple look 
> inside, and whats
> my surprise  ROOT context is mounted !!! but in "" path and
> SimpleMapper1 is trying to map a path="/" . I recall that the
> correct behavior the path as "" not "/" but... i've decided to ask
> everybody, to test that nothing is bad on my side...
> 
> Everybody can access a freshly checkout of Tomcat 3.2.2 from cvs build
> them and access http://localhost:8080 without problems??? 
> 
> Saludos ,
> Ignacio J. Ortega
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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

Re: BugRat Report #690 has been filed.

[Dan Milstein]

There have been some pretty major bugs fixed in the mod_jk / ajp13 world.  The broken 
File Upload problem, which people repost as a bug pretty often, and a load-balancing 
bug, which also seems to cause a lot of pain.

Just to factor that into whatever else has been fixed...

-Dan

> Glenn (and others),
> 
> Have we accumulated enough bug fixes where it's worth creating a 3.2.2 release, or 
>are there more issues that should be
> dealt with first?
-- 

Dan Milstein // [EMAIL PROTECTED]

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

BugRat Report #753 has been filed.

[BugRat Mail System]

Bug report #753 has just been filed.

You can view the report at the following URL:

   

REPORT #753 Details.

Project: Servlet API
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: Tomcat 3.2.1
   JVM Release: 1.3
   Operating System: Linux / NT
   OS Release: 7.2 / 4.51
   Platform: Intel

Synopsis: 
req.getParameter(name) Ignores charset. always assumes ISO8859-1.

Description:
I have an application that allows the user to enter UNICODE 
characters on the WEB browser.
The web page is "rsp.setContentType("text/html; charset=UTF8");"
which enables UNICODE support on both IE and NetScape.
When I use "req.getParameter(name)" to get the user input, 
it is not decoded correctly.  Each byte of the UTF8 stream 
is placed in a seperate character. (as if a deprecated String 
constructor "String(bytearray,0,0,length)" is being used to 
convert the bytes into a String).  
This behavior is WRONG!
Java 2 classes should not use deprecated methods!
Also, it destroys important information needed to convert 
the input byte stream into it's correct UNICODE String 
representation.
Please tell me who supports javax.servlet.
Tim Tye -- [EMAIL PROTECTED]

Title: 
BugRat Report #
753





BugRat Report #
753




Project:
Servlet API


Release:
Tomcat 3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 12:08:22 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

req.getParameter(name) Ignores charset. always assumes ISO8859-1.


 Environment: (jvm, os, osrel, platform)

1.3, Linux / NT, 7.2 / 4.51, Intel



Additional Environment Description:


public String(byte[] ascii,
  int hibyte,
  int offset,
  int count)

  Deprecated. This method does not properly convert bytes into characters. As of JDK 1.1, the preferred way to do this is via the String
  constructors that take a character-encoding name or that use the platform's default encoding. 




Report Description:

I have an application that allows the user to enter UNICODE 
characters on the WEB browser.
The web page is "rsp.setContentType("text/html; charset=UTF8");"
which enables UNICODE support on both IE and NetScape.
When I use "req.getParameter(name)" to get the user input, 
it is not decoded correctly.  Each byte of the UTF8 stream 
is placed in a seperate character. (as if a deprecated String 
constructor "String(bytearray,0,0,length)" is being used to 
convert the bytes into a String).  
This behavior is WRONG!
Java 2 classes should not use deprecated methods!
Also, it destroys important information needed to convert 
the input byte stream into it's correct UNICODE String 
representation.
Please tell me who supports javax.servlet.
Tim Tye -- [EMAIL PROTECTED]



Workaround:

null



View this report online...






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

BugRat Report #753 - req.getParameter(name) Ignores charset. always assumes ISO8859-1.

[BugRat Mail System]

Report #753 Details

Project: Servlet API
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: Tomcat 3.2.1
   JVM Release: 1.3
   Operating System: Linux / NT
   OS Release: 7.2 / 4.51
   Platform: Intel

Synopsis: 
req.getParameter(name) Ignores charset. always assumes ISO8859-1.

Description:
I have an application that allows the user to enter UNICODE 
characters on the WEB browser.
The web page is "rsp.setContentType("text/html; charset=UTF8");"
which enables UNICODE support on both IE and NetScape.
When I use "req.getParameter(name)" to get the user input, 
it is not decoded correctly.  Each byte of the UTF8 stream 
is placed in a seperate character. (as if a deprecated String 
constructor "String(bytearray,0,0,length)" is being used to 
convert the bytes into a String).  
This behavior is WRONG!
Java 2 classes should not use deprecated methods!
Also, it destroys important information needed to convert 
the input byte stream into it's correct UNICODE String 
representation.
Please tell me who supports javax.servlet.
Tim Tye -- [EMAIL PROTECTED]

Title: 
BugRat Report #
753





BugRat Report #
753




Project:
Servlet API


Release:
Tomcat 3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 12:08:22 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

req.getParameter(name) Ignores charset. always assumes ISO8859-1.


 Environment: (jvm, os, osrel, platform)

1.3, Linux / NT, 7.2 / 4.51, Intel



Additional Environment Description:


public String(byte[] ascii,
  int hibyte,
  int offset,
  int count)

  Deprecated. This method does not properly convert bytes into characters. As of JDK 1.1, the preferred way to do this is via the String




Report Description:

I have an application that allows the user to enter UNICODE 
characters on the WEB browser.
The web page is "rsp.setContentType("text/html; charset=UTF8");"
which enables UNICODE support on both IE and NetScape.
When I use "req.getParameter(name)" to get the user input, 
it is not decoded correctly.  Each byte of the UTF8 stream 
is placed in a seperate character. (as if a deprecated String 
constructor "String(bytearray,0,0,length)" is being used to 
convert the bytes into a String).  
This behavior is WRONG!
Java 2 classes should not use deprecated methods!
Also, it destroys important information needed to convert 
the input byte stream into it's correct UNICODE String 
representation.
Please tell me who supports javax.servlet.
Tim Tye -- [EMAIL PROTECTED]



Workaround:





View this Report online...






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

Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Hans Bergsten]

"Ignacio J. Ortega" wrote:
> 
> Hola Hans , Marc:
> 
> You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks
> ago , that seems to resolve this problem, were reports #619 #653 #513 ,
> and i think this is resolved in CVS, please review it and i will revise
> BugRat to close related bugs , if you agree it's already resolved..

I was using the 3.2.1 version, not the latest CVS version (duh!).
Will test again with the CVS version.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

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

Re: possible problem with CLIENT-CERT login and security constraint on TOMCAT 4.0

[Shahed Ali]

Hi,
 
This is slightly off the original post.
 
But I want to do auth based on client 
certificates.
 
However, I am using Tomcat 3.2.1 with Apache and Virtual 
Hosts.
Also I have the  tag in my 
server.xml.
 
Now I remember reading people having problems passing a client 
cert from 
apache to tomcat or something to that effect.
 
Are there any examples out there that talk about how to set up 
client cert auth
with Apache + Tomcat + acquiring a client cert + Becoming an 
issure of client certs.
 
Thanks
Shahed.

[PATCH] (Was: 3.2 cvs problems with ROOT context?)

[Dimitris Dinodimos]

Hello to all of you,This bug was introduced by the latest fix, that was made
to correct the problem in tomcat when it didn't have a ROOT context.This
patch gives getLongestPrefixMatch() a chance to return the ROOT
context.Cheers,Dimitris Dinodimos



Index: PrefixMapper.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMapper.java,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 PrefixMapper.java
--- PrefixMapper.java   2001/01/04 21:28:33 1.3.2.1
+++ PrefixMapper.java   2001/01/12 17:25:20
@@ -214,12 +214,14 @@
container=myMap.mapCache.get(path);
if( container!=null ) return container;
}
-   
-   while (s.length() > 0) {
+
+   while (s.length() >= 0) {
//if(debug>8) context.log( "Prefix: " + s  );
container = myMap.prefixMappedServlets.get(s);

if (container == null) {
+   if (s.length() == 0)
+   return null;
s=URLUtil.removeLast( s );
}  else {
if( myMap.mapCacheEnabled ) {
@@ -228,7 +230,8 @@
}
return container;
}
-   }
+   } 
+
return container;
 }
 



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

Re: possible problem with CLIENT-CERT login and security constraint on TOMCAT 4.0

[Craig R. McClanahan]

Shahed Ali wrote:
 Hi, This
is slightly off the original post. But I want
to do auth based on client certificates. However,
I am using Tomcat 3.2.1 with Apache and Virtual Hosts.Also
I have the  tag in my server.xml. Now
I remember reading people having problems passing a client cert fromapache
to tomcat or something to that effect. Are there
any examples out there that talk about how to set up client cert authwith
Apache + Tomcat + acquiring a client cert + Becoming an issure of client
certs. ThanksShahed.

Tomcat 3.2.1 does not support *container-managed* security using
the CLIENT-CERT method -- you need Tomcat 4.0 for that -- although you
could implement your own security processing based on the contents of the
client certificates.  The certificate chain is supposed to be exposed
to you (I don't recall the details of whether this works right for all
web connectors or not) as a request attribute named "java.security.cert.X509Certificate",
which will be an array of java.security.cert.X509Certificate objects.
Craig McClanahan
 

Re: NullPointerException from HttpSessionFacade.invalidate()

[cmanolache]

> There lies the catch and the source of problem in my understanding.
>  In different requests relating to
> the same session, I may get referance to HttpSessionFacade instances which
> are different, but I expect them to be same (although not guarantied by
> specs but I thought it was a tacit agreement between container and servlet
> developer). What I suggest is that tomcat should recycle the
> HttpSessionFacade instance only when the HttpSession instance is
> recycled.This might be more inefficient as it will result in N instances on

You are right, I know what's the problem. It's not hard to fix, but this
week I have no time ( and probably neither next week ), but this bug has
been on my list.

In fact, there is a larger problem here - with very serious security
and performance implications.

To get decent performance you need to recycle ( the cost of allocating
few hundred objects per request is huge - it means the server will
saturate on even small loads). Most servlet containers do recycle - the
problem is common to all of them.

Unfortunately recycling opens a security hole: a (bad) servlet may keep
reference to the HttpServletRequest, HttpServletResponse and HttpSession
objects - and later access the them. That means it'll be able to access
data in a HttpServletRequest that is in use by another servlet, in another
application.

We have most of the elements to fix this hole - and with a decent ( small)
perfomance hit. We need to make sure that a servlet receive only facades
that are local to it's context. That's easy to do by either maintaining a
per/context pool of facades or just doing nothing ( since the facade is
very "light"). 

There is nothing that can be done with the original Request (and  I don't
know any possible fix for this problem in containers that don't use
facades ) - you know the context after you process the request, and then
you've already allocated the request. It may be possible to process the
request line before allocating the request - but that's ugly. Anyway,
that's not a problem in 3.x.


Regarding HttpSessionFacade - you are right, ServerSession should have a
get/setFacade and all getSession() calls should return the same
facade. 1/2 of that is done in 3.3, I just need to do one more change -
it's easy to duplicate this in 3.2 also. Of course, when the session is
invalidated the facade must be either saved in a context-specific pool or
just let it die.

--
Costin


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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Hans Bergsten]

Gokul Singh wrote:
> [...]
> > The reason you see a behavior difference is that Tomcat 3.1 did not
> recycle session object instances, but Tomcat 3.2 does.
> 
> There lies the catch and the source of problem in my understanding.
>  In different requests relating to
> the same session, I may get referance to HttpSessionFacade instances which
> are different, but I expect them to be same (although not guarantied by
> specs but I thought it was a tacit agreement between container and servlet
> developer). 
> [...]

The spec may not be explicit enough about this, but the session object
you get back from the getSession() object is a container-managed object
that the application is not supposed/allowed to keep long-lived
references 
to. It's the same as with all other container-objects made available to
the
application; request, response, JSP tag handlers, etc.

I'm not sure why you're keeping references to the session objects in
you're application, but if you describe what you're trying to do I'm
sure I can give you a hint about another way to accomplish the same
thing without the problems you have with your current solution.
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

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

Interceptor architecture

[Aprameya N. Paduthonse]

Hi,

Could someone please direct me to any useful documentation that explains the
architecture for building interceptors for Tomcat? Any resource that
explains how to use the Tomcat open APIs would be helpful.

Thanks in advance,

Aprameya Paduthonse



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

BugRat Report #754 has been filed.

[BugRat Mail System]

Bug report #754 has just been filed.

You can view the report at the following URL:

   

REPORT #754 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: Tomcat 4.0-b1
   JVM Release: jdk1.3
   Operating System: Linux
   OS Release: Kernel 2.2.13-0.7 on an i686 
   Platform: Linux

Synopsis: 
Tomcat sending the real port which Apache is running on.

Description:
With Apache-1.3.14/Tomcat-4.0-b1 running on a linux box with jdk1.3.
Apache configured to use port base virtual hosting.
A Cisco Local Directory used to translate http://www.my.com/
to 10.10.10.100:8000 or http://www.my1.com/ to 10.10.10.100:8001.
When you access a jsp or servlet on tomcat, tomcat send a Location 
header to the client with the real Apache port.
Example.
The client access http://www.my.com/examples/jsp Tomcat returns
http://www.my.com:8000/exmaples/jsp.

Title: 
BugRat Report #
754





BugRat Report #
754




Project:
Tomcat


Release:
Tomcat 4.0-b1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Daniel Williams ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 01:05:50 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Tomcat sending the real port which Apache is running on.


 Environment: (jvm, os, osrel, platform)

jdk1.3, Linux, Kernel 2.2.13-0.7 on an i686 , Linux



Additional Environment Description:





Report Description:

With Apache-1.3.14/Tomcat-4.0-b1 running on a linux box with jdk1.3.
Apache configured to use port base virtual hosting.
A Cisco Local Directory used to translate http://www.my.com/
to 10.10.10.100:8000 or http://www.my1.com/ to 10.10.10.100:8001.
When you access a jsp or servlet on tomcat, tomcat send a Location 
header to the client with the real Apache port.
Example.
The client access http://www.my.com/examples/jsp Tomcat returns
http://www.my.com:8000/exmaples/jsp.



View this report online...






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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Hans Bergsten]

[EMAIL PROTECTED] wrote:
> 
> > There lies the catch and the source of problem in my understanding.
> >  In different requests relating to
> > the same session, I may get referance to HttpSessionFacade instances which
> > are different, but I expect them to be same (although not guarantied by
> > specs but I thought it was a tacit agreement between container and servlet
> > developer). What I suggest is that tomcat should recycle the
> > HttpSessionFacade instance only when the HttpSession instance is
> > recycled.This might be more inefficient as it will result in N instances on
> 
> You are right, I know what's the problem. It's not hard to fix, but this
> week I have no time ( and probably neither next week ), but this bug has
> been on my list.
> 
> In fact, there is a larger problem here - with very serious security
> and performance implications.
> 
> To get decent performance you need to recycle ( the cost of allocating
> few hundred objects per request is huge - it means the server will
> saturate on even small loads). Most servlet containers do recycle - the
> problem is common to all of them.
> 
> Unfortunately recycling opens a security hole: a (bad) servlet may keep
> reference to the HttpServletRequest, HttpServletResponse and HttpSession
> objects - and later access the them. That means it'll be able to access
> data in a HttpServletRequest that is in use by another servlet, in another
> application.
> 
> We have most of the elements to fix this hole - and with a decent ( small)
> perfomance hit. We need to make sure that a servlet receive only facades
> that are local to it's context. That's easy to do by either maintaining a
> per/context pool of facades or just doing nothing ( since the facade is
> very "light").
> 
> There is nothing that can be done with the original Request (and  I don't
> know any possible fix for this problem in containers that don't use
> facades ) - you know the context after you process the request, and then
> you've already allocated the request. It may be possible to process the
> request line before allocating the request - but that's ugly. Anyway,
> that's not a problem in 3.x.
> 
> Regarding HttpSessionFacade - you are right, ServerSession should have a
> get/setFacade and all getSession() calls should return the same
> facade. 1/2 of that is done in 3.3, I just need to do one more change -
> it's easy to duplicate this in 3.2 also. Of course, when the session is
> invalidated the facade must be either saved in a context-specific pool or
> just let it die.

Another solution, IMHO, is to make sure all these objects are only used
within the thread they where allocated for. Briefly, add a package scope
setThreadID() method to the classes that implement pooled objects like 
this and let the container call this method with the current thread ID 
before it delivers the object to the application. Then compare the
current 
thread ID with the assigned thread ID in all methods the application can 
call. If they are not the same, throw IllegalStateException.

Again, the spec is not clear on this. Maybe it needs to be clarified
with regards to how the container-objects can be used by the application
(some attempts to clarify this is being added to the JSP 1.2 spec with
regards to tag handler classes).

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

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

BugRat Report #755 has been filed.

[BugRat Mail System]

Bug report #755 has just been filed.

You can view the report at the following URL:

   

REPORT #755 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.1
   JVM Release: 1.3
   Operating System: Linux
   OS Release: 2.2.16
   Platform: x86

Synopsis: 
Cannot use custom tags, illegalAccessError

Description:
I wrote and compiled a class that extends TagSupport, created the TLD file, updated my 
application descriptor, but when I start Tomcat and try to access a page that uses the 
tag, I get an illegalAccessError, "try to access com.sun.xml.tree.ParentNode from  
class org.apache.jasper.compiler.TagLibraryInfoImpl".  I have a servlet that does the 
same thing, uses the same classes, and I have no problem.

Title: 
BugRat Report #
755





BugRat Report #
755




Project:
Tomcat


Release:
3.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
Thomas Gideon ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 01:31:25 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Cannot use custom tags, illegalAccessError


 Environment: (jvm, os, osrel, platform)

1.3, Linux, 2.2.16, x86



Additional Environment Description:

I am also using Xalan 1.2, with the xalan.jar and xerces.jar files in 



Report Description:

I wrote and compiled a class that extends TagSupport, created the TLD file, updated my application descriptor, but when I start Tomcat and try to access a page that uses the tag, I get an illegalAccessError, "try to access com.sun.xml.tree.ParentNode from  class org.apache.jasper.compiler.TagLibraryInfoImpl".  I have a servlet that does the same thing, uses the same classes, and I have no problem.



How To Reproduce:

null



View this report online...






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

Re: An alternative to JSP

[Jon Stevens]

on 1/11/01 8:30 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:

> Yeah, but thats an impl detail. You could easily modify it to load the HTML
> on the fly, so that the HTML could be modified separately. The main thing I
> like here is that you actually start with a "proper" HTML file, without a
> proliferation of proprietary "Cold Fusion" style tags. That way HTML codes
> can actually code real HTML, rather than some weird proprietary HTML
> sublanguage. Allaires "content management" thingo Spectra defines 400 +
> tags - how is your average HTML coder gonna deal with that? Course, it has
> other problems but hey, that was my original thesis ... unfortunately the
> real world is a complex place :-).

Ok, so what I hear you saying is that you are comparing XMLC against
something we all already know is not a good way of doing things? :-)

> Weren't you implying that under complex (read real world) scenarios, the
> tradtional Webmacro "push" style way of doing things breaks down? Thats all
> I was saying. Note your pull model Webmacro starts to sound like JSP to
> me... interpreted HTML...

Quite the opposite. Let me correct you and state that I don't use/recommend
WM, I use/recommend Velocity these days as Velocity is a much better
re-implementation of the original WM *concepts*.

Let me also state that at this point in time, I see Velocity+Turbine as
being one of the best solutions out there.

WM/Velocity is *parsed* HTML, however, that is where the similarities to JSP
stop. For example, people who code JSP tend to do things like this (taken
from a recent CVS check-in by a guy from IBM to the Jetspeed project):

   <%
   keys = rundata.getParameters().keys();
   while ( keys.hasMoreElements() )
   {
   key   = (String) keys.nextElement();
   value = rundata.getParameters().getString(key);
   out.println(""+key+" = " + value +
"");
   }
   %>

The issue with that is that you are no embedding HTML code into your Java
code. How many designers without any programming skills (but have HTML
skills) do you know can edit something like that? What if the person wanted
to embed a bgcolor= attributed into the  tag? Then they would suddenly
also have to learn how to escape double quotes as well. Not very
maintainable IMHO.

With WM/Velocity, you would write the above something like this:

#foreach ( $key in $data.Parameters.Keys )

 $key
  = $data.Parameters.getString($key)

#end

Velocity has a well defined simple *template* syntax that prevents you from
making the mistakes that JSP doesn't prevent you from. In other words, yes,
you could have done the above JSP snippet correctly, however, my issue with
JSP is that it almost encourages you to do it incorrectly.

Also, the other advantage of the above Velocity example is that if you load
it into a browser without running it through the parser (ie: just load the
static template), it shows up ugly, but you can easily see the logic of what
you are trying to accomplish. If you loaded the JSP example the same
way...all you would see is...nothing.

In conclusion, let me restate that I feel that Turbine+Velocity is the right
way to implement Pull functionality for a simple to complex web application.

thanks,

-jon


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

Re: Interceptor architecture

[cmanolache]

> Hi,
> 
> Could someone please direct me to any useful documentation that explains the
> architecture for building interceptors for Tomcat? Any resource that
> explains how to use the Tomcat open APIs would be helpful.

Read the BaseInterceptor comments - all you have to do is extend it and
implement the hooks you need. 

Some time ago I started working on documentation, but it still need more
work. For general concepts you can read Apache documentations ( the hooks
in 2.0, etc ) - the design is almost the same.

Costin


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

RE: An alternative to JSP

[Tomas Rokicki]

With the solution we're deploying in-house here, your dynamic row
example is just

%tr rundata%%key% = %value%

which is editable in WYSIWYG HTML editors, contains no Java code,
and so on . . . the magic %tr ...% tells it to iterate on table rows.

Oh, but of course it's YATL so I'll shut up now.  (It compiles down
to JSPs.)

-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 12, 2001 11:39 AM
To: [EMAIL PROTECTED]
Subject: Re: An alternative to JSP


on 1/11/01 8:30 PM, "Geoff Soutter" <[EMAIL PROTECTED]> wrote:

> Yeah, but thats an impl detail. You could easily modify it to load the
HTML
> on the fly, so that the HTML could be modified separately. The main thing
I
> like here is that you actually start with a "proper" HTML file, without a
> proliferation of proprietary "Cold Fusion" style tags. That way HTML codes
> can actually code real HTML, rather than some weird proprietary HTML
> sublanguage. Allaires "content management" thingo Spectra defines 400 +
> tags - how is your average HTML coder gonna deal with that? Course, it has
> other problems but hey, that was my original thesis ... unfortunately the
> real world is a complex place :-).

Ok, so what I hear you saying is that you are comparing XMLC against
something we all already know is not a good way of doing things? :-)

> Weren't you implying that under complex (read real world) scenarios, the
> tradtional Webmacro "push" style way of doing things breaks down? Thats
all
> I was saying. Note your pull model Webmacro starts to sound like JSP to
> me... interpreted HTML...

Quite the opposite. Let me correct you and state that I don't use/recommend
WM, I use/recommend Velocity these days as Velocity is a much better
re-implementation of the original WM *concepts*.

Let me also state that at this point in time, I see Velocity+Turbine as
being one of the best solutions out there.

WM/Velocity is *parsed* HTML, however, that is where the similarities to JSP
stop. For example, people who code JSP tend to do things like this (taken
from a recent CVS check-in by a guy from IBM to the Jetspeed project):

   <%
   keys = rundata.getParameters().keys();
   while ( keys.hasMoreElements() )
   {
   key   = (String) keys.nextElement();
   value = rundata.getParameters().getString(key);
   out.println(""+key+" = " + value +
"");
   }
   %>

The issue with that is that you are no embedding HTML code into your Java
code. How many designers without any programming skills (but have HTML
skills) do you know can edit something like that? What if the person wanted
to embed a bgcolor= attributed into the  tag? Then they would suddenly
also have to learn how to escape double quotes as well. Not very
maintainable IMHO.

With WM/Velocity, you would write the above something like this:

#foreach ( $key in $data.Parameters.Keys )

 $key
  = $data.Parameters.getString($key)

#end

Velocity has a well defined simple *template* syntax that prevents you from
making the mistakes that JSP doesn't prevent you from. In other words, yes,
you could have done the above JSP snippet correctly, however, my issue with
JSP is that it almost encourages you to do it incorrectly.

Also, the other advantage of the above Velocity example is that if you load
it into a browser without running it through the parser (ie: just load the
static template), it shows up ugly, but you can easily see the logic of what
you are trying to accomplish. If you loaded the JSP example the same
way...all you would see is...nothing.

In conclusion, let me restate that I feel that Turbine+Velocity is the right
way to implement Pull functionality for a simple to complex web application.

thanks,

-jon


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



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

Re: An alternative to JSP

[Jon Stevens]

on 1/12/01 11:49 AM, "Tomas Rokicki" <[EMAIL PROTECTED]> wrote:

> With the solution we're deploying in-house here, your dynamic row
> example is just
> 
> %tr rundata%%key% = %value%
> 
> which is editable in WYSIWYG HTML editors, contains no Java code,
> and so on . . . the magic %tr ...% tells it to iterate on table rows.
> 
> Oh, but of course it's YATL so I'll shut up now.  (It compiles down
> to JSPs.)

Exactly. JSP alone didn't solve your problem. You had to do YATL in order to
get it to do what you want. That just seems odd to me.

-jon


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

BugRat Report #756 has been filed.

[BugRat Mail System]

Bug report #756 has just been filed.

You can view the report at the following URL:

   

REPORT #756 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.2.1_04
   Operating System: Solaris
   OS Release: ???
   Platform: SPARC

Synopsis: 
User Principal incorrectly Maintained - Fix

Description:
request.getUserPrincipal().getName() doesn't return the correct user all of the time.

Title: 
BugRat Report #
756





BugRat Report #
756




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
David Winterfeldt ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 01:53:23 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

User Principal incorrectly Maintained - Fix


 Environment: (jvm, os, osrel, platform)

1.2.1_04, Solaris, ???, SPARC



Additional Environment Description:





Report Description:

request.getUserPrincipal().getName() doesn't return the correct user all of the time.



Workaround:

null



View this report online...






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

BugRat Report #757 has been filed.

[BugRat Mail System]

Bug report #757 has just been filed.

You can view the report at the following URL:

   

REPORT #757 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.2.1_04
   Operating System: Solaris
   OS Release: ???
   Platform: SPARC

Synopsis: 
User Principal incorrectly Maintained - Fix

Description:
Sorry, posting one more time.  I don't see the workaround I posted before being 
displayed so I've moved it to this text box.

request.getUserPrincipal().getName() doesn't return the correct user all of the time.

FIX
--
In org.apache.tomcat.core.RequestImpl, 'principal=null' needs to be added to 
initRequest().  Then it works fine.

Since setUserPrincipal() isn't being called by the authenicating realm, but 
setRemoteUser() is being called.  The old principal is never getting reset when 
authentication occurs.

Title: 
BugRat Report #
757





BugRat Report #
757




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
David Winterfeldt ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 01:55:45 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

User Principal incorrectly Maintained - Fix


 Environment: (jvm, os, osrel, platform)

1.2.1_04, Solaris, ???, SPARC



Additional Environment Description:





Report Description:

Sorry, posting one more time.  I don't see the workaround I posted before being displayed so I've moved it to this text box.

request.getUserPrincipal().getName() doesn't return the correct user all of the time.

FIX
--
In org.apache.tomcat.core.RequestImpl, 'principal=null' needs to be added to initRequest().  Then it works fine.

Since setUserPrincipal() isn't being called by the authenicating realm, but setRemoteUser() is being called.  The old principal is never getting reset when authentication occurs.



View this report online...






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

IM LOST, ERROR 500????

[Mary McCarthy]

Hi Im writing my first little program that will welcome a user once she enters and submits her details into a web page.There is no problem Writing the JSP files but I cannot start a new .java file in Jbuilder, so I write it in Homesite, save it as .java and attempt to compile it to .class in Jbuilder. 
Im having difficulty converting the .javafile to .class 

I have tried compiling the .java file to a .class in JBuilder, but I keep getting the following warning: 

"Warning #908: check sourcepath; source c:\jakarta-tomcat\webapps\mary\Web-inf\Classes\namehandler.java cannot be found on source pathby appending \mary\namehandler.java to each sourcepath entry." 
(mary is the name of the package) 


When I try to view the program in my browser at http:// localhost etc etc I get the following error 
 



  

Error: 500
Location: /Mary/hellouser.jsp
Internal Servlet Error:org.apache.jasper.JasperException: Bad file argument to include     at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventListener.java, Compiled Code)    at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener.java:116)    at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java, Compiled Code)    at org.apache.jasper.compiler.Parser.parse(Parser.java, Compiled Code)    at org.apache.jasper.compiler.Parser.parse(Parser.java:1038)    at org.apache.jasper.compiler.Parser.parse(Parser.java:1034)    at org.apache.jasper.compiler.Compiler.compile(Compiler.java, Compiled Code)    at org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java:413)    at org.apache.jasper.runtime.JspServlet$JspServletWrapper.loadIfNecessary(JspServlet.java:149)    at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet.java:161)    at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:261)    at org.apache.jasper.runtime.JspServlet.service(JspServlet.java, Compiled Code)    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)    at org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java, Compiled Code)    at org.apache.tomcat.core.ContextManager.service(ContextManager.java:559)    at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:160)    at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338)    at java.lang.Thread.run(Thread.java:479)PLEASE PLEASE PLEASE, anyone with help?Get your FREE download of MSN Explorer at http://explorer.msn.com

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

RE: An alternative to JSP

[Tomas Rokicki]

I don't look at it as odd at all.  JSP and servlets in general
are *very low level* abstractions.  They are incredibly useful,
but they are at such a low level that it's very difficult to
build a complex application.  It's like coding in machine
language.  It's not that difficult to add a layer or two to
raise the level of abstraction.

The good thing about JSP and servlets is they provide a stable,
portable, and solid base with good engineering.  They are
complex enough that getting them implemented correctly is
nontrivial (hence all the work on tomcat etc.) but yet generic
enough that different abstractions can easily be constructed
on top of them.  This is precisely what I want, a
good solid base engineered well on which I can build what
we need.

All the experimentation with the various macro languages and
the like is all good, and we'll all learn from them and
eventually it will all converge [or fail to do so]; I don't
see that it has happened yet, and each solution has its pros
and cons, none of which were acceptable when we started our
project, which is why I've got a stupid lightweight YATL that
we use in-house that solves our problems.

I just thought I'd toss out an example of how we solved the
`no code in JSP' problem.

-tom
-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 12, 2001 11:54 AM
To: [EMAIL PROTECTED]
Subject: Re: An alternative to JSP


on 1/12/01 11:49 AM, "Tomas Rokicki" <[EMAIL PROTECTED]> wrote:

> With the solution we're deploying in-house here, your dynamic row
> example is just
>
> %tr rundata%%key% = %value%
>
> which is editable in WYSIWYG HTML editors, contains no Java code,
> and so on . . . the magic %tr ...% tells it to iterate on table rows.
>
> Oh, but of course it's YATL so I'll shut up now.  (It compiles down
> to JSPs.)

Exactly. JSP alone didn't solve your problem. You had to do YATL in order to
get it to do what you want. That just seems odd to me.

-jon


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



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

BugRat Report #758 has been filed.

[BugRat Mail System]

Bug report #758 has just been filed.

You can view the report at the following URL:

   

REPORT #758 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: 1.3
   Operating System: Win2k
   OS Release: SP0
   Platform: Apache 1.3.14

Synopsis: 
HTTP POST incorrect behavior

Description:
When I open a telnet session from a Linux machine to my Win2k machine running Tomcat, 
it allows me to type the following:

POST /jgrady/servlet/PurchaseOrderServlet HTTP/1.0
content-length: 8

And then as soon as I hit  after the '8', it tries to process my request.  
AFAIK, this is incorrect behavior for HTTP POSTing.  I think it should allow me to 
type one blank line, some content, and then process my request.

Integrating Apache with Tomcat and trying the same test only makes Apache return an 
error 500 'Internal Server Error'.

[EMAIL PROTECTED]

Title: 
BugRat Report #
758





BugRat Report #
758




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Jan 12 2001, 02:05:14 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

HTTP POST incorrect behavior


 Environment: (jvm, os, osrel, platform)

1.3, Win2k, SP0, Apache 1.3.14



Additional Environment Description:





Report Description:

When I open a telnet session from a Linux machine to my Win2k machine running Tomcat, it allows me to type the following:

POST /jgrady/servlet/PurchaseOrderServlet HTTP/1.0
content-length: 8

And then as soon as I hit  after the '8', it tries to process my request.  AFAIK, this is incorrect behavior for HTTP POSTing.  I think it should allow me to type one blank line, some content, and then process my request.

Integrating Apache with Tomcat and trying the same test only makes Apache return an error 500 'Internal Server Error'.

[EMAIL PROTECTED]



How To Reproduce:

null



View this report online...






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

Re: An alternative to JSP

[Craig R. McClanahan]

Jon Stevens wrote:

> on 1/12/01 11:49 AM, "Tomas Rokicki" <[EMAIL PROTECTED]> wrote:
>
> > With the solution we're deploying in-house here, your dynamic row
> > example is just
> >
> > %tr rundata%%key% = %value%
> >
> > which is editable in WYSIWYG HTML editors, contains no Java code,
> > and so on . . . the magic %tr ...% tells it to iterate on table rows.
> >
> > Oh, but of course it's YATL so I'll shut up now.  (It compiles down
> > to JSPs.)
>
> Exactly. JSP alone didn't solve your problem. You had to do YATL in order to
> get it to do what you want. That just seems odd to me.
>

So did you Jon ... it's called Velocity :-)

JSP, as Tomas points out, is a low level toolkit, on top of which you can build
higher level constructs (with custom tags).  For example, the Struts-based
equivalent of your example is (where "parameters" is a bean in some scope that
is a Collection, a Map, or an array):








One can edit this stuff by hand if you want, but we're also starting to see IDE
tools that understand this stuff -- complete with popping up dialong boxes to
populate the appropriate attributes -- in the same way the IDE tools for
building JavaBeans took much of the drudgery out of that process.

But, of course, Jon and I go *way* back on this particular topic :-).

>
> -jon
>

Craig




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

Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Hans Bergsten]

Hans Bergsten wrote:
> 
> "Ignacio J. Ortega" wrote:
> >
> > Hola Hans , Marc:
> >
> > You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks
> > ago , that seems to resolve this problem, were reports #619 #653 #513 ,
> > and i think this is resolved in CVS, please review it and i will revise
> > BugRat to close related bugs , if you agree it's already resolved..
> 
> I was using the 3.2.1 version, not the latest CVS version (duh!).
> Will test again with the CVS version.

Okay, I have tested with the latest tomcat_32 version from CVS
now and it works as it should. So the patch you applied solved
the problem. Thanks for telling me before I spent time trying to 
solve this again ;-)

Great, then I don't know of any serious issues that should hold up
a 3.2.2 release.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

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

RE: An alternative to JSP

[Taglang, Guillaume]

Hi,

Following the discussion we have decided to use an approach using the filter
features of the new servlet specifications. A application foo will follow
this steps:

0. some filtering is done for session stuff, security, etc.
1. the request is going to a controller servlet which is doing whatever it
should do (using beans for making db connection and computing and so on ...)
2. the request is including JSP which are ouputing an XML containing only
the logic data with some custom tags(a.xml)
3. a first filter will get the text content (probably also with a JSP and a
db connection behind) and include it in the XML document (b.xml)
4. a second filter transform the XML in HTML with XSL
5. a last filter can handle inclusion of static html files (like other part
of the web site)
Our web designer will receive some sample XML output files (of type a.xml)
and write then the XSL stuff, and the XML document b which is containig the
different texts, image references, etc.

I think for us it's a proper enough approach you have the whole JAVA code in
the servlets, filters, and tags. The JSP files look very clean containing
only a few custom tags. We are acheiving this way agood separation of the
logic, the content and the style of a web application.

Of course it take time at the beginning, but later on it's really easy to
add a wap version of a web site or to change the look and fell without
involving a single JAVA developer or to correct the java part if the xml
output is well defined.

Guillaume

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[cmanolache]

> Another solution, IMHO, is to make sure all these objects are only used
> within the thread they where allocated for. Briefly, add a package scope
> setThreadID() method to the classes that implement pooled objects like 
> this and let the container call this method with the current thread ID 
> before it delivers the object to the application. Then compare the
> current 
> thread ID with the assigned thread ID in all methods the application can 
> call. If they are not the same, throw IllegalStateException.

Well, that's a great idea - but it means adding a native method ( 
currentThread ) to absolutely all calls to all classes in the servlet API.
I did a test some time ago ( in another context ) - it's not a huge hit,
but it is visible.

Of course, the alternative ( either a sync() block if a pool is used or
garbage collection if the facade is not recycled ) may be as expensive,
but I was hoping that it can be done only for "untrusted" apps.
( on the other side, it's also possible to do 
if( untrusted && Thread.currentThread() != myThread ) ... ) )

I'll try both and see what happens. 

> Again, the spec is not clear on this. Maybe it needs to be clarified
> with regards to how the container-objects can be used by the application
> (some attempts to clarify this is being added to the JSP 1.2 spec with
> regards to tag handler classes).

One thing is clear - the current implementation ( at least 3.x ) doesn't
do any synchronization on request/response calls - if a servlet is using
more than one thread it's up to the servlet author to synchronize.
( most calls do not need any synchronization anyway, but it hasn't been
tested or verified ).

It would be nice to know that servlets are not allowed to create or use
threads ( and I don't think too many do that anyway ).

Thanks Hans.

Costin


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

Re: An alternative to JSP

[Jon Stevens]

on 1/12/01 12:31 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> So did you Jon ... it's called Velocity :-)

Exactly. It would have been nice if JSP was done right from the start
instead of having an original goal of attempting to provide a solution to
strictly compete with ASP.

> JSP, as Tomas points out, is a low level toolkit, on top of which you can
> build
> higher level constructs (with custom tags).  For example, the Struts-based
> equivalent of your example is (where "parameters" is a bean in some scope that
> is a Collection, a Map, or an array):
> 
> 
> 
> 
> 
> 
> 

I will restate the point of my earlier email...

Jon said:
> In other words, yes, you could have done the above JSP snippet correctly,
> however, my issue with JSP is that it almost encourages you to do it
> incorrectly.

...

> One can edit this stuff by hand if you want, but we're also starting to see
> IDE
> tools that understand this stuff -- complete with popping up dialong boxes to
> populate the appropriate attributes -- in the same way the IDE tools for
> building JavaBeans took much of the drudgery out of that process.

Right, Dreamweaver's recent additions sound very cool and a much needed
advancement for helping with JSP, however, it isn't real feasible as a
requirement for working on OSS projects since it is commercial (expensive!)
software. :-(

> But, of course, Jon and I go *way* back on this particular topic :-).

:-)

-jon


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

un subscribe me...................

[PAPIREDDY Poreddy]

 

  -Original Message-From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]Sent: Friday, January 12, 2001 
  9:20 PMTo: [EMAIL PROTECTED]Subject: 
  possible problem with CLIENT-CERT login and security constraint on TOMCAT 
  4.0Hi, 
  I try to configure TOMCAT server to 
  authenticate client with certificate on HTTPS protocol. My connector is configure to accept request on 8443 
  port like this :     
                 
   port="8443" minProcessors="5" maxProcessors="75"               
   acceptCount="10" debug="0" scheme="https" secure="true"> 
                       
   clientAuth="true" protocol="TLS" keystorePass="password1"/> 
       
  My tomcat-user.xml file is configured 
  with a new entry that match the getSubjectDN().getName() of client certificat 
  used :  
           
      I 
  also uncomment the security constraint on my web.xml file like this 
     
      
     
      The Entire Web 
  Application       /* 
      
              tomcat 
       
     
     
      
  CLIENT-CERT     Tomcat Supported 
  Realm   
     
       
       
    An example role defined in "conf/tomcat-users.xml"          
  tomcat    My problem is when I try to connect on my tomcat serveur  I have 
  always the same message : HTTP Error 
  403 - Forbidden Possibly reasons 
  : I try to compare BASIC authenticator 
   and CLIENT-CERT authenticator.     * BasicAuthenticator class register an 
  MemoryRealmPrincipal object return by the MemoryRealm class     * SSLAuthenticator class register an 
  Principal object with  is simply return by certs[0].getSubjectDN() method 
  (and has no role associated) When 
  I modified a little bit the SSLAuthenticator class to find on the MemoryRealm 
  the MemoryRealmPrincipal associated 
  with the username = certs[0].getSubjectDN().getName()  ( with no 
  password) that seems run better... Excuse me, if it's a know limitation, a bug already know or a bad 
  settings ... Jérôme

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[Marc Saegesser]

BugReport 748 came in this morning.  I'm up to my eyeballs at work lately so
I haven't been able to look at it in depth, but it does look like a real
spec violation so it probably should be considered for 3.2.2.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans
> Bergsten
> Sent: Friday, January 12, 2001 2:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]
>
>
> Hans Bergsten wrote:
> >
> > "Ignacio J. Ortega" wrote:
> > >
> > > Hola Hans , Marc:
> > >
> > > You are using 3.2 from CVS AFAIK i did apply a patch 2 oe 3 weeks
> > > ago , that seems to resolve this problem, were reports #619
> #653 #513 ,
> > > and i think this is resolved in CVS, please review it and i
> will revise
> > > BugRat to close related bugs , if you agree it's already resolved..
> >
> > I was using the 3.2.1 version, not the latest CVS version (duh!).
> > Will test again with the CVS version.
>
> Okay, I have tested with the latest tomcat_32 version from CVS
> now and it works as it should. So the patch you applied solved
> the problem. Thanks for telling me before I spent time trying to
> solve this again ;-)
>
> Great, then I don't know of any serious issues that should hold up
> a 3.2.2 release.
>
> Hans
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software   http://www.gefionsoftware.com
> Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


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

RE: An alternative to JSP

[Paulo Gaspar]

Besides, I still found no great support for custom taglibs on
DreamWeaver/UltraDev.


OTOH, JSP + Custom Taglibs + Velocity/WebMacro can be a nice solution. I
work with people that can use a couple of custom taglibs + SQL to get data
from a database and then make a Vel./WM template work. They already do it
with the XSQLServlet, and using XSLT as a template mechanism is much
harder.

Custom taglibs can be used to provide simple dialects that help getting
productive people able to do simple scripting.

There is a lot of this people. It is not only designers/full fledged
programmers.


Have fun,
Paulo


> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 12, 2001 21:58
>
>
> > One can edit this stuff by hand if you want, but we're also
> starting to see
> > IDE
> > tools that understand this stuff -- complete with popping up
> dialong boxes to
> > populate the appropriate attributes -- in the same way the IDE tools for
> > building JavaBeans took much of the drudgery out of that process.
>
> Right, Dreamweaver's recent additions sound very cool and a much needed
> advancement for helping with JSP, however, it isn't real feasible as a
> requirement for working on OSS projects since it is commercial
> (expensive!)
> software. :-(
>


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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Christopher K. St. John]

Hans Bergsten wrote:
>
> The spec may not be explicit enough about this, but the session object
> you get back from the getSession() object is a container-managed object
> that the application is not supposed/allowed to keep long-lived
> references
> to. It's the same as with all other container-objects made available to
> the
> application; request, response, JSP tag handlers, etc.
> 

 I would have agreed with you before I read the
following in the 2.3PFD spec:

  7.3 Session Scope

  HttpSession objects must be scoped at the
  application / servlet context level. The
  underlying mechanism, such as the cookie
  used to establish the session, can be shared
  between contexts, but the object exposed, and
  more importantly the attributes in that object,
  must not be shared between contexts.

 By mentioning that the HttpSession object cannot
be shared outside the ServletContext, it strongly
implies that it can be shared within the context.
If that sort of thing isn't allowed, then 7.3 might
need to be clarified.


-cks

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

cvs commit: jakarta-tomcat-4.1/catalina build.xml

[remm]

remm01/01/12 14:14:38

  Modified:catalina build.xml
  Log:
  - ResourceFactory and TransactionFactory don't need to be left out of the
build, since dependencies and imports from other parts of J2EE have been
removed (using dynamic class loading instead).
  
  Revision  ChangesPath
  1.31  +0 -4  jakarta-tomcat-4.1/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.1/catalina/build.xml,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- build.xml 2001/01/09 04:27:05 1.30
  +++ build.xml 2001/01/12 22:14:38 1.31
  @@ -103,10 +103,6 @@
excludes="**/CVS/**">
 
  -  
  -  
 
   
  
  
  

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Hans Bergsten]

"Christopher K. St. John" wrote:
> 
> Hans Bergsten wrote:
> >
> > The spec may not be explicit enough about this, but the session object
> > you get back from the getSession() object is a container-managed object
> > that the application is not supposed/allowed to keep long-lived
> > references
> > to. It's the same as with all other container-objects made available to
> > the
> > application; request, response, JSP tag handlers, etc.
> >
> 
>  I would have agreed with you before I read the
> following in the 2.3PFD spec:
> 
>   7.3 Session Scope
> 
>   HttpSession objects must be scoped at the
>   application / servlet context level. The
>   underlying mechanism, such as the cookie
>   used to establish the session, can be shared
>   between contexts, but the object exposed, and
>   more importantly the attributes in that object,
>   must not be shared between contexts.
> 
>  By mentioning that the HttpSession object cannot
> be shared outside the ServletContext, it strongly
> implies that it can be shared within the context.
> If that sort of thing isn't allowed, then 7.3 might
> need to be clarified.

This section refers to the fact that a servlet in one context should
not be able to gain access to the same session data as a servlet
in another context (i.e., resources in two different context's can 
not "be part" of the same session) for security reasons .

It has nothing to do with whether a servlet in one context is allowed 
to hold on to the actual session object or not, which has to do with 
how much freedom the spec gives to container vendors in terms of 
pooling and life-cycle management for the internal objects.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

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

Re: NullPointerException from HttpSessionFacade.invalidate()

[Christopher K. St. John]

Hans Bergsten wrote:
> 
> "Christopher K. St. John" wrote:
> >
> >   7.3 Session Scope
> >
> >   HttpSession objects must be scoped at the
> >   application / servlet context level. The
> >   underlying mechanism, such as the cookie
> >   used to establish the session, can be shared
> >   between contexts, but the object exposed, and
> >   more importantly the attributes in that object,
> >   must not be shared between contexts.
> >
> >  By mentioning that the HttpSession object cannot
> > be shared outside the ServletContext, it strongly
> > implies that it can be shared within the context.
> > If that sort of thing isn't allowed, then 7.3 might
> > need to be clarified.
> 
> This section refers to the fact that a servlet in one context should
> not be able to gain access to the same session data as a servlet
> in another context (i.e., resources in two different context's can
> not "be part" of the same session) for security reasons .
> 
> It has nothing to do with whether a servlet in one context is allowed
> to hold on to the actual session object or not, which has to do with
> how much freedom the spec gives to container vendors in terms of
> pooling and life-cycle management for the internal objects.
> 

 Because Section 7.3 explicity discusses the HttpSession
object itself (as opposed to the objects it contains), it
suggests that the HttpSession object has an identity. 

 I don't think there is any question that after the end
of the lifecycle of an HttpSession object, it can be
recycled. But what earlier messages in this thread suggested
was that JServ was recycling HttpSession objects _during_
the lifetime of the session, so that req.getSession(false) could
return two different objects even within the same session.

 That would mean that the practice of synchronzing on the
HttpSession object was also not kosher? Since two servlets
within the same session at the same time could not be sure
of getting the same HttpSession object? Are you really
suggesting that that behavior is allowed by the spec?

 If so, I find that very unintuitive.


-cks

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

RE: [PATCH] adapter in load balancing (version 1.2 - Tomcat 3.2.x)

[GOMEZ Henri]

Will you update also the 3.3 branch ?-)

"Pour la plupart des hommes, se corriger consiste à changer de défauts."
-- Voltaire 

>-Original Message-
>From: Dan Milstein [mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 12, 2001 6:59 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [PATCH] adapter in load balancing (version 1.2 - Tomcat
>3.2.x)
>
>
>Benoit,
>
>Thanks -- I actually just fixed this in the 3.2 branch.
>
>-Dan
>
>Benoit Derouet wrote:
>> 
>> Hi,
>> 
>> The load balancer worker fail to handle load 
>balancing (with sticky
>> sessions) if the application uses custom cookies.
>> 
>> In some circumstances, the load balancer worker 
>can't retreive the server
>> name from the JSessionID cookie and is not able to redirect 
>to the good
>> server.
>> 
>> The algorithm parse the cookie header to extract the 
>server name from the
>> JSessionID cookie. It find properly the end of the server 
>name but fail to
>> cut the chars after.
>> So, it works fine if the cookie header contains only one 
>cookie (or if
>> JSessionID is the last cookie) but If they are custom 
>cookie, the server
>> name extracted will be: "servername;mycookieVal=myCookieValue .."
>> 
>> The bug is fixed around line 170.
>> (line id_end=NULL; replaced by id_end[0] = '\0'; )
>> 
>> 'hope this will be integrated in future versions ! 
>(as our customers need
>> sticky load balancing...)
>> 
>> regards.
>> 
>> Benoit
>-- 
>
>Dan Milstein // [EMAIL PROTECTED]
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>

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

RE: Tomcat 3.2.2 [Was: Re: BugRat Report #690 has been filed.]

[GOMEZ Henri]

A release will be nice since there were many bugs out 
since the 3.2.1 (jsp/jk)

I think it will be time to make TC 3.2 release more frequently.

+1

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

Patch for 3.2.2 - Bug #528

[David Rees]

Maybe with some luck this patch will finally make it into Tomcat 3.2.2.

Will somebody _please_ commit this to CVS?

I've been trying to get this committed to CVS for over a month now (probably
send 3-4 emails to tomcat-dev about it now), but no-one wants to apply it
for some reason.

-Dave

> -Original Message-
> From: David Rees [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 12, 2000 11:42 AM
> To: [EMAIL PROTECTED]
> Subject: RE: BugRat Report #528 has been filed.
>
> Before Tomcat 3.2.1 gets released, can someone apply this patch to fix the
> documentation in the FAQ?
>
> > -Original Message-
> > From: BugRat Mail System [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 05, 2000 12:52 PM
> > To: [EMAIL PROTECTED]
> > Subject: BugRat Report #528 has been filed.
> >
> > Bug report #528 has just been filed.
> >
> > You can view the report at the following URL:
> >
> >
> >
> > REPORT #528 Details.
> >
> > Project: Tomcat
> > Category: Bug Report
> > SubCategory: New Bug Report
> > Class: docbug
> > State: received
> > Priority: medium
> > Severity: non-critical
> > Confidence: public
> > Environment:
> >Release: Tomcat 3.2
> >JVM Release: all
> >Operating System: all
> >OS Release: all
> >Platform: all
> >
> > Synopsis:
> > src/doc/faq contains wrong information for overriding the JspServlet
> >
> > Description:
> > Can someone apply this patch?  It looks like the faq had fallen a
> > little out of date while the name of the JspServlet changed.
> > Took me a little while to figure out why JSPs stopped working
> > after following the FAQ.  :-)
> >
> > This diff was performed on tomcat-3.2 final src tarball.
> >
> > Thanks,
> > -Dave
> >
> > PS - I just posted this to the tomcat-dev list, thought it would
> > better to put it into BugRat.
> >
> > --- jakarta-tomcat-3.2-src/src/doc/faq.orig Tue Dec  5 12:36:19 2000
> > +++ jakarta-tomcat-3.2-src/src/doc/faq  Tue Dec  5 12:36:29 2000
> > @@ -225,7 +225,7 @@
> >jsp
> >
> >
> > -  org.apache.jasper.runtime.JSPServlet
> > +  org.apache.jasper.servlet.JspServlet
> >
> >
> >
> >
>


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

cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester SetBufferSize01.java

[craigmcc]

craigmcc01/01/12 16:51:01

  Modified:tester/src/tester/org/apache/tester SetBufferSize01.java
  Log:
  Tweak the details of this test so that it operates more like the
  corresponding CTS version (i.e. outputs text before the attempted call to
  setBufferSize()).
  
  Revision  ChangesPath
  1.2   +4 -6  
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/SetBufferSize01.java
  
  Index: SetBufferSize01.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/SetBufferSize01.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SetBufferSize01.java  2000/12/22 22:13:07 1.1
  +++ SetBufferSize01.java  2001/01/13 00:51:01 1.2
  @@ -68,7 +68,7 @@
* Negative test for ServletResponse.setBufferSize().
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2000/12/22 22:13:07 $
  + * @version $Revision: 1.2 $ $Date: 2001/01/13 00:51:01 $
*/
   
   public class SetBufferSize01 extends GenericServlet {
  @@ -92,13 +92,11 @@
   response.setContentType("text/plain");
   PrintWriter writer = response.getWriter();
   try {
  -writer.println("TEST");
  +writer.print("SetBufferSize01 ");
   response.setBufferSize(100);
  -response.reset();
  -writer.println("SetBufferSize01 FAILED - Did not throw 
IllegalStateException");
  +writer.println("FAILED - Did not throw IllegalStateException");
   } catch (IllegalStateException e) {
  -response.reset();
  -writer.println("SetBufferSize01 PASSED");
  +writer.println("PASSED");
   }
   while (true) {
   String message = StaticLogger.read();
  
  
  

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

cvs commit: jakarta-tomcat-4.1/tester/src/tester/org/apache/tester SetBufferSize01.java

[craigmcc]

craigmcc01/01/12 16:52:01

  Modified:tester/src/tester/org/apache/tester SetBufferSize01.java
  Log:
  Forward port the test imrpovement.
  
  Revision  ChangesPath
  1.2   +4 -6  
jakarta-tomcat-4.1/tester/src/tester/org/apache/tester/SetBufferSize01.java
  
  Index: SetBufferSize01.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/tester/src/tester/org/apache/tester/SetBufferSize01.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SetBufferSize01.java  2000/12/22 22:13:07 1.1
  +++ SetBufferSize01.java  2001/01/13 00:52:01 1.2
  @@ -68,7 +68,7 @@
* Negative test for ServletResponse.setBufferSize().
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2000/12/22 22:13:07 $
  + * @version $Revision: 1.2 $ $Date: 2001/01/13 00:52:01 $
*/
   
   public class SetBufferSize01 extends GenericServlet {
  @@ -92,13 +92,11 @@
   response.setContentType("text/plain");
   PrintWriter writer = response.getWriter();
   try {
  -writer.println("TEST");
  +writer.print("SetBufferSize01 ");
   response.setBufferSize(100);
  -response.reset();
  -writer.println("SetBufferSize01 FAILED - Did not throw 
IllegalStateException");
  +writer.println("FAILED - Did not throw IllegalStateException");
   } catch (IllegalStateException e) {
  -response.reset();
  -writer.println("SetBufferSize01 PASSED");
  +writer.println("PASSED");
   }
   while (true) {
   String message = StaticLogger.read();
  
  
  

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

Reports #638 & #637

[Ignacio J. Ortega]

Hola a todos:

Please AJP12 & 13 experts :-)

Have a look at reports  #637 & #638 they seems related to same issue (
#638 is hard to undertsand but relates to the same issue i think ) , i
can recall some guy did put a test page online some time ago about that,
please take a look at it, seems related to redirections & AJP & apache &
linux ... i dont have a box to confirm it...


Saludos ,
Ignacio J. Ortega

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

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

[nacho]

nacho   01/01/12 17:08:27

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
RequestImpl.java
  Log:
  Bug Report #757
  User Principal incorrectly Maintained
  Submitted by  David Winterfeldt ( [EMAIL PROTECTED] 
 )
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.52.2.5  +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java
  
  Index: RequestImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java,v
  retrieving revision 1.52.2.4
  retrieving revision 1.52.2.5
  diff -u -r1.52.2.4 -r1.52.2.5
  --- RequestImpl.java  2000/11/21 02:39:06 1.52.2.4
  +++ RequestImpl.java  2001/01/13 01:08:27 1.52.2.5
  @@ -726,7 +726,6 @@
   pathInfo=null;
   pathTranslatedIsSet=false;
   sessionIdSource = null;
  -
   // XXX a request need to override those if it cares
   // about security
   remoteAddr="127.0.0.1";
  @@ -741,6 +740,7 @@
   notAuthenticated=true;
userRoles=null;
reqRoles=null;
  +principal=null;
   }
   
   //  End utils
  
  
  

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

BugRat Report #757 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #757 was closed by Person #0

   Synopsis: User Principal incorrectly Maintained - Fix

 (logged in as: Ignacio Ortega)

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

BugRat Report #758 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #758 was closed by Person #0

   Synopsis: HTTP POST incorrect behavior

 (logged in as: Ignacio Ortega)

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

BugRat Report #756 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #756 was closed by Person #0

   Synopsis: User Principal incorrectly Maintained - Fix

 (logged in as: Ignacio Ortega)

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

cvs commit: jakarta-tomcat/src/doc faq

[nacho]

nacho   01/01/12 17:12:23

  Modified:src/doc  Tag: tomcat_32 faq
  Log:
  src/doc/faq contains wrong information for overriding the JspServlet
  Submitter: David Rees ( [EMAIL PROTECTED]  )
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.4.1   +1 -1  jakarta-tomcat/src/doc/faq
  
  Index: faq
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/faq,v
  retrieving revision 1.1
  retrieving revision 1.1.4.1
  diff -u -r1.1 -r1.1.4.1
  --- faq   2000/02/08 21:08:34 1.1
  +++ faq   2001/01/13 01:12:22 1.1.4.1
  @@ -225,7 +225,7 @@
 jsp
 
 
  -  org.apache.jasper.runtime.JSPServlet
  +  org.apache.jasper.runtime.JspServlet
 
 
 
  
  
  

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

BugRat Report #528 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #528 was closed by Person #0

   Synopsis: src/doc/faq contains wrong information for overriding the JspServlet

 (logged in as: Ignacio Ortega)

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

BugRat Report #752 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #752 was closed by Person #0

   Synopsis: User Principal incorrectly Maintained

 (logged in as: Ignacio Ortega)

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

RE: An alternative to JSP

[Tomas Rokicki]

> Exactly. It would have been nice if JSP was done right from the start
> instead of having an original goal of attempting to provide a solution to
> strictly compete with ASP.

My thought is that JSP was `done right from the start' (at least, with
custom taglibs)---it just doesn't solve the whole problem, nor would I
want it to.

> 

The main problem I have against tag libs and tag-based templates is the
tags are either invisible in the HTML view or else some squiggly little
box; it's really tough to get semantic information (hence my use of
%% rather than <> in my template language).  Of course, dreamweaver is
making that better, but even in dreamweaver it's still a box that
looks like [~].

Until of course you turn on tomcat, which we do and our developers do, to
see what's happening with the real server, but it's great to actually
have a clue what you're looking at in the main view too.

I'll shut up now and let everyone get back to work on TOTL (their own
template language).

-tom


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

RE: BugRat Report #758 was closed (apparently by: Ignacio Ortega)

[Ignacio J. Ortega]

Upsss, this was closed by mistake, sorry

Nick can you reopen it, please ???

TIA

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: BugRat Mail System [mailto:[EMAIL PROTECTED]]
> Enviado el: sábado 13 de enero de 2001 2:05
> Para: Z_Tomcat Alias
> Asunto: BugRat Report #758 was closed (apparently by: Ignacio Ortega)
> 
> 
> Report #758 was closed by Person #0
> 
>Synopsis: HTTP POST incorrect behavior
> 
>  (logged in as: Ignacio Ortega)
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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

BugRat Report #749 was closed (apparently by: Ignacio Ortega)

[BugRat Mail System]

Report #749 was closed by Person #0

   Synopsis: I had same problem  like Bug Report #61

 (logged in as: Ignacio Ortega)

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

RE: An alternative to JSP

[Nick Bauman]

Somewhat unrelated, I hear a lot of people going gaga over XSLT for web
development. I understand the desire: a single document represents the
data of the page, while other documents are used to convert that data for
different clients / views with an emphasis on content seperation from
presentation logic. 

But AFAIK, this is only 1/2 the battle. I still have business logic which 
cannot be handled in the XSLT code. Add the amount of work just to get the
presentation away from the content in a standards-compliant fashion
(work in both a human and a computer terms) isn't worth it unless, say, I
was going to implement web, WAP and Palm OS views for the Library of
Congress or the Human Genome Project. But all that just for Acme Widgets,
who has, at the most, 2000 products.

Kinda like using the Space Shuttle to go grocery shopping.

On Fri, 12 Jan 2001, Paulo Gaspar wrote:

> Besides, I still found no great support for custom taglibs on
> DreamWeaver/UltraDev.
> 
> 
> OTOH, JSP + Custom Taglibs + Velocity/WebMacro can be a nice solution. I
> work with people that can use a couple of custom taglibs + SQL to get data
> from a database and then make a Vel./WM template work. They already do it
> with the XSQLServlet, and using XSLT as a template mechanism is much
> harder.
> 
> Custom taglibs can be used to provide simple dialects that help getting
> productive people able to do simple scripting.
> 
> There is a lot of this people. It is not only designers/full fledged
> programmers.
> 
> 
> Have fun,
> Paulo
> 
> 
> > -Original Message-
> > From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 12, 2001 21:58
> >
> >
> > > One can edit this stuff by hand if you want, but we're also
> > starting to see
> > > IDE
> > > tools that understand this stuff -- complete with popping up
> > dialong boxes to
> > > populate the appropriate attributes -- in the same way the IDE tools for
> > > building JavaBeans took much of the drudgery out of that process.
> >
> > Right, Dreamweaver's recent additions sound very cool and a much needed
> > advancement for helping with JSP, however, it isn't real feasible as a
> > requirement for working on OSS projects since it is commercial
> > (expensive!)
> > software. :-(
> >
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-- 
Nicolaus Bauman
Software Engineer
Simplexity Systems



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

BugRat Report #758 was assigned to Z_Ant Alias

[BugRat Mail System]

Report #758 was assigned to Person #17

   Name: Z_Ant Alias
   Email:[EMAIL PROTECTED]
   HomePage: -NA-
   Phone:-NA-
   FAX:  -NA-

The report was previously assigned to person #1

   Name: Z_Tomcat Alias
   Email:[EMAIL PROTECTED]
   HomePage: http://jakarta.apache.org
   Phone:-NA-
   FAX:  -NA-

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

BugRat Report #758 was assigned to Z_Tomcat Alias

[BugRat Mail System]

Report #758 was assigned to Person #1

   Name: Z_Tomcat Alias
   Email:[EMAIL PROTECTED]
   HomePage: http://jakarta.apache.org
   Phone:-NA-
   FAX:  -NA-

The report was previously assigned to person #17

   Name: Z_Ant Alias
   Email:[EMAIL PROTECTED]
   HomePage: -NA-
   Phone:-NA-
   FAX:  -NA-

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

RE: BugRat Report #758 was closed (apparently by: Ignacio Ortega)

[Nick Bauman]

758 has been reopened.

On Sat, 13 Jan 2001, Ignacio J. Ortega wrote:

> Upsss, this was closed by mistake, sorry
> 
> Nick can you reopen it, please ???
> 
> TIA
> 
> Saludos ,
> Ignacio J. Ortega
> 
> 
> > -Mensaje original-
> > De: BugRat Mail System [mailto:[EMAIL PROTECTED]]
> > Enviado el: sábado 13 de enero de 2001 2:05
> > Para: Z_Tomcat Alias
> > Asunto: BugRat Report #758 was closed (apparently by: Ignacio Ortega)
> > 
> > 
> > Report #758 was closed by Person #0
> > 
> >Synopsis: HTTP POST incorrect behavior
> > 
> >  (logged in as: Ignacio Ortega)
> > 
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

-- 
Nicolaus Bauman
Software Engineer
Simplexity Systems



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

RE: An alternative to JSP

[Peter Donald]

At 07:22  12/1/01 -0600, Nick Bauman wrote:
>Somewhat unrelated, I hear a lot of people going gaga over XSLT for web
>development. I understand the desire: a single document represents the
>data of the page, while other documents are used to convert that data for
>different clients / views with an emphasis on content seperation from
>presentation logic. 

>But AFAIK, this is only 1/2 the battle. I still have business logic which 
>cannot be handled in the XSLT code. Add the amount of work just to get the
>presentation away from the content in a standards-compliant fashion
>(work in both a human and a computer terms) isn't worth it unless, say, I
>was going to implement web, WAP and Palm OS views for the Library of
>Congress or the Human Genome Project. But all that just for Acme Widgets,
>who has, at the most, 2000 products.

Have a look at Cocoon - it's got the early stages of it going through. True
it is still too complex but as it matures I think it will come down to a
reasonable level of complexity thou I mainly worked with XML so I may be
biased ;) 

Plain XML + XSLT is not a possibility (if you have the slightest concern
for performance) but with various generation techniques (like XSP - cocoons
answer to asp/jsp) combined with enforced separation of concerns (ie set a
flag to disable embedded logic and only go through taglibs) it could
definetly be a good option for the future.


Cheers,

Pete

*-*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."   |
|  - John Kenneth Galbraith   |
*-*


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

[OFF TOPIC] HTML question

[Marc Saegesser]

Please excuse this way off topic question but I'm looking for someone
smarter than I am and this seems like a good place to look :-)

I'm fighting with an HTML question.  I need to create a hidden  tag
whose value will contain white space, double quotes and single quotes.

For example



Obviously that won't work but I'm at a loss for something that will.  The
contents of the value attribute are CDATA and according to the HTML 4.01
specification section 6.2
(http://www.w3.org/TR/1999/REC-html401-19991224/types.html#h-6.2), character
entities in CDATA are supposed to be replaced with characters.  So one might
think that



would work but it doesn't in either Netscape or IE.  There must be something
simple that I'm missing.




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

Re: [OFF TOPIC] HTML question

[Jon Stevens]

on 1/12/01 6:12 PM, "Marc Saegesser" <[EMAIL PROTECTED]> wrote:

> There must be something simple that I'm missing.

URL encode it.

-jon

-- 
Honk if you love peace and quiet.



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

FW: Jakarta PMC Meeting Agenda / Info

[James Duncan Davidson]

-- 
James Duncan Davidson[EMAIL PROTECTED]
  !try; do()

-- Forwarded Message
From: James Duncan Davidson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Fri, 12 Jan 2001 17:16:24 -0800
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>
Subject: Jakarta PMC Meeting Agenda / Info


As promised, here's the information for the Jakarta PMC meeting.

WHEN:

Tuesday Jan 16th 1:00PM PDT

I anticipate that this meeting could span the entire afternoon. Please
plan accordingly.

WHERE:

CollabNet
8000 Marina Boulevard Suite 600
Brisbane, CA 94005-1865

For more info including directions see:
http://www.collab.net/about/contact.html

WHO:

This is a meeting for the Jakarta PMC members and the PMC members
will be primary participants in this meeting. However, it will
be an open door meeting. Anybody who is a committer to any project
under the Jakarta umbrella is welcome to attend and observe. As well
anybody interested in the future of the Jakarta project is welcome.
We have had requests for people to observe the proceedings for
educational purposes -- these folks as well are welcome.

The PMC Chairman reserves the right to limit participation by
any observer if circumstances warrant.

DIAL-IN INFORMATION:

Number: 954-797-1657
Participant Code: 507609

Note, we do have a maximum number of 20 concurrent connections available
on the conference calling system. Please be aware of this. The purpose
of the dial in number is to allow committers who can not otherwise
attend this meeting to observe to have visibility into the meeting. If
you are in the Bay Area, please attend the meeting in person rather than
calling in so that we can maximize lines for people that absolutely
can not be present in person.

BACKGROUND INFORMATION:

The ASF By-Laws states the following about PMC's:

"Section 6.3. Project Management Committees. In addition to the officers
of the corporation, the Board of Directors may, by resolution, establish
one or more Project Management Committees consisting of at least one
officer of the corporation, who shall be designated chairman of such
committee, and may include one or more other members of the corporation.
Unless elected or appointed as an officer in accordance with Sections
6.1 and 6.4 of these Bylaws, a member of a Project Management Committee
shall not be deemed an officer of the corporation.

Each Project Management Committee shall be responsible for the active
management of one or more projects identified by resolution of the Board
of Directors which may include, without limitation, the creation or
maintenance of "open-source" software for distribution to the public at
no charge. Subject to the direction of the Board of Directors, the
chairman of each Project Management Committee shall be primarily
responsible for project(s) managed by such committee, and he or she
shall establish rules and procedures for the day to day management of
project(s) for which the committee is responsible.

The Board of Directors of the corporation may, by resolution, terminate
a Project Management Committee at any time. "

This section of the ASF By-Laws is what defines what the PMCs are and
how they can act.

AGENDA:

 *) Definition of the scope of the Jakarta Project. This is required
by the Chairman of the ASF and the ASF Board. At the current time
the Chairman feels that many of the projects in the Jakarta and
XML projects are out of scope. Either we define a new scope
and propose it to the board, or we propose that certain subprojects
be moved to their own, different projects with their own scope.

The result of this action item will be presented to the Board for
its consideration.

As part of this bullet point, I will be moving that we propose
to the board the creation of a separate, top level project for Ant.

 *) Formalization of a subproject responsibility hierarchy. The PMC, and
its chairman, are responsible for the day to day operations of the
subprojects contained by the Jakarta Project. Currently the Jakarta
project has too many codebases for the PMC and Chairman to oversee
directly. As a solution, the PMC will be appointing responsible
parties for each of the subprojects who will be responsible for the
day to day operations of that subproject. These appointees will be
responsible to the PMC chairman.

 *) Tomcat 3.x vs. Tomcat 4.x. We will be reaching a final decision
about the future of the Tomcat source base and what our process
for managing the factors that created the current situation will
be moving forward. For reference you may want to read:

http://www.x180.net/Mutterings/Apach

[PATCHES] Catalina 4.1 Session Persistence

[Kief Morris]

These patches are my proposal for session persistence in Catalina 4.1. Please
look these over and give me your comments, and commit them if they look OK.

The main change is the addition of a PersistentManager class, an optional replacement
for StandardManager, providing the following configurable functionality:

- Saves sessions to a Store on shutdown, loads on restart. This is currently 
implemented 
  in StandardManager, but PersistentManager makes use of the Store interface.
- Swaps sessions out to a Store if the number in memory exceeds maxActiveSessions,
  to better manage resources. A minIdleSwap property prevents sessions from being
  swapped out if they haven't been idle for very long, to avoid thrashing.
- Swaps sessions out to a Store if they are idle for too long. With this feature, an 
app
  can have very long session expiration times without over-burdening memory.
- Backs sessions up to Store (but keeps them in memory) if they are idle for too long.
  This provides basic fault tolerance, since the sessions will be read in from the 
Store
  when the server starts after a crash. NOT IMPLEMENTED YET! There is an issue
  regarding the Servlet 2.3 specification which I will discuss below.

To test this out, see the server.xml file - there is a section to uncomment and tweak
the configuration.

ISSUES:


- Backing up Sessions: I believe that HttpSessionActivationListeners should be notified
  when sessions are being backed up and restored. However, application developers
  reading the Servlet 2.3 specification [PFD] might not expect a session to remain
  in active use after the sessionWillPassivate() method is called. I would like to get 
  some feedback on this.

- I still have not figured out how to get Catalina to instantiate the Store class for 
me,
  this patch hard-codes the use of FileStore in PersistentManager. I've tried mucking
  around in startup/Catalina.java, to no avail. Can anyone help me out with this?

- There is a lot of duplication of code between PersistentManager and StandardManager.
  Maybe this should be moved to ManagerBase?

- The use of Session/StandardSession is very messy in ManagerBase, StandardManager, 
  and now PersistentManager. Although some code uses the Session interface and executes
  StandardSession-specific code only after testing, much of this code will break if an
  alternative implementation is used (essential properties aren't set, etc.), and some
  code has StandardSession hard-coded without tests. 
  It looks as if someone had good intentions to make it possible to replace 
StandardSession 
  with a different implementation, but it hasn't been followed through, so it's just a 
mess.
  This means I can't create a PersistentSession class and keep persistence-related code
  out of StandardSession, which is too bad. 
  Fixing this will require a fair amount of refactoring.

- While developing apps you would sometimes like to wipe out all of the sessions,
  which is a bit awkward to do with persistence enabled because the server saves
  and restores them on restarts. Currently you would have to change the server.xml 
  configuration for PersistentManager to disable all persistence and backups, and then 
  it will clear out the Store when you restart. You can manually delete them from the 
  directory used by FileStore, but this won't work with other Store implementations.
  Ideally there should be a command line argument which causes the Store to be 
  cleared.

PATCH COMMENTS


Store.java

- Added getManager(), setManager(), and clear() methods.

FileStore.java

- Implemented Store functionality, sessions are serialized one per file.

PersistentManager

- Implemented persistence across server restarts
- Implemented swapping out of sessions to manage resources, based on
  the number of sessions in memory and idle times.
- Stubs for backing up of sessions based on idle times, not yet implemented.

server.xml

- Added a commented out section to enable and configure PersistentManager

LocalStrings.properties

- Added strings for logging by FileStore and PersistentManager.


Regards,
Kief


--- FileStore.java.orig Fri Aug 11 20:39:15 2000
+++ FileStore.java  Fri Jan 12 21:55:02 2001
@@ -74,18 +74,27 @@
 import java.io.FileNotFoundException;
 import java.io.FileOutputStream;
 import java.io.IOException;
+import java.io.InputStream;
 import java.io.ObjectInputStream;
 import java.io.ObjectOutputStream;
+import java.io.ObjectStreamClass;
 import java.io.Serializable;
 import java.util.Enumeration;
 import java.util.Hashtable;
 import java.util.Vector;
+import javax.servlet.ServletContext;
+import org.apache.catalina.Context;
+import org.apache.catalina.Globals;
 import org.a

[PATCHES] Catalina Session handling

[Kief Morris]

This is the first of two sets of patches relating to sessions. The following
set will be my proposed session persistence package, while these are more
general and should be considered independently.

ManagerBase.java

- Fixed a bug where recycled sessions don't seem to have their Managers set.
  The session.recycle() clears the manager, so the createSession() method should
  set the manager if it uses a recycled session. It's possible this is done elsewhere,
  but I don't see it, caused some NullPointerExceptions while testing my persistence 
  code.
- Fixed a bug where findSession() apparently doesn't call access() on the returned
  session. The result is sessions will expire based on when they were first created,
  not when they were last accessed. Again, this might be set somewhere else, but
  it wasn't getting set in my persistence testing.

StandardSession.java

- Changed expire() to recycle the session if the Manager is a subclass of ManagerBase.
- Added activate() and passivate() methods which notify HttpSessionActivationListeners
  when the session is activated or passivated, as per the Servlet 2.3 specification 
PFD.

Kief


--- ManagerBase.java.orig   Fri Jan 12 22:03:13 2001
+++ ManagerBase.javaFri Jan 12 21:22:44 2001
@@ -506,7 +506,9 @@
recycled.remove(size - 1);
}
}
-   if (session == null)
+   if (session != null)
+   session.setManager(this);
+   else
session = new StandardSession(this);
 
// Initialize the properties of the new session and return it
@@ -544,7 +546,10 @@
if (id == null)
return (null);
synchronized (sessions) {
-   return ((Session) sessions.get(id));
+   Session session = (Session) sessions.get(id);
+   if (session != null)
+   session.access();
+   return (session);
}
 
 }


--- StandardSession.java.orig   Thu Jan 11 23:01:02 2001
+++ StandardSession.javaFri Jan 12 22:17:50 2001
@@ -77,6 +77,7 @@
 import java.util.Iterator;
 import javax.servlet.ServletException;
 import javax.servlet.http.HttpSession;
+import javax.servlet.http.HttpSessionActivationListener;
 import javax.servlet.http.HttpSessionAttributesListener;
 import javax.servlet.http.HttpSessionBindingEvent;
 import javax.servlet.http.HttpSessionBindingListener;
@@ -538,10 +539,58 @@
 
 // We have completed expire of this session
expiring = false;
+   if ((manager != null) && (manager instanceof ManagerBase)) {
+   recycle();
+   ((ManagerBase) manager).recycle(this);
+   }
 
 }
 
 
+/**
+ * Perform the internal processing required to passivate
+ * this session.
+ */
+public void passivate() {
+
+   // Notify ActivationListeners
+   HttpSessionEvent event = null;
+   String keys[] = keys();
+   for (int i = 0; i < keys.length; i++) {
+   Object attribute = getAttribute(keys[i]);
+   if (attribute instanceof HttpSessionActivationListener) {
+   if (event == null)
+   event = new HttpSessionEvent(this);
+   // FIXME: Should we catch throwables?
+   ((HttpSessionActivationListener)attribute).sessionWillPassivate(event);
+   }
+   }
+
+}
+
+
+/**
+ * Perform internal processing required to activate this
+ * session.
+ */
+public void activate() {
+
+   // Notify ActivationListeners
+   HttpSessionEvent event = null;
+   String keys[] = keys();
+   for (int i = 0; i < keys.length; i++) {
+   Object attribute = getAttribute(keys[i]);
+   if (attribute instanceof HttpSessionActivationListener) {
+   if (event == null)
+   event = new HttpSessionEvent(this);
+   // FIXME: Should we catch throwables?
+   ((HttpSessionActivationListener)attribute).sessionDidActivate(event);
+   }
+   }
+
+}
+
+
 /**
  * Return the isValid flag for this session.
  */



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

Re: cvs commit: jakarta-tomcat/src/doc faq

[Hans Bergsten]

[EMAIL PROTECTED] wrote:
> 
> nacho   01/01/12 17:12:23
> 
>   Modified:src/doc  Tag: tomcat_32 faq
>   Log:
>   src/doc/faq contains wrong information for overriding the JspServlet
>   Submitter: David Rees ( [EMAIL PROTECTED]  )
> [...]
>   -  org.apache.jasper.runtime.JSPServlet
>   +  org.apache.jasper.runtime.JspServlet

Hmm... Doesn't look like you changed much ;-) "runtime" should be
replaced with "servlet". If you don't have the time to fix this I
will try to get to it this weekend.

Hans
-- 
Hans Bergsten   [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com

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

cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources FileDirContext.java

[remm]

remm01/01/12 21:15:56

  Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java
  Log:
  - Fix minor path related problems.
  - Still three unimplemented functions.
  - Apparently, there are problems with encoding/decoding (so accessing files
containing spaces fail. This is probably a problem with the FileDirContext
implementation.
  
  Revision  ChangesPath
  1.3   +8 -4  
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java
  
  Index: FileDirContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- FileDirContext.java   2001/01/12 06:59:08 1.2
  +++ FileDirContext.java   2001/01/13 05:15:55 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
 1.2 2001/01/12 06:59:08 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/01/12 06:59:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/FileDirContext.java,v
 1.3 2001/01/13 05:15:55 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/01/13 05:15:55 $
*
* 
*
  @@ -97,7 +97,7 @@
* Filesystem Directory Context implementation helper class.
*
* @author Remy Maucherat
  - * @version $Revision: 1.2 $ $Date: 2001/01/12 06:59:08 $
  + * @version $Revision: 1.3 $ $Date: 2001/01/13 05:15:55 $
*/
   
   public class FileDirContext extends BaseDirContext {
  @@ -796,7 +796,11 @@
   } catch (IOException e) {
   }
   absPath = absPath.substring(absoluteBase.length());
  +if (absPath.equals(""))
  +absPath = "/";
   canPath = canPath.substring(absoluteBase.length());
  +if (canPath.equals(""))
  +canPath = "/";
   if ((canPath == null) || (absPath == null)
   || (!canPath.equals(absPath)))
   return null;
  
  
  

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

cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources DirContextURLStreamHandlerFactory.java DirContextURLConnection.java LocalStrings.properties

[remm]

remm01/01/12 21:17:05

  Modified:catalina/src/share/org/apache/naming/resources
DirContextURLConnection.java
LocalStrings.properties
  Added:   catalina/src/share/org/apache/naming/resources
DirContextURLStreamHandlerFactory.java
  Log:
  - Added a factory for the stream handler.
  - The URL connection will auto connect.
  
  Revision  ChangesPath
  1.2   +57 -16
jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java
  
  Index: DirContextURLConnection.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- DirContextURLConnection.java  2001/01/12 06:59:08 1.1
  +++ DirContextURLConnection.java  2001/01/13 05:17:04 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
 1.1 2001/01/12 06:59:08 remm Exp $
  - * $Revision: 1.1 $
  - * $Date: 2001/01/12 06:59:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/naming/resources/DirContextURLConnection.java,v
 1.2 2001/01/13 05:17:04 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/01/13 05:17:04 $
*
* 
*
  @@ -84,7 +84,7 @@
* content is directly returned.
* 
* @author mailto:[EMAIL PROTECTED]">Remy Maucherat
  - * @version $Revision: 1.1 $
  + * @version $Revision: 1.2 $
*/
   public class DirContextURLConnection 
   extends URLConnection {
  @@ -132,6 +132,12 @@
   protected Attributes attributes;
   
   
  +/**
  + * Date.
  + */
  +protected long date;
  +
  +
   // - Properties
   
   
  @@ -145,19 +151,24 @@
   public void connect()
   throws IOException {
   
  -try {
  -object = context.lookup(getURL().getFile());
  -attributes = context.getAttributes(getURL().getFile());
  -if (object instanceof Resource)
  -resource = (Resource) object;
  -if (object instanceof DirContext)
  -collection = (DirContext) object;
  -} catch (NamingException e) {
  -// Object not found
  +if (!connected) {
  +
  +try {
  +date = System.currentTimeMillis();
  +object = context.lookup(getURL().getFile());
  +attributes = context.getAttributes(getURL().getFile());
  +if (object instanceof Resource)
  +resource = (Resource) object;
  +if (object instanceof DirContext)
  +collection = (DirContext) object;
  +} catch (NamingException e) {
  +// Object not found
  +}
  +
  +connected = true;
  +
   }
   
  -connected = true;
  -
   }
   
   
  @@ -180,6 +191,14 @@
   /**
* Return the last modified date.
*/
  +public long getDate() {
  +return date;
  +}
  +
  +
  +/**
  + * Return the last modified date.
  + */
   public long getLastModified() {
   return getHeaderFieldDate(ResourceAttributes.LAST_MODIFIED, 0);
   }
  @@ -189,6 +208,14 @@
* Returns the name of the specified header field.
*/
   public String getHeaderField(String name) {
  +if (!connected) {
  +// Try to connect (silently)
  +try {
  +connect();
  +} catch (IOException e) {
  +}
  +}
  +
   Attribute attribute = attributes.get(name);
   try {
   return attribute.get().toString();
  @@ -196,6 +223,7 @@
   // Shouldn't happen, unless the attribute has no value
   }
   return (null);
  +
   }
   
   
  @@ -205,8 +233,11 @@
   public Object getContent()
   throws IOException {
   
  +if (!connected)
  +connect();
  +
   if (resource != null)
  -return resource;
  +return getInputStream();
   if (collection != null)
   return collection;
   if (object != null)
  @@ -241,8 +272,18 @@
   public InputStream getInputStream() 
   throws IOException {
   
  -if (resource == null)
  -throw new IOException();
  +if (!connected)
  +connect();
  +
  +if (resource == null) {
  +throw new FileNotF

cvs commit: jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java LocalStrings.properties

[remm]

remm01/01/12 21:20:05

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java LocalStrings.properties
  Log:
  - Fix lots of path related problems.
  - Directory browser works again.
  - The only known issues are :
- writing, which will fail because of functions which are not implemented yet
  in the FileDirContext.
- accessing encoded URLs fail (like files with spaces in their names.
  - WebDAV is broken at the moment, and needs a small revision of the
algorithms.
  
  Revision  ChangesPath
  1.20  +11 -19
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- DefaultServlet.java   2001/01/12 06:55:34 1.19
  +++ DefaultServlet.java   2001/01/13 05:20:05 1.20
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.19 2001/01/12 06:55:34 remm Exp $
  - * $Revision: 1.19 $
  - * $Date: 2001/01/12 06:55:34 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.20 2001/01/13 05:20:05 remm Exp $
  + * $Revision: 1.20 $
  + * $Date: 2001/01/13 05:20:05 $
*
* 
*
  @@ -118,7 +118,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.19 $ $Date: 2001/01/12 06:55:34 $
  + * @version $Revision: 1.20 $ $Date: 2001/01/13 05:20:05 $
*/
   
   public class DefaultServlet
  @@ -1439,12 +1439,6 @@
   
   }
   
  - if (!resourceInfo.exists()) {
  - response.sendError(HttpServletResponse.SC_NOT_FOUND, 
  -   resourceInfo.path);
  - return;
  - }
  -
   // Checking If headers
   if ( !checkIfHeaders(request, response, resourceInfo) ) {
   return;
  @@ -1525,7 +1519,8 @@
   
   if (content) {
   // Serve the directory browser
  -resourceInfo.is = render(resourceInfo);
  +resourceInfo.is = 
  +render(request.getContextPath(), resourceInfo);
   }
   
   }
  @@ -1738,9 +1733,8 @@
* @param contextPath Context path to which our internal paths are
*  relative
*/
  -public InputStream render(ResourceInfo resourceInfo) {
  +public InputStream render(String contextPath, ResourceInfo resourceInfo) {
   
  -String contextPath = resourceInfo.path;
   String name = resourceInfo.path;
   
// Number of characters to trim from the beginnings of filenames
  @@ -1785,8 +1779,8 @@
writer.print(rewriteUrl(contextPath));
   if (parent.equals(""))
   parent = "/";
  -if (contextPath.endsWith("/"))
  -parent = parent.substring(1);
  +//if (contextPath.endsWith("/"))
  +//parent = parent.substring(1);
writer.print(parent);
writer.print("\">");
writer.print(sm.getString("directory.parent", parent));
  @@ -1821,7 +1815,7 @@
   ResourceInfo childResourceInfo = 
   new ResourceInfo(resourceName, directory);
   
  -String trimmed = resourceName.substring(trim);
  +String trimmed = resourceName/*.substring(trim)*/;
   if (trimmed.equalsIgnoreCase("WEB-INF") ||
   trimmed.equalsIgnoreCase("META-INF"))
   continue;
  @@ -1835,9 +1829,7 @@
   writer.print("  \r\n");
   writer.print(" 0))
  -resourceName = resourceName.substring(1);
  +resourceName = rewriteUrl(name + resourceName);
   writer.print(resourceName);
   writer.print("\">");
   writer.print(trimmed);
  
  
  
  1.4   +6 -0  
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/servlets/LocalStrings.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- LocalStrings.properties   2000/11/10 01:19:17 1.3
  +++ LocalStrings.properties   2001/01/13 05:20:05 1.4
  @@ -19,3 +19,9 @@
   managerServlet.reloaded=OK - Reloaded application at context pat

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

[remm]

remm01/01/12 21:20:49

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Fix path initialization of the DirContext.
  
  Revision  ChangesPath
  1.35  +15 -10
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- StandardContext.java  2001/01/12 06:50:06 1.34
  +++ StandardContext.java  2001/01/13 05:20:49 1.35
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.34 2001/01/12 06:50:06 remm Exp $
  - * $Revision: 1.34 $
  - * $Date: 2001/01/12 06:50:06 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.35 2001/01/13 05:20:49 remm Exp $
  + * $Revision: 1.35 $
  + * $Date: 2001/01/13 05:20:49 $
*
* 
*
  @@ -136,7 +136,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.34 $ $Date: 2001/01/12 06:50:06 $
  + * @version $Revision: 1.35 $ $Date: 2001/01/13 05:20:49 $
*/
   
   public class StandardContext
  @@ -922,12 +922,17 @@
   if (container == null) {
   docBase = (new File(engineBase(), getDocBase())).getPath();
   } else {
  -// Use the "appBase" property of this container
  -String appBase = ((Host) container).getAppBase();
  -File file = new File(appBase);
  -if (!file.isAbsolute())
  -file = new File(engineBase(), appBase);
  -docBase = (new File(file, getDocBase())).getPath();
  +File file = new File(getDocBase());
  +if (!file.isAbsolute()) {
  +// Use the "appBase" property of this container
  +String appBase = ((Host) container).getAppBase();
  +file = new File(appBase);
  +if (!file.isAbsolute())
  +file = new File(engineBase(), appBase);
  +docBase = (new File(file, getDocBase())).getPath();
  +} else {
  +docBase = file.getPath();
  +}
   }
   ((BaseDirContext) resources).setDocBase(docBase);
   }
  
  
  

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

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

[remm]

remm01/01/12 21:22:41

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
  Log:
  - Implement getRealPath (fixes Jasper).
  - getRealPath() returns the name of the file which would be server by the
request. Note that a file does not necessarily exists.
  
  Revision  ChangesPath
  1.11  +8 -5  
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
  
  Index: ApplicationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ApplicationContext.java   2001/01/12 06:50:06 1.10
  +++ ApplicationContext.java   2001/01/13 05:22:40 1.11
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.10 2001/01/12 06:50:06 remm Exp $
  - * $Revision: 1.10 $
  - * $Date: 2001/01/12 06:50:06 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
 1.11 2001/01/13 05:22:40 remm Exp $
  + * $Revision: 1.11 $
  + * $Date: 2001/01/13 05:22:40 $
*
* 
*
  @@ -66,6 +66,7 @@
   
   
   import java.io.InputStream;
  +import java.io.File;
   import java.net.MalformedURLException;
   import java.net.URL;
   import java.util.ArrayList;
  @@ -104,7 +105,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.10 $ $Date: 2001/01/12 06:50:06 $
  + * @version $Revision: 1.11 $ $Date: 2001/01/13 05:22:40 $
*/
   
   public final class ApplicationContext
  @@ -351,7 +352,9 @@
*/
   public String getRealPath(String path) {
   
  -return (null);
  +// Here, we return a fake path
  +File file = new File(context.getDocBase(), path);
  +return (file.getAbsolutePath());
   
   }
   
  
  
  

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

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

[remm]

remm01/01/12 21:27:54

  Modified:catalina/src/share/org/apache/catalina/loader
StandardClassLoader.java StandardLoader.java
  Log:
  - "Fixes" webapp classloading.
  - Class files in /WEB-INF/classes are loaded through a URL to a DirContext
(good :).
  - JAR files couldn't work that way, so it uses direct filesystem access :(
  - You can read the comments about my failed attempt in StandardLoader.
I left the commented code which tries to register JNDI URL repositories.
Unfortunately, it appears that the URLClassLoader (and its hidden helper
classes) don't like my URLs. Any explanation / solution would be greatly
appreciated.
  
  Revision  ChangesPath
  1.6   +116 -18   
jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java
  
  Index: StandardClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- StandardClassLoader.java  2000/10/09 21:04:02 1.5
  +++ StandardClassLoader.java  2001/01/13 05:27:54 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.5 2000/10/09 21:04:02 craigmcc Exp $
  - * $Revision: 1.5 $
  - * $Date: 2000/10/09 21:04:02 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.1/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java,v
 1.6 2001/01/13 05:27:54 remm Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/01/13 05:27:54 $
*
* 
*
  @@ -71,11 +71,16 @@
   import java.net.MalformedURLException;
   import java.net.URL;
   import java.net.URLClassLoader;
  +import java.net.URLConnection;
  +import java.net.URLStreamHandlerFactory;
  +import java.net.URLStreamHandler;
   import java.util.ArrayList;
   import java.util.Enumeration;
   import java.util.HashMap;
   import java.util.Iterator;
   import java.util.jar.JarFile;
  +import java.util.jar.JarEntry;
  +import java.util.jar.JarInputStream;
   import java.util.jar.Manifest;
   
   
  @@ -99,7 +104,8 @@
* independently.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.5 $ $Date: 2000/10/09 21:04:02 $
  + * @author Remy Maucherat
  + * @version $Revision: 1.6 $ $Date: 2001/01/13 05:27:54 $
*/
   
   public class StandardClassLoader
  @@ -122,6 +128,20 @@
   
   
   /**
  + * Construct a new ClassLoader with no defined repositories and no
  + * parent ClassLoader, but with a stream handler factory.
  + * 
  + * @param factory the URLStreamHandlerFactory to use when creating URLs
  + */
  +public StandardClassLoader(URLStreamHandlerFactory factory) {
  +
  +super(new URL[0], null, factory);
  +this.factory = factory;
  +
  +}
  +
  +
  +/**
* Construct a new ClassLoader with no defined repositories and the
* specified parent ClassLoader.
*
  @@ -135,6 +155,22 @@
   
   
   /**
  + * Construct a new ClassLoader with no defined repositories and the
  + * specified parent ClassLoader.
  + *
  + * @param parent The parent ClassLoader
  + * @param factory the URLStreamHandlerFactory to use when creating URLs
  + */
  +public StandardClassLoader(ClassLoader parent, 
  +   URLStreamHandlerFactory factory) {
  +
  +super((new URL[0]), parent, factory);
  +this.factory = factory;
  +
  +}
  +
  +
  +/**
* Construct a new ClassLoader with the specified repositories and
* no parent ClassLoader.
*
  @@ -263,6 +299,12 @@
   protected String systems[] = { "java." };
   
   
  +/**
  + * URL stream handler for additional protocols.
  + */
  +protected URLStreamHandlerFactory factory = null;
  +
  +
   // - Properties
   
   
  @@ -352,7 +394,12 @@
   
   // Add this repository to our underlying class loader
   try {
  -super.addURL(new URL(repository));
  +URLStreamHandler streamHandler = null;
  +String protocol = parseProtocol(repository);
  +if (factory != null)
  +streamHandler = factory.createURLStreamHandler(protocol);
  +URL url = new URL(null, repository, streamHandler);
  +super.addURL(url);
   } catch (MalformedURLException e) {
   throw new IllegalArgumentException(e.toString());
   }
  @@ -1028,6 +1075,21 @@
   
   
   /**
  + * Parse URL protocol.
  + * 
  + * @return String protocol
  + */
  +protected static String parseProtocol(String spec) {
  +if (spec == null)
  +re

AccessLogUtil and minor patch to AccessLogValve

[David Weinrich]

Time for another installment of the AccessLogUtil, this time the parser is
( nearly ) done and handles most of the possible entries that the apache
mod_log_config does are present ( including filtering an entry based on
status code and parameters to a particular entry type ). The docs for that
module are at:

http://httpd.apache.org/docs/mod/mod_log_config.html

The stuff that I have questions about or haven't implemented yet are as
follows:

%...c:Connection status when response is completed.
  'X' = connection aborted before the response completed.
  '+' = connection may be kept alive after the response is
sent.
  '-' = connection will be closed after the response is sent.
Notes:
  * I'm not sure exactly where I would grab the connection aborted
case from ( mostly this was a low priority item, I will dig
through the code and try to locate that a little later ).


%...{FOOBAR}e:  The contents of the environment variable FOOBAR
and
%...{Foobar}n:  The contents of note "Foobar" from another module.

and
%...P:  The process ID of the child that serviced the request.

Notes:
  * I don't know these are meaningful/useful in this particular
environment.

%...{Foobar}o:  The contents of Foobar: header line(s) in the reply.

Notes:
  * This is present *but* response headers that are set internally
( Content-Length and Content-Type are two I ran up against so
far ) aren't yet available. I can fix this in the parser if these
two are the only response headers that get snagged by this.

%...s:Status.  For requests that got internally redirected,
  this is the status of the *original* request ---
  %...>s for the last.

Notes:
  * Not sure exactly what the > would mean in this particular
environment, if I'm reading it correctly this is done by
default the way this is implemented but I don't think I am
reading this correctly.

%...{format}t:  The time, in the form given by format, which should
be in strftime(3) format. (potentially localized)

Notes:
  * For now this actually would take a java.text.SimpleDateFormat
style format. If needed I might be able to parse strtime
formats too but...one thing at a time. I've also added a
shortcut ISO for ISO style timestamp output
"-MM-dd HH:mm:ss (+|-)offset".

%...T:  The time taken to serve the request, in seconds.

Notes:
  * Not implemented yet, I'm still trying to figure out a clean
or sane way to do this. So far it looks like the most
straightforward way I've looked at would be to have the
calling valve invoke a 'beforeResponse()' and
'afterResponse()' method but that seems like something of
an ugly solution.

%...v:  The canonical ServerName of the server serving the request.
%...V:  The server name according to the UseCanonicalName setting.

Notes:
  * Is this distinction meaningful in this environment? Right now
the values returned are identical.

I hope this is a fairly useful utility class, the next steps I will
probably take include:

1) Test and retest the parser.
2) Hopefully clarify the items included above and fix.
3) Add additional items available in tomcat but not in mod_log_config.
4) Add a second configuration method that allows the client of this class
   to add arbitrary items by name and store a foreign name for that item
   ( mostly useful for JDBCAccessLog ).

In addition I have some minimal syslog client code sitting around
gathering dust, I know one or two people have requested syslog logs
and access logs. If someone wants I can clean this code up and create
a org.apache.catalina.logger.SyslogLogger class.

One last note: while looking around in AccessLogValve I noticed a
peculiarity in the way the first file opened always lacked the date
stamp. The patch for that is attached.

Thanks for your patience ( this email is a bit lengthy I know ), again any
ideas/critiques/pointers are more than welcome.

David Weinrich



--- AccessLogValve.java Fri Jan 12 22:59:34 2001
+++ AccessLogValveEd.java   Fri Jan 12 22:58:04 2001
@@ -528,7 +528,6 @@
 if (!dateStamp.equals(tsDate)) {
 synchronized (this) {
 close();
-dateStamp = tsDate;
 open();
 }
 }
@@ -572,6 +571,10 @@
dir = new File(System.getProperty("catalina.home") +
   File.separator + directory);
dir.mkdirs();
+
+// set the dateStamp here, avoiding the creation of a dateStamp-less
+// log the first day of use...
+dateStamp = dateFormatter.format(currentDate);
 
// Open the current log file
try {

 TestAccessLogValve.java
 AccessLogUtil.java

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

Re: AccessLogUtil and minor patch to AccessLogValve

[David Weinrich]

In diving through the documentation I found for log4j, and hitting the
website I noticed...it is now part of the jakarta project (yay!). Seems like
this would be a (much much much) better idea than my mostly-untested syslog
code for an addition to the logger classes, any thoughts on this?

David Weinrich


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