Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec

[Bill Barker]

Ok, I take back my .  It seems that they have really made a hash out
of the security-constraints.  Something like Philippe's implementation is
required.  Section 12.8.3 requires that only the 'best match' constraints
are processed, and those in a 'grant' fashion (i.e. you get the least
restrictive privilege of the most restrictive constraints).  Now you just
need to be a rocket-scientist to figure out how your security-constraints
work ;-). So in my example below, a request for /myapp/clients/product1/
will only consider the 'product1' constraint, and ignore the constraint for
'/clients/*'.  If I had added a security-constraint for '*.jsp', then a
request for /myapp/clients/product1/index.jsp would use the 'product1'
constraint, and ignore the '*.jsp' constraint.  Isn't life going to be fun
on the user-list ;-).

This means that RealmBase.findSecurityConstraints is going to have to change
to only pass back the 'best-match' constraints.  At least this isn't an
interface change.  The decision on whether to change the Realm interface, or
move the header processing to AuthenticatorBase is still open.

- Original Message - 
From: "Bill Barker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 9:00 PM
Subject: Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec


> Yes, this looks like it changed between pfd3 to fr :(.
Security-constraints
> now work like 'grants' instead of 'constraints'.  IMHO, this make the 2.4
> security model all but useless.
> 
> It would be natural to configure something like:
>   
>  
> Client Area
> /clients/*
>   
>   
>  
>  *
>   
>   
>   
>  
> Product1 Client Area
> /clients/product1/*
>   
>   
>  
>  product1
>   
>   
>   
>  
> Product2 Client Area
> /clients/product2/*
>   
>   
>  
>  product2
>   
>   
>
> The way the 2.4 spec is written, all authenticated users have access to
> everything under /myapp/clients/.  To get what I want is now a
configuration
> nightmare :(.
> 
>
> Now back to fixing things.  I sort of like the idea of changing the Realm
> interface so that 'hasUserDataPermissions' and 'hasResourcePermissions'
take
> a SecurityConstraint [].  However, after a GA release, this may be a bit
> much.  Philippe's solution looks a bit over-kill to me, but I'm not going
to
> object if someone wants to commit it.  I'm thinking of moving the
> header-setting stuff out of RealmBase and into AuthenticatorBase.  It may
> cause some custom realms to stop working, but there shouldn't be that many
> for TC 5 yet :).
>
> Of course, I'm volunteering for the code-monkey (© Pier) part of
this.
> Since anyway we go is a pretty big change, I just wanted to get a
consensus
> first.
>
> Opinions, Comments, Flames?
>
> - Original Message - 
> From: "philippe.leothaud" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 08, 2003 6:43 PM
> Subject: Tomcat authorization handling seems not to function according to
> Servlet 2.4 Spec
>
>
> Hi all,
>
> I am new to Tomcat's mailing lists, and I don't really know if this list
is
> the right place for such a post : excuse me if it is not the case.
>
> I wonder if I didn't notice something which is not a real bug in Tomcat,
as
> it seems to do exactly what developers want it to do,
> but more a difference between the implementation of authorization policy
> (the handling of a Web Application web.xml
> security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec
says.
>
> Example of the problem (from the Tomcat Jsp-examples WebApp) :
>
> 
> 
>   
>   
>   
>   
>   
>   
>   
>   
> 
>
> tomcat-users.xml
>
> 
>  Example Security Constraint
>  
>   Protected Area
>   
>   /security/protected/*
>   
>   DELETE
>   GET
>   POST
>   PUT
>  
>  
>   
>   tomcat
>  
> 
>
> 
>  Example Security Constraint
>  
>   Protected Area
>   
>   /security/protected/*
>   
>   DELETE
>   GET
>   POST
>   PUT
>  
>  
>   
>   role1
>  
> 
>
> 
> 
>  FORM
>  Example Form-Based Authentication Area
>  
>   /security/protected/login.jsp
>   /security/protected/error.jsp
>  
> 
>
> 
> 
>  role1
> 
> 
>  tomcat
> 
>
> webapps/jsp-examples/WEB-INF/web.xml (excerpt)
>
> I've been adding  a new security-constraint element, separing the
authorized
> roles each in its security-constraint
>
> According to what the Servlet 2.4 says (see below for exact reference),
two
> security constraints on the same
> (url-pattern, http-method) should result in the addition of the given
> authorizations and so in this case,
> users "tomcat", "role1" and "both" should be authorized to access the
> protected resource.
>
> But here, it is the contrary : you can't access
> http://10.160.4.205:8080/jsp-examples/security/protected/ under
> "tomcat" or "role1" identity any more, but you can still using the "both"
> identity : To

Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec

[Philippe Leothaud]

Hi Bill,

I totally agree with you, this security model is going to be a pain
somewhere to correctly configure access rights...

As of my "solution", the real interest is that (as far as I can see) it
doesn't change at all any API : the only thing that changes is the body of
the method
SecurityConstraint[] findSecurityConstraints(HttpRequest request, Context
context) in org.apache.catalina.realm.RealmBase (starting at line 438), I
only changed the body so that it calls the new MergedConstraintBuilder
class.

In any case, the signature remains the same.

Today :
1-  AuthenticatorBase gets all possible Constraints mathing the request, by
calling
SecurityConstraint [] constraints = realm.findSecurityConstraints(hrequest,
this.context); (AuthenticatorBase , l. 502)
2- RealmBase handles that request, returning an array of all the Constraints
matching the URI and the HTTP method of the request
3- AuthenticatorBase retrieves all these Constraints, cast the Request and
Response into HttpServletRequest and  HttpServletResponse (l 515-525)
4- For each Constraint of the array, AuthenticatorBase asks RealmBase if the
UserDataPermission is OK
5- For each Constraint of the array, AuthenticatorBase asks RealmBase if the
AuthConstraint is OK

All that I change is what is happening in step 2 :
- RealmBase asks the new Class to retrieve an Array of matching
Constraints
- The new Class builds a fake Constraint representing all possible
AuthConstraints and UserDataConstraints for this (URI, HTTPMethod)
- It returns an array of SecurityConstraints, just like before.

The only difference is that now this array has only one (or zero) element,
but neither RealmBase neither AuthenticatorBase are aware of that.

All the remaining methods calls are just the same, they will just be faster
because there is only one Constraint in the array (and I think that if the
10 lines of code needed to cache the fake Constraints are added in this new
Class, it may really be faster and compute-time saving) .

I used that for a custom authorization framework I'm working on and it's OK
for me.


Thanks for having replied quickly (It's difficult to work seriously while
you're looking at your mail-box every minute to see if a response wasn't
posted ;-)


- Original Message -
From: "Bill Barker" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, December 09, 2003 6:00 AM
Subject: Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec


> Yes, this looks like it changed between pfd3 to fr :(.
Security-constraints
> now work like 'grants' instead of 'constraints'.  IMHO, this make the 2.4
> security model all but useless.
> 
> It would be natural to configure something like:
>   
>  
> Client Area
> /clients/*
>   
>   
>  
>  *
>   
>   
>   
>  
> Product1 Client Area
> /clients/product1/*
>   
>   
>  
>  product1
>   
>   
>   
>  
> Product2 Client Area
> /clients/product2/*
>   
>   
>  
>  product2
>   
>   
>
> The way the 2.4 spec is written, all authenticated users have access to
> everything under /myapp/clients/.  To get what I want is now a
configuration
> nightmare :(.
> 
>
> Now back to fixing things.  I sort of like the idea of changing the Realm
> interface so that 'hasUserDataPermissions' and 'hasResourcePermissions'
take
> a SecurityConstraint [].  However, after a GA release, this may be a bit
> much.  Philippe's solution looks a bit over-kill to me, but I'm not going
to
> object if someone wants to commit it.  I'm thinking of moving the
> header-setting stuff out of RealmBase and into AuthenticatorBase.  It may
> cause some custom realms to stop working, but there shouldn't be that many
> for TC 5 yet :).
>
> Of course, I'm volunteering for the code-monkey (© Pier) part of
this.
> Since anyway we go is a pretty big change, I just wanted to get a
consensus
> first.
>
> Opinions, Comments, Flames?
>
> - Original Message -
> From: "philippe.leothaud" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 08, 2003 6:43 PM
> Subject: Tomcat authorization handling seems not to function according to
> Servlet 2.4 Spec
>
>



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

Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec

[Bill Barker]

Yes, this looks like it changed between pfd3 to fr :(.  Security-constraints
now work like 'grants' instead of 'constraints'.  IMHO, this make the 2.4
security model all but useless.

It would be natural to configure something like:
  
 
Client Area
/clients/*
  
  
 
 *
  
  
  
 
Product1 Client Area
/clients/product1/*
  
  
 
 product1
  
  
  
 
Product2 Client Area
/clients/product2/*
  
  
 
 product2
  
  

The way the 2.4 spec is written, all authenticated users have access to
everything under /myapp/clients/.  To get what I want is now a configuration
nightmare :(.


Now back to fixing things.  I sort of like the idea of changing the Realm
interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take
a SecurityConstraint [].  However, after a GA release, this may be a bit
much.  Philippe's solution looks a bit over-kill to me, but I'm not going to
object if someone wants to commit it.  I'm thinking of moving the
header-setting stuff out of RealmBase and into AuthenticatorBase.  It may
cause some custom realms to stop working, but there shouldn't be that many
for TC 5 yet :).

Of course, I'm volunteering for the code-monkey (© Pier) part of this.
Since anyway we go is a pretty big change, I just wanted to get a consensus
first.

Opinions, Comments, Flames?

- Original Message - 
From: "philippe.leothaud" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 08, 2003 6:43 PM
Subject: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec


Hi all,

I am new to Tomcat's mailing lists, and I don't really know if this list is
the right place for such a post : excuse me if it is not the case.

I wonder if I didn't notice something which is not a real bug in Tomcat, as
it seems to do exactly what developers want it to do,
but more a difference between the implementation of authorization policy
(the handling of a Web Application web.xml
security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says.

Example of the problem (from the Tomcat Jsp-examples WebApp) :



  
  
  
  
  
  
  
  


tomcat-users.xml


 Example Security Constraint
 
  Protected Area
  
  /security/protected/*
  
  DELETE
  GET
  POST
  PUT
 
 
  
  tomcat
 



 Example Security Constraint
 
  Protected Area
  
  /security/protected/*
  
  DELETE
  GET
  POST
  PUT
 
 
  
  role1
 




 FORM
 Example Form-Based Authentication Area
 
  /security/protected/login.jsp
  /security/protected/error.jsp
 




 role1


 tomcat


webapps/jsp-examples/WEB-INF/web.xml (excerpt)

I've been adding  a new security-constraint element, separing the authorized
roles each in its security-constraint

According to what the Servlet 2.4 says (see below for exact reference), two
security constraints on the same
(url-pattern, http-method) should result in the addition of the given
authorizations and so in this case,
users "tomcat", "role1" and "both" should be authorized to access the
protected resource.

But here, it is the contrary : you can't access
http://10.160.4.205:8080/jsp-examples/security/protected/ under
"tomcat" or "role1" identity any more, but you can still using the "both"
identity : Tomcat has realized the intersection
of the authorizations instead of doing the union.


Analyze of the problem

After inverstigating a while in the code, here is what I noticed :

First,

In SecurityConstraint[] RealmBase.findSecurityConstraints(HttpRequest
request, Context context)
(the method begins at l. 445 of the org.apache.catalina.realm.RealmBase
file),

each and every SecurityConstraint (<=> security-constraint in web.xml)
containing a SecurityCollection
(<=> web-ressource-collection in web.xml) containing a url-pattern matching
the User's request URI
and defining a restriction on the http-method used by the user for his
request is retrieved, using

boolean SecurityConstraint.included(String uri, String method)
(method starts at line 343 of org.apache.catalina.deploy.SecurityConstraint)

While only SecurityConstraints containing SecurityCollections containing the
url-pattern which is the
best-match to the User's request URI amongst all the url-patterns defined in
web.xml should be retained first, and then amongst
these remaining constraints we shall keep only the ones defining a
restriction on the same method (or no restriction
on the method, as stated in servlet-2_4-fr-spec.pdf, ch SRV 12-8-3, pp
100-101)


Second

in public boolean hasResourcePermission(HttpRequest request,
   HttpResponse response,
   SecurityConstraint constraint,
   Context context)
(the method begins at line 501 of the org.apache.catalina.realm.RealmBase
file)

the restrictions on the authorized groups are analyzed, constraint after
constraint, and as soon as

Placement of JSP/HTML Files

[Asad Habib]

Hello. Does anyone know if there is a way to place
your JSP/HTML files in a subfolder of the root level
directory instead of in the root level directory. For
example, if I have a web app named Test, I would like
to place my files in /Test/jsp instead of in /Test.
Your help would be greatly appreciated. Thanks.

- Asad

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

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

DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP

[bugzilla]

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

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

Incorrect SMAP generated for JSP





--- Additional Comments From [EMAIL PROTECTED]  2003-12-09 03:23 ---
I think a global flag that set some reasonable debug settings would be 
fantastic and make configuration much simpler.

And, thanks for fixing the bug. :-)

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

DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP

[bugzilla]

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

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

Incorrect SMAP generated for JSP

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-09 02:54 ---
Maybe it should.  Come to think of it, we should just set a single flag, such as
'development', to turn on/off debugging.  So setting development would set some
reasbable default for checkInterval, classdebuginfo, development, keepgenerated,
reloading, and mappedfile.  What do you think?

Anyway, this bug is fixed now.

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

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

[kinman]

kinman  2003/12/08 18:51:35

  Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
  Log:
  - Fix 25263: bad smap when template text got concatenated.
  
  Revision  ChangesPath
  1.21  +6 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java
  
  Index: SmapUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- SmapUtil.java 22 Oct 2003 19:10:58 -  1.20
  +++ SmapUtil.java 9 Dec 2003 02:51:35 -   1.21
  @@ -613,19 +613,22 @@
   //Add a LineInfo that corresponds to the beginning of this node
   int iInputStartLine = mark.getLineNumber();
   int iOutputStartLine = n.getBeginJavaLine();
  -smap.addLineData(iInputStartLine, fileName, 1, iOutputStartLine, 1);
  +int iOutputLineIncrement = breakAtLF? 1: 0;
  +smap.addLineData(iInputStartLine, fileName, 1, iOutputStartLine, 
  + iOutputLineIncrement);
   
   // Output additional mappings in the text
   java.util.ArrayList extraSmap = n.getExtraSmap();
   
   if (extraSmap != null) {
   for (int i = 0; i < extraSmap.size(); i++) {
  +iOutputStartLine += iOutputLineIncrement;
   smap.addLineData(
   iInputStartLine+((Integer)extraSmap.get(i)).intValue(),
   fileName,
   1,
  -++iOutputStartLine,
  -1);
  +iOutputStartLine,
  +iOutputLineIncrement);
   }
   }
   }
  
  
  

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

Tomcat authorization handling seems not to function according to Servlet 2.4 Spec

[philippe.leothaud]

Hi all, 

I am new to Tomcat's mailing lists, and I don't really know if this list is the right 
place for such a post : excuse me if it is not the case.

I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems 
to do exactly what developers want it to do,  
but more a difference between the implementation of authorization policy (the handling 
of a Web Application web.xml 
security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says.

Example of the problem (from the Tomcat Jsp-examples WebApp) : 



  
  
  
  
  
  
  
  


tomcat-users.xml


 Example Security Constraint
 
  Protected Area
  
  /security/protected/*
  
  DELETE
  GET
  POST
  PUT
 
 
  
  tomcat
 



 Example Security Constraint
 
  Protected Area
  
  /security/protected/*
  
  DELETE
  GET
  POST
  PUT
 
 
  
  role1
 




 FORM
 Example Form-Based Authentication Area
 
  /security/protected/login.jsp
  /security/protected/error.jsp
 




 role1


 tomcat


webapps/jsp-examples/WEB-INF/web.xml (excerpt)

I've been adding  a new security-constraint element, separing the authorized roles 
each in its security-constraint

According to what the Servlet 2.4 says (see below for exact reference), two security 
constraints on the same 
(url-pattern, http-method) should result in the addition of the given authorizations 
and so in this case,
users "tomcat", "role1" and "both" should be authorized to access the protected 
resource.

But here, it is the contrary : you can't access 
http://10.160.4.205:8080/jsp-examples/security/protected/ under 
"tomcat" or "role1" identity any more, but you can still using the "both" identity : 
Tomcat has realized the intersection
of the authorizations instead of doing the union.


Analyze of the problem

After inverstigating a while in the code, here is what I noticed : 

First, 

In SecurityConstraint[] RealmBase.findSecurityConstraints(HttpRequest request, Context 
context) 
(the method begins at l. 445 of the org.apache.catalina.realm.RealmBase file),

each and every SecurityConstraint (<=> security-constraint in web.xml) containing a 
SecurityCollection
(<=> web-ressource-collection in web.xml) containing a url-pattern matching the User's 
request URI 
and defining a restriction on the http-method used by the user for his request is 
retrieved, using

boolean SecurityConstraint.included(String uri, String method) 
(method starts at line 343 of org.apache.catalina.deploy.SecurityConstraint)

While only SecurityConstraints containing SecurityCollections containing the 
url-pattern which is the
best-match to the User's request URI amongst all the url-patterns defined in web.xml 
should be retained first, and then amongst
these remaining constraints we shall keep only the ones defining a restriction on the 
same method (or no restriction
on the method, as stated in servlet-2_4-fr-spec.pdf, ch SRV 12-8-3, pp 100-101)


Second

in public boolean hasResourcePermission(HttpRequest request,
   HttpResponse response,
   SecurityConstraint constraint,
   Context context)
(the method begins at line 501 of the org.apache.catalina.realm.RealmBase file)

the restrictions on the authorized groups are analyzed, constraint after constraint, 
and as soon as one constraint is not verified, 

response.getResponse()).sendError(
HttpServletResponse.SC_FORBIDDEN,
sm.getString("realmBase.forbidden"));

is sent to the User : this means that at the contrary of what the spec says, for a 
same 
(http-method, url-pattern) couple, it's not the union of the authorizations but the 
intersection that is realized.

Spec : The rules to combine roles are given in servlet-2_4-fr-spec.pdf, ch SRV 12.8.1, 
pp97-98 : 

 "The combination of authorization constraints that name roles or that imply
 roles via the name shall yield the union of the role names in the individual
 constraints as permitted roles. A security constraint that does not contain an
 authorization constraint shall combine with authorization constraints that name or
 imply roles to allow unauthenticated access. The special case of an authorization
 constraint that names no roles shall combine with any other constraints to override
 their affects and cause access to be precluded."


Third

A similar problem as the second one accurs in the call to 

public boolean hasUserDataPermission(HttpRequest request,
 HttpResponse response,
 SecurityConstraint constraint)
(the method begins at line 627 of the org.apache.catalina.realm.RealmBase file)

As in the second point, constraints are examined one by one, instead of determining 
globally the policy for all
the constraints applying for the same (http-method, url-patern)

Spec :The rules to combine user-data-constraints are given in servlet-2_4-fr-spec.pdf, 
ch SRV 12.8.1, p98 : 

 "The combination of u

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java

[amyroh]

amyroh  2003/12/08 17:54:33

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
   catalina/src/share/org/apache/catalina/realm RealmBase.java
  Log:
  Revert the patch.  Seems like this case is already handled in the Mapper in TC5.
  
  Revision  ChangesPath
  1.13  +3 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
  
  Index: ApplicationFilterFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- ApplicationFilterFactory.java 9 Dec 2003 00:50:28 -   1.12
  +++ ApplicationFilterFactory.java 9 Dec 2003 01:54:33 -   1.13
  @@ -156,10 +156,6 @@
   
   if (attribute != null){
   requestPath = attribute.toString();
  -int semicolon = requestPath.indexOf(";");
  -if (semicolon >= 0) {
  -requestPath = requestPath.substring(0, semicolon);
  -}
   }
   
   HttpServletRequest hreq = null;
  
  
  
  1.19  +4 -15 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
  
  Index: RealmBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- RealmBase.java9 Dec 2003 00:50:58 -   1.18
  +++ RealmBase.java9 Dec 2003 01:54:33 -   1.19
  @@ -461,17 +461,6 @@
   if (contextPath.length() > 0)
   uri = uri.substring(contextPath.length());
   
  -if (uri != null) {
  -int semicolon = uri.indexOf(";");
  -if (semicolon >= 0) {
  -String baseuri = uri.substring(0, semicolon);
  -if (debug >= 2)
  -log("Request uri '" + uri + "' treated as '" + baseuri +
  -"' for security constraint matching.");
  -uri = baseuri;
  -}
  -}
  -
   String method = hreq.getMethod();
   for (int i = 0; i < constraints.length; i++) {
   if (log.isDebugEnabled())
  
  
  

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

DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP

[bugzilla]

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

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

Incorrect SMAP generated for JSP





--- Additional Comments From [EMAIL PROTECTED]  2003-12-09 00:54 ---
The suggested workaround of setting mappedfile to true works perfectly, once 
all the previously compiled JSP state is removed from the Tomcat work 
directory.  Thank you very much for the suggestion.

By the way, the default Tomcat settings are basically set up for debugging, 
except for mappedfile.  For example, checkInterval, classdebuginfo, 
development, keepgenerated, reloading are all set to development/debug settings 
by default.  Is there some special reason that mappedfile is not set 
accordingly?  Should it be?

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java

[amyroh]

amyroh  2003/12/08 16:51:47

  Modified:catalina/src/share/org/apache/catalina/mbeans
ServerLifecycleListener.java
  Log:
  Fix indentation.
  
  Revision  ChangesPath
  1.12  +38 -38
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java
  
  Index: ServerLifecycleListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/ServerLifecycleListener.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ServerLifecycleListener.java  25 Sep 2003 12:49:01 -  1.11
  +++ ServerLifecycleListener.java  9 Dec 2003 00:51:47 -   1.12
  @@ -152,41 +152,41 @@
   /**
* MX4J adaptor name.
*/
  - protected String adaptor = null;
  +protected String adaptor = null;
   
  - public String getAdaptor() {
  - return (this.adaptor);
  - }
  -
  - public void setAdaptor(String adaptor) {
  - this.adaptor = adaptor;
  - }
  -
  - /**
  -  * MX4J jrmp/iiop listen host
  -  */ 
  - protected String adaptorHost = null;
  -
  - public String getAdaptorHost() {
  - return (this.adaptorHost);
  - }
  -
  - public void setAdaptorHost(String adaptorHost) {
  - this.adaptorHost = adaptorHost;
  - }
  -
  - /**
  -  * MX4J jrmp/iiop listen port
  -  */ 
  - protected int adaptorPort = -1;
  -
  - public int getAdaptorPort() {
  - return (this.adaptorPort);
  - }
  -
  - public void setAdaptorPort(int adaptorPort) {
  - this.adaptorPort = adaptorPort;
  - }
  +public String getAdaptor() {
  +return (this.adaptor);
  +}
  +
  +public void setAdaptor(String adaptor) {
  +this.adaptor = adaptor;
  +}
  +
  +/**
  + * MX4J jrmp/iiop listen host
  + */ 
  +protected String adaptorHost = null;
  +
  +public String getAdaptorHost() {
  +return (this.adaptorHost);
  +}
  +
  +public void setAdaptorHost(String adaptorHost) {
  +this.adaptorHost = adaptorHost;
  +}
  +
  +/**
  + * MX4J jrmp/iiop listen port
  + */ 
  +protected int adaptorPort = -1;
  +
  +public int getAdaptorPort() {
  +return (this.adaptorPort);
  +}
  +
  +public void setAdaptorPort(int adaptorPort) {
  +this.adaptorPort = adaptorPort;
  +}
   
   
   // -- ContainerListener Methods
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm RealmBase.java

[amyroh]

amyroh  2003/12/08 16:50:58

  Modified:catalina/src/share/org/apache/catalina/realm RealmBase.java
  Log:
  Strip out uri parameters (";*") during filter mappings or security constraints 
matching - bugtraq 4903209.
  
  Revision  ChangesPath
  1.18  +16 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java
  
  Index: RealmBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- RealmBase.java2 Sep 2003 21:22:05 -   1.17
  +++ RealmBase.java9 Dec 2003 00:50:58 -   1.18
  @@ -460,6 +460,18 @@
   String contextPath = hreq.getContextPath();
   if (contextPath.length() > 0)
   uri = uri.substring(contextPath.length());
  +
  +if (uri != null) {
  +int semicolon = uri.indexOf(";");
  +if (semicolon >= 0) {
  +String baseuri = uri.substring(0, semicolon);
  +if (debug >= 2)
  +log("Request uri '" + uri + "' treated as '" + baseuri +
  +"' for security constraint matching.");
  +uri = baseuri;
  +}
  +}
  +
   String method = hreq.getMethod();
   for (int i = 0; i < constraints.length; i++) {
   if (log.isDebugEnabled())
  
  
  

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

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

[amyroh]

amyroh  2003/12/08 16:50:28

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationFilterFactory.java
  Log:
  Strip out uri parameters (";*") during filter mappings or security constraints 
matching - bugtraq 4903209.
  
  Revision  ChangesPath
  1.12  +7 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java
  
  Index: ApplicationFilterFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationFilterFactory.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ApplicationFilterFactory.java 2 Sep 2003 21:22:04 -   1.11
  +++ ApplicationFilterFactory.java 9 Dec 2003 00:50:28 -   1.12
  @@ -156,6 +156,10 @@
   
   if (attribute != null){
   requestPath = attribute.toString();
  +int semicolon = requestPath.indexOf(";");
  +if (semicolon >= 0) {
  +requestPath = requestPath.substring(0, semicolon);
  +}
   }
   
   HttpServletRequest hreq = null;
  
  
  

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

DO NOT REPLY [Bug 25263] - Incorrect SMAP generated for JSP

[bugzilla]

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

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

Incorrect SMAP generated for JSP





--- Additional Comments From [EMAIL PROTECTED]  2003-12-09 00:03 ---
Argh!  When I concatenated adjecent template text strings, I forgot to update
the smap too!  I'll try to fix this.  In the meantime, use the compiler option
'mappedfile' as a workaround, which you may want to do anyway when debugging.

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

Placement of Tag Library Descriptor

[Asad Habib]

Hello. I am using Tomcat 4.1.24 on Mac OS 10.3 and
when I place the tld file used by my web application
in /Test/tlds(where Test is the name of the
application), I get a 404 Error. When I place the same
tld file in /Test, everything works fine. Does anyone
know why this is happening? Apparently, the
application is able to find the tld since the Tomcat
logs show no errors. Any help would be greatly
appreciated. Thanks.

- Asad

__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

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

DO NOT REPLY [Bug 25338] New: - URI Rewrite does not function according to Servlet2.3 specifications (jsession= , servlet-mapping & filter-mapping)

[bugzilla]

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

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

URI Rewrite does not function according to Servlet2.3 specifications (jsession= , 
servlet-mapping & filter-mapping)

   Summary: URI Rewrite does not function according to Servlet2.3
specifications (jsession= , servlet-mapping & filter-
mapping)
   Product: Tomcat 4
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A URI is improperly distpatched when the ;jsession=xxx is added to the URI.
  The catalina lookup uses everything from the URI:hostname:port to the ? 
delimiter to define a "resource".  When ;jsession=xxx is added upon the uri for 
return the resource is not found.  The published FIX is to enable the apache-
web-server's mod_rewrite and have the webserver fix this for tomcat... this is 
an inappropriate fix.  Since tomcat is bundled in Jboss as a stand-alone 
webservice (and when tested in stand-alone, without apache), it can not use the 
apache-mod_rewrite hack.  The catalina module needs to correctly handle the 
resource information, if the ;jsession=xxx is not within spec, then for 
compliance to spec this habit will have to change.

  Another bug discovered while debugging this issue... 

  The filter-mapping /* does not filter calls to the traditional servlet-
mapping="*.do" for struts.  This breaks the filter-mapping concept.  Luckily 
for me the ;jsession=xxx bug is not caught by the servlet *.do mapping and my 
filter can catch this to reroute it to the appropriate resource.

I suggest looking into the Catilina dispatcher and uri parsing semantics
I do not have time to fully debug this :(

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

DO NOT REPLY [Bug 22867] - Tag handlers can't be inner/nested classes

[bugzilla]

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

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

Tag handlers can't be inner/nested classes





--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 19:07 ---
Can someone clarify what will happen now.  Will A$B be 
converted to A.B in the generated .java file (if not, then javac 1.4.2+ will 
fail)?  Also, will this fix be in Tomcat 4.x branch?

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

Re: [PATCH] Servlet Examples

[Jeanfrancois Arcand]

Done

Thanks,

-- Jeanfrancois

Mark Thomas wrote:

Noticed this while looking at the examples. Worth making sure we get this sort 
of thing right.

Mark

Index: webapps/examples/servlets/helloworld.html
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/webapps/examples/servlets/helloworld.html,v
retrieving revision 1.1
diff -u -r1.1 helloworld.html
--- webapps/examples/servlets/helloworld.html	17 Aug 2000 00:58:20 -	1.1
+++ webapps/examples/servlets/helloworld.html	6 Dec 2003 18:47:56 -
@@ -21,7 +21,6 @@
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("");
-out.println("");
out.println("");
out.println("");
out.println("");

Index: jsr154/examples/helloworld.html
===
RCS file: 
/home/cvspublic/jakarta-servletapi-5/jsr154/examples/helloworld.html,v
retrieving revision 1.2
diff -u -r1.2 helloworld.html
--- jsr154/examples/helloworld.html	29 Oct 2002 17:42:57 -	1.2
+++ jsr154/examples/helloworld.html	6 Dec 2003 18:49:44 -
@@ -21,7 +21,6 @@
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("");
-out.println("");
out.println("");
out.println("");
out.println("");

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



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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup catalina.properties

[remm]

remm2003/12/08 09:28:31

  Modified:catalina/src/share/org/apache/catalina/startup
catalina.properties
  Log:
  - Sync with the main catalina.properties.
  
  Revision  ChangesPath
  1.5   +3 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/catalina.properties
  
  Index: catalina.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/catalina.properties,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- catalina.properties   26 Sep 2003 19:31:16 -  1.4
  +++ catalina.properties   8 Dec 2003 17:28:31 -   1.5
  @@ -1,10 +1,10 @@
  -##
  +#
   # List of comma-separated packages that start with or equal this string
   # will cause a security exception to be thrown when
   # passed to checkPackageAccess unless the
   # corresponding RuntimePermission ("accessClassInPackage."+package) has
   # been granted.
  
-package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
  
+package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans.
   #
   # List of comma-separated packages that start with or equal this string
   # will cause a security exception to be thrown when
  @@ -52,4 +52,4 @@
   # "foo/*.jar": Add all the JARs of the specified folder as class 
   #  repositories
   # "foo/bar.jar": Add bar.jar as a class repository 
  -shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/lib/*.jar
  +shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
  
  
  

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

Re: Tomcat 5.0.16 catalina.properties

[Michael Kloss]

Hi,

3)
According to org/apache/catalina/startup/CatalinaProperties.java, the
location of catalina.properties can be specified via the catalina.config
option.  Shouldn't that be documented in the catalina.properties file?


I don't know if this works (it looks like it would, though).

Rémy
I've tested this option. If you pass in startup 
-Dcatalina.config=PATH-TO-catalina.properties Tomcat uses the specified 
properties-file.

Michael



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

cvs commit: jakarta-tomcat-4.0/webapps/examples/servlets helloworld.html

[jfarcand]

jfarcand2003/12/08 07:40:42

  Modified:webapps/examples/servlets helloworld.html
  Log:
  Port patch.
  
  Revision  ChangesPath
  1.2   +0 -1  jakarta-tomcat-4.0/webapps/examples/servlets/helloworld.html
  
  Index: helloworld.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/servlets/helloworld.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- helloworld.html   17 Aug 2000 00:58:20 -  1.1
  +++ helloworld.html   8 Dec 2003 15:40:42 -   1.2
  @@ -21,7 +21,6 @@
   response.setContentType("text/html");
   PrintWriter out = response.getWriter();
   out.println("");
  -out.println("");
   out.println("");
   out.println("");
   out.println("");
  
  
  

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

cvs commit: jakarta-servletapi-5/jsr154/examples helloworld.html

[jfarcand]

jfarcand2003/12/08 07:38:29

  Modified:jsr154/examples helloworld.html
  Log:
  Apply patch from Mark Thomas (medthomas at ntlworld dot com)
  
  Revision  ChangesPath
  1.3   +0 -1  jakarta-servletapi-5/jsr154/examples/helloworld.html
  
  Index: helloworld.html
  ===
  RCS file: /home/cvs/jakarta-servletapi-5/jsr154/examples/helloworld.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- helloworld.html   29 Oct 2002 17:42:57 -  1.2
  +++ helloworld.html   8 Dec 2003 15:38:29 -   1.3
  @@ -21,7 +21,6 @@
   response.setContentType("text/html");
   PrintWriter out = response.getWriter();
   out.println("");
  -out.println("");
   out.println("");
   out.println("");
   out.println("");
  
  
  

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

DO NOT REPLY [Bug 24763] - Apache-Tomcat comm fails streaming objects of certain predictble sizes

[bugzilla]

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

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

Apache-Tomcat comm fails streaming objects of certain predictble sizes





--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 14:35 ---
some easy steps to reproduce this kind of error
(in short, parameter value of some certain length gets 
changed in transit - last character of the parameter value
gets equal to '\u' instead of '\u0030' which was originally
sent)

1) create a jsp - say bb.jsp
<%
  String v = request.getParameter("v");
  int LEN=8185;
  for( int i=0; ihttp://your-host-apache-tomcat/bb.jsp";);
URLConnection uc = u.openConnection();
uc.setRequestProperty("Content-Type", "application/x-www-form-urlencoded");
StringBuffer val = new StringBuffer("v=");
for (int j = 0; j < LEN; j++) {
  val.append("0");
}
uc.setRequestProperty("Content-Length", "" + val.length());
uc.setDoOutput(true);
uc.getOutputStream().write(val.toString().getBytes());
uc.getInputStream().read();
  }

3) see in catalina.out that last character in the parameter value
is '\u' , not '\u0030' as it should be


That kind of problem (filling with 0-es) is not limited to single byte.
Out production site sometimes experiences blocks of zeroes
somehow becoming parameter names/values, so the problem is rather critical.

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

Re: Tomcat 5.0.16 catalina.properties

[Remy Maucherat]

Marx, Mitchell E (Mitch), ALABS wrote:
1)
There seem to be 2 different catalina.properties:
jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\conf\cata
lina.properties
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/li
b/*.jar
- this winds up in CATALINA_HOME/conf, but when the binary
tarball is expanded, the permissions are 600.  So, in my case the file
does not get read
jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\share\org
\apache\catalina\startup\catalina.properties
shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/li
b/*.jar
- this winds up inside bootstrap.jar.  Note this version says
catalina.home, instead of catalina.base.
According to
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
the second file is incorrect.
	If multiple Tomcat instances are run from the same binary using
the $CATALINA_BASE environment variable, then 	this classloader
repositories are relative to $CATALINA_BASE rather than $CATALINA_HOME. 
Ok.

2) 
By default, org/apache/catalina/startup/CatalinaProperties.java looks
for catalina.properties in CATALINA_HOME.  Since the user might want to
customize a CATALINA_BASE directory, shouldn't it look in CATALINA_BASE?
No, it's global (and defines where the binaries are).

3)
According to org/apache/catalina/startup/CatalinaProperties.java, the
location of catalina.properties can be specified via the catalina.config
option.  Shouldn't that be documented in the catalina.properties file?
I don't know if this works (it looks like it would, though).

Rémy



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

DO NOT REPLY [Bug 25279] - Tomcat don't write java out or err logs

[bugzilla]

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

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

Tomcat don't write java out or err logs





--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 13:27 ---

That is correct behavior (at least until the procrun2 gets working).
Procrun (tomcat.exe) can write to stderr/stdout files only for
redirected console apps (java.exe).
Using java.exe is btw 'preffered' way of launching tomcat.

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

DO NOT REPLY [Bug 23745] - "jsp.error.unterminated.tag" received when doing struts tags - improve error messages for misbuilt tags!

[bugzilla]

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

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

"jsp.error.unterminated.tag" received when doing struts tags - improve error messages 
for misbuilt tags!

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 13:26 ---
so, if you want to get this fixed and have eclipse, use
http://sourceforge.net/projects/lomboz/ and as per
http://www.objectlearn.com/support/docs/debuggingJSP.jsp this may help (you also
need http://www.sysdeo.com/eclipse/tomcatPlugin.html -->
http://www.sysdeo.com/eclipse/jasperDebugPatchV4.1.24.zip)

not fixing the root cause creates an entire industry  ;)

it could be so much easier!

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

Tomcat 5.0.16 catalina.properties

[Marx, Mitchell E (Mitch), ALABS]

1)
There seem to be 2 different catalina.properties:

jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\conf\cata
lina.properties
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/li
b/*.jar
- this winds up in CATALINA_HOME/conf, but when the binary
tarball is expanded, the permissions are 600.  So, in my case the file
does not get read

jakarta-tomcat-5.0.16-src\jakarta-tomcat-catalina\catalina\src\share\org
\apache\catalina\startup\catalina.properties
shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/li
b/*.jar
- this winds up inside bootstrap.jar.  Note this version says
catalina.home, instead of catalina.base.

According to
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html
the second file is incorrect.

If multiple Tomcat instances are run from the same binary using
the $CATALINA_BASE environment variable, then   this classloader
repositories are relative to $CATALINA_BASE rather than $CATALINA_HOME. 

2) 
By default, org/apache/catalina/startup/CatalinaProperties.java looks
for catalina.properties in CATALINA_HOME.  Since the user might want to
customize a CATALINA_BASE directory, shouldn't it look in CATALINA_BASE?

3)
According to org/apache/catalina/startup/CatalinaProperties.java, the
location of catalina.properties can be specified via the catalina.config
option.  Shouldn't that be documented in the catalina.properties file?

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

DO NOT REPLY [Bug 25241] - jsp:getProperty tag prints "null" if property is null.

[bugzilla]

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

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

jsp:getProperty  tag prints "null" if property is null.





--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 10:06 ---
Sorry, I think there was a misunderstanding: the spec is clear that "null"
should be printed out, so we won't include a feature which violates the spec. So
no patch will be accepted.

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

DO NOT REPLY [Bug 25279] - Tomcat don't write java out or err logs

[bugzilla]

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

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

Tomcat don't write java out or err logs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 10:05 ---
You're supposed to use "-Java java".
Please don't attempt to use the service wrapper outside of the installer,
nothing is documented (or well tested) at the moment.

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

DO NOT REPLY [Bug 25279] New: - Tomcat don't write java out or err logs

[bugzilla]

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

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

Tomcat don't write java out or err logs

   Summary: Tomcat don't write java out or err logs
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I install tomcat as a service (Windows 2K)
with --Java 
tomcat dosn't write java output or error files. The log file is locked, but the 
size of this file is always zero. 
When i change --Java to java (not jvm.dll)
all works fine.

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

DO NOT REPLY [Bug 25055] - getRemoteUser() returns null - bypass of apache authentication

[bugzilla]

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

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

getRemoteUser() returns null - bypass of apache authentication





--- Additional Comments From [EMAIL PROTECTED]  2003-12-08 08:28 ---
Ben, I did this already. 
The issue is that that using a .htaccess file does not protect tomcat served
requests (*.jsp). It bypasses apache and does not ask for a login/password.

I see this in apache 2.047 + tomcat 4.1.29 (both windows and linux) whereas
apache 1.3.29 +  tomcat 4.1.24 worked fine
I do not know if this a tomcat or an apache issue. I'm going to write an email
to tomcat-user to see if anyone else experiences this problem.

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