DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context

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

can't retrieve external context who's uri is a sub-dir of current context

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Catalina|Servlet & JSP API



--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 12:41 ---
The "/" is added to avoid matching stuff like:
Context name: "/foo"
Uri: "/foobar"

I still think the spec is bad, and should modify to specify that the desired
context path should be matched exactly.
BTW, there's a Watchdog test about this (unfortunately). I wonder why, since the
API Javadocs are quite unclear.

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

DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context

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

can't retrieve external context who's uri is a sub-dir of current context





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 13:18 ---
Agreed, we need to add "/" to the end, but that goes for the incoming URI as 
well. We also need to treat the ROOT context differently. I agree the specs 
are bad, but we need to solve this with what we got, since the getContext() 
method as it currently stands isn't useful.

---
--- ApplicationContext.java-2002-10-21  Mon Sep 23 11:23:16 2002
+++ ApplicationContext.java Wed Oct 23 14:08:41 2002
@@ -439,12 +439,25 @@
 return (null);

 // Return the current context if requested
-String contextPath = context.getPath();
-if (!contextPath.endsWith("/"))
-contextPath = contextPath + "/";
-if ((contextPath.length() > 0) && (uri.startsWith(contextPath))) {
-return (this);
-}
+   String contextPath = context.getPath();
+   if ( contextPath.equals( "" ) ) {
+ if ( uri.equals( "/" ) ) {
+   return (this);
+ }
+   } else {
+ String compareUri = uri;
+ if ( !uri.endsWith( "/" ) ) {
+   compareUri = compareUri+"/";
+ }
+ if ( !contextPath.endsWith( "/" ) ) {
+   contextPath = contextPath+"/";
+ }
+ if ( compareUri.startsWith( contextPath ) ) {
+   return (this);
+ }
+   }
+
+   System.out.println( context.getCrossContext() );

 // Return other contexts only if allowed
 if (!context.getCrossContext())
---

Martin Algesten

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

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

[remm]

remm2002/10/23 07:13:46

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Update changelog for 4.1.13.
  
  Revision  ChangesPath
  1.24  +107 -1jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- RELEASE-NOTES-4.1.txt 8 Oct 2002 07:58:23 -   1.23
  +++ RELEASE-NOTES-4.1.txt 23 Oct 2002 14:13:45 -  1.24
  @@ -453,6 +453,92 @@
JDBCStore:
Fix NPE on shutdown.
   
  +[4.1.13] StandardContext:
  + Major refactoring of the resources lifecycle handling, which is now 
  + similar to the one of the other components.
  +
  +[4.1.13] #12985
  + StandardWrapper:
  + Fix load on startup bug for JSPs.
  +
  +[4.1.13] StandardWrapper:
  + Add log swallowing support.
  +
  +[4.1.13] InvokerServlet:
  + SECURITY: Check the classname of the invoked servlet.
  +
  +[4.1.13] #13513
  + StandardManager:
  + Add disabling persistence with a blank String.
  +
  +[4.1.13] Catalina:
  + SECURITY: Add security manager protection on Coyote components.
  +
  +[4.1.13] ErrorReportValve:
  + Performance optimization: don't generate a status report for status 
  + codes < 400.
  +
  +[4.1.13] ProxyDirContext:
  + Cache non existing resources list to provide a major speedup for 
  + welcome files processing.
  +
  +[4.1.13] ProxyDirContext:
  + Avoid object creation when reproting a not found resource.
  +
  +[4.1.13] ProxyDirContext:
  + Peformance fix: allow directory caching.
  +
  +
  +
  +Coyote Bug Fixes:
  +
  +
  +[4.1.13] #12998
  + CoyoteAdapter:
  + Fix compatibility problem with AJP.
  +
  +[4.1.13] #13162
  + CoyoteAdapter:
  + Decode the URI as a URI, not as a query-string.
  +
  +[4.1.13] #13658
  + CoyoteAdapter:
  + Arrange to have the SSL attributes in the CoyoteRequest so that they 
  + show up for getAttributeNames.
  +
  +[4.1.13] CoyoteConnector:
  + Allow disabling proxyName with an empty string.
  +
  +[4.1.13] CoyoteInputStream:
  + Implement available().
  +
  +[4.1.13] CoyoteResponse:
  + Fix sendRedirect URL generation.
  +
  +[4.1.13] HTTP/1.1 Constants:
  + Increase max HTTP header buffer size to 48K.
  +
  +[4.1.13] HTTP/1.1 Http11Processor:
  + Performance: Save on B2C for host name handling.
  +
  +[4.1.13] HTTP/1.1 Http11Processor:
  + Performance: Use bytes comparisons to check the "connection" header
  + values.
  +
  +[4.1.13] HTTP/1.1 InternalOutputBuffer:
  + Performance: improve header generation.
  +
  +[4.1.13] #13270
  + JK2 ChannelSocket:
  + TCP no delay was not implemented.
  +
  +[4.1.13] JK2 HandlerRequest:
  + Fix tomcatAuthentication support.
  +
  +[4.1.13] #11657
  + JK2 JkMain:
  + Initialize https URLs if only JK connector is used.
  +
   
   
   Jasper Bug Fixes:
  @@ -625,6 +711,26 @@
   
   [4.1.12] JspRuntimeContext:
Add permission to allow reading the work directory.
  +
  +[4.1.13] #13144
  + Generator:
  + Ending comment eats up line following.
  +
  +[4.1.13] #13536
  + Generator:
  + Bad  value in plugin if the value is an expression.
  +
  +[4.1.13] JspRuntimeContext:
  + Make sure the CodeSource for JSP pages is created consistently 
  + the same.
  +
  +[4.1.13] #13206
  + JspRuntimeLibrary:
  + Invalid java bean property error message could be reported better.
  +
  +[4.1.13] #13843
  + JspServlet:
  + Fix locking on Windows of big JSP files.
   
   
   
  
  
  

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

[JK2] RedHat 8.0 JNI totaly bogus

[Mladen Turk]

Hi,

Using JNI on RH8 using either original 2.0.40, Henri's 2.0.43-1.7.2 or
build from sources (either prefork or worker).
Even tried 2.0.1 rpm, but on all config when trying to use the [vm:] I'm
having constant child_init, with cpu at 99%.
ErrorLog is growing and seems that entire thing faults at vm_init
(vm_default at 445 is the last thing logged).
Nothing is passed after the loading of jvm, like the child process
exits, but pool cleanup doesn't report that.
After stopping httpd, a few childs are reported as 'still did not exit'.

I've put some extra ap_logs and the child pids are growing even when set
StartServers to 1.
The Java is 1.4.0_01 

Any clues?
MT.



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

DO NOT REPLY [Bug 13884] New: - getRealPath() returns null in JBoss3.0.3-Tomcat4.1.12

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

getRealPath() returns null in JBoss3.0.3-Tomcat4.1.12

   Summary: getRealPath() returns null in JBoss3.0.3-Tomcat4.1.12
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


getRealPath() returns null in Tomcat 4.1.12. I have already posted this on 
JBoss forum. From what I learn from JBoss people is that the bug is in Tomcat 
4.1.12.

Sandeep

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

DO NOT REPLY [Bug 13884] - getRealPath() returns null in JBoss3.0.3-Tomcat4.1.12

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

getRealPath() returns null in JBoss3.0.3-Tomcat4.1.12





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 15:43 ---
Are you sure your war file is expended under JBoss. If no (meaning your war file
is never expected, then that's the normal behaviour). Try it with 4.1.12 by
setting unpackWars="false".

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

DO NOT REPLY [Bug 13887] New: - /manager/undeploy fails

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

/manager/undeploy fails

   Summary: /manager/undeploy fails
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Sun
OS/Version: Netware
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat server starts up okay.
# cat $CATALINA_HOME/logs/catalina.out
[INFO] Registry - -Loading registry information
[INFO] Registry - -Creating new Registry instance
[INFO] Registry - -Creating MBeanServer
[INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 8080
Starting service Tomcat-Standalone
Apache Tomcat/4.1.12
[INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 8080
[INFO] ChannelSocket - -JK2: ajp13 listening on tcp port 8009
[INFO] JkMain - -Jk running ID=0 time=18/75  config=/usr/local/jakarta-tomcat-
4.1.12/conf/jk2.properties

This is the display of applications before installing ours.
http://localhost:8080/manager/list

OK - Listed applications for virtual host localhost
/examples:running:0:examples
/webdav:running:0:/opt/jakarta-tomcat-4.1.12/webapps/webdav
/tomcat-docs:running:0:/opt/jakarta-tomcat-4.1.12/webapps/tomcat-docs
/admin:running:0:../server/webapps/admin
/manager:running:0:../server/webapps/manager
/:running:1:/opt/jakarta-tomcat-4.1.12/webapps/ROOT

Installing one of our applications which works on Tomcat 4.0.x and Tomcat 4.1.12

http://localhost:8080/manager/install?
path=/epe&war=jar:file:/opt/epe/epe/epe.war!/

OK - Installed application at context path /epe

This is the display of applications after installing ours.
http://localhost:8080/manager/list

OK - Listed applications for virtual host localhost
/examples:running:0:examples
/webdav:running:0:/opt/jakarta-tomcat-4.1.12/webapps/webdav
/epe:running:0:/opt/epe/epe/epe.war
/tomcat-docs:running:0:/opt/jakarta-tomcat-4.1.12/webapps/tomcat-docs
/admin:running:0:../server/webapps/admin
/manager:running:0:../server/webapps/manager
/:running:1:/opt/jakarta-tomcat-4.1.12/webapps/ROOT

Testing the application as follows works
http://localhost:8080/epe

This is the display of applications after running ours.
http://localhost:8080/manager/list

OK - Listed applications for virtual host localhost
/examples:running:0:examples
/webdav:running:0:/opt/jakarta-tomcat-4.1.12/webapps/webdav
/epe:running:1:/opt/epe/epe/epe.war
/tomcat-docs:running:0:/opt/jakarta-tomcat-4.1.12/webapps/tomcat-docs
/admin:running:0:../server/webapps/admin
/manager:running:0:../server/webapps/manager
/:running:1:/opt/jakarta-tomcat-4.1.12/webapps/ROOT

The problem is when we try to undeploy it.
http://localhost:8080/manager/undeploy?path=/epe

FAIL - Cannot remove document base for path /epe

Looking at the Tomcat directory

# ls -l /usr/local/jakarta-tomcat-4.1.12/work/Standalone/localhost
total 14
drwxr-xr-x   2 jakarta  ctron512 Oct 23 11:44 _
drwxr-xr-x   2 jakarta  ctron512 Oct 23 11:43 admin
drwxr-xr-x   3 jakarta  ctron512 Oct 23 12:03 epe
drwxr-xr-x   2 jakarta  ctron512 Oct 23 11:43 examples
drwxr-xr-x   2 jakarta  ctron512 Oct 23 11:43 manager
drwxr-xr-x   2 jakarta  ctron512 Oct 23 11:44 tomcat-docs
drwxr-xr-x   2 jakarta  ctron512 Oct 23 11:44 webdav

You can see the 'epe' subdirectory is there but is not be deployed, i.e. 
removed.

Doing the following works correctly:
http://localhost:8080/manager/stop?path=/epe
http://localhost:8080/manager/remove?path=/epe

But the following fails:
http://localhost:8080/manager/undeploy?path=/epe

Thanks
Robert Wolf, 416-848-4790 x3 M-F 10:00am - 4:00pm EST

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

DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid  in servlet 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=13014

OS/390/USS - Invalid   in servlet mapping





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 16:19 ---
Hi everybody

The same problem you described exists on 4.0.6 ,so
I fixed the bugs and now I have the TOMCAT 4.0.6 operating
perfectly on OS/390 2.10 .
If you are interested in this version ,I can send you a binary package
produced for OS/390.
On TOMCAT 4.12 the problem exists too,and I could solve the ascii-ebcdic
issues but  another problems appear with finding some class files.


Thanks 
Ali Madani
Email : [EMAIL PROTECTED]

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

DO NOT REPLY [Bug 13887] - /manager/undeploy fails

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

/manager/undeploy fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Critical|Normal
 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 16:25 ---
undeploy is the contrary of deploy.
remove of install.
I suppose this would need to be clarified or refactored to be more intuitive,
but this is expected behavior.

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

DO NOT REPLY [Bug 13893] New: - /manager/install ... add a /manager/uninstall

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

/manager/install ... add a /manager/uninstall

   Summary: /manager/install ... add a /manager/uninstall
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The command /manager/install ... works.

It would be nice to have a new command /manager/uninstall that does:
- /manager/stop
- /manager/remove
- rm -rf $CATALINA_HOME/work/Standalone/localhost/???

Also add the 'uninstall' to the gui application 'Tomcat Web Application Server'.

Currently there are potentially four hyperlinks beside each application:
 START STOP RELOAD REMOVE

Nice to have five hyperlinks beside each application:
 START STOP RELOAD REMOVE UNINSTALL

Also add to the documentation pages about this new 'uninstall' command.
There also seems to be some confusion about the 'deploy' and 'undeploy'.
More explanation in the documentation should clear this up.

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

Servlet Mapping xss Bug

[Orlando]

Hi,
I'm not sure if this is the correct list to post to so.. apologies ahead of 
time.

When testing for this vulnerability Bugtraq id 5193, via a request such as
http://target/servlet/org.apache.catalina.ContainerServlet/alert("css-test")

A " javax.servlet.ServletException: ..." is generated; is this part of the 
vulnerability, or is this normal?
Would it be feasable to treat any host returning this exception along with the 
alert() message vulnerable to this cross site scripting bug?

thanks, 
please CC me, I'm not subscribed to this list.

-orlando
http://www.g0thead.com/xbud.asc

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

DO NOT REPLY [Bug 13894] New: - The 'Install' button on Tomcat Web Application Server fails

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

The 'Install' button on Tomcat Web Application Server fails

   Summary: The 'Install' button on Tomcat Web Application Server
fails
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The command url:
http://localhost:8080/manager/install?
path=/foo&war=jar:file:/absolute_path/foo.war!/

The questions is how to do the same with the 'Tomcat Web Application Server'.

For example if you do the following it fails:
- type into the 'Path'field  /foo
- type into the 'War URL' field  jar:file:/absolute_path/foo.war!/
click on 'Install' button

It generates the following error:
Message: FAIL - Encountered exception java.net.MalformedURLException: no 
protocol: 

It would be nice to be able to have a GUI version of the /manager/install ...

Also adding a 'help' button onto this web page that will bring up
a page of documentation with examples to using this Tomcat Web Application 
Manager.

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

Re: [JK2] RedHat 8.0 JNI totaly bogus

[Costin Manolache]

Mladen Turk wrote:

> Hi,
> 
> Using JNI on RH8 using either original 2.0.40, Henri's 2.0.43-1.7.2 or
> build from sources (either prefork or worker).
> Even tried 2.0.1 rpm, but on all config when trying to use the [vm:] I'm
> having constant child_init, with cpu at 99%.
> ErrorLog is growing and seems that entire thing faults at vm_init
> (vm_default at 445 is the last thing logged).
> Nothing is passed after the loading of jvm, like the child process
> exits, but pool cleanup doesn't report that.
> After stopping httpd, a few childs are reported as 'still did not exit'.
> 
> I've put some extra ap_logs and the child pids are growing even when set
> StartServers to 1.
> The Java is 1.4.0_01

I think they just released 1.4.1 - and I remember reading in the release
notes about a jni fix that seems related.

I had few other problems with 1.4.0 and jni - for example I wasn't
able to load the libjk.so ( java loading the C lib, not the reverse ).
It did work after I removed the 'endorsed' libs flags - I have no ideea why.

Right now 1.3 is much more stable for JNI stuff ( IMO ) - I hope 1.4.1
will solve those problems.

-- 
Costin



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

DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid  in servlet 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=13014

OS/390/USS - Invalid   in servlet mapping





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 17:57 ---
Ali,
What a great news ! Is it possible to ftp the binary directly from your web 
site ?

Joseph Tan

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

RE: [JK2] RedHat 8.0 JNI totaly bogus

[Mladen Turk]

> From: Costin Manolache
>>
> > Using JNI on RH8 using either original 2.0.40, Henri's 
> 2.0.43-1.7.2 or 
> > build from sources (either prefork or worker). Even tried 
> 2.0.1 rpm, 
> > but on all config when trying to use the [vm:] I'm having constant 
> > child_init, with cpu at 99%. ErrorLog is growing and seems 
> that entire 
> > thing faults at vm_init (vm_default at 445 is the last 
> thing logged).
> > Nothing is passed after the loading of jvm, like the child process
> > exits, but pool cleanup doesn't report that.
> > After stopping httpd, a few childs are reported as 'still 
> did not exit'.
> > 
> > I've put some extra ap_logs and the child pids are growing 
> even when 
> > set StartServers to 1. The Java is 1.4.0_01
> 
> I think they just released 1.4.1 - and I remember reading in 
> the release notes about a jni fix that seems related.
> 
> I had few other problems with 1.4.0 and jni - for example I 
> wasn't able to load the libjk.so ( java loading the C lib, 
> not the reverse ). It did work after I removed the 'endorsed' 
> libs flags - I have no ideea why.
> 
> Right now 1.3 is much more stable for JNI stuff ( IMO ) - I 
> hope 1.4.1 will solve those problems.
> 

Will try both.

MT.



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

Upload - out of memory

[Moises Bezerra Menezes]

Hi,

I am having problems trying to configure TOMCAT 3.3 to work with IIS 4.0, via 
isapi_redirect.dll
When I am doing an upload of a file larger than 100Mbytes I get an 'out of memory' 
error.
I already tried to set the parameters cmd_line= -Xmx256m -Xss64k to the file 
wrapper.properties.
If I ran TOMCAT stand alone (without IIS integration) it works fine, but when it is 
under IIS I receive the 'out of 
memory' error.
The server is a NT-40 - Service Pack 6, with 198 Mbytes Ram memory and 300 Mbytes of 
Virtual Memory.
It seems that when it is under IIS it is ignoring the memory parameters -Xmx256m 
-Xss64k.
Is there any other configuration that I am missing ?

thanks


Moisés B. Menezes


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

Re: 4.0.7 release?

[Jon Scott Stevens]

on 2002/10/23 1:11 AM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:

> Jon Scott Stevens wrote:
> 
>> Can I get a 4.0.7 release? It has an important configuration bug fix
>> that I
>> need for Scarab.
> 
> There has been zero changes to the 4.0.x branch since 4.0.6 got released.
> 
> Remy

Ok, I guess it went into HEAD. I didn't realize that 4.0.x was on the branch
now.

A fix was done with regards to proxyName/proxyPort configuration in the HEAD
branch (based on a bug I reported) and I would love to see it make it into
4.0.x since Scarab still uses that because of XML parser issues when using
JDK 1.3.x.

So, if I backport the single fix, will you do a release? =)

-jon

-- 
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/


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

RE: [JK2] RedHat 8.0 JNI totaly bogus

[Brzezinski, Paul J]

*PLEASE* Post your results!!!


--
mailto:Paul.Brzezinski@;EDS.com
Enterprise Distributed Capabilities
EDS Corporation
248-265-8283


: -Original Message-
: From: Mladen Turk [mailto:mturk@;mappingsoft.com] 
: Sent: Wednesday, October 23, 2002 2:01 PM
: To: 'Tomcat Developers List'
: Subject: RE: [JK2] RedHat 8.0 JNI totaly bogus
: 
: 
: 
: 
: > From: Costin Manolache
: >>
: > > Using JNI on RH8 using either original 2.0.40, Henri's
: > 2.0.43-1.7.2 or
: > > build from sources (either prefork or worker). Even tried
: > 2.0.1 rpm,
: > > but on all config when trying to use the [vm:] I'm having constant
: > > child_init, with cpu at 99%. ErrorLog is growing and seems 
: > that entire
: > > thing faults at vm_init (vm_default at 445 is the last
: > thing logged).
: > > Nothing is passed after the loading of jvm, like the 
: child process 
: > > exits, but pool cleanup doesn't report that. After 
: stopping httpd, a 
: > > few childs are reported as 'still
: > did not exit'.
: > > 
: > > I've put some extra ap_logs and the child pids are growing
: > even when
: > > set StartServers to 1. The Java is 1.4.0_01
: > 
: > I think they just released 1.4.1 - and I remember reading in
: > the release notes about a jni fix that seems related.
: > 
: > I had few other problems with 1.4.0 and jni - for example I
: > wasn't able to load the libjk.so ( java loading the C lib, 
: > not the reverse ). It did work after I removed the 'endorsed' 
: > libs flags - I have no ideea why.
: > 
: > Right now 1.3 is much more stable for JNI stuff ( IMO ) - I
: > hope 1.4.1 will solve those problems.
: > 
: 
: Will try both.
: 
: MT.
: 
: 
: 
: --
: To unsubscribe, e-mail:   
: 
: For 
: additional commands, 
: e-mail: 
: 

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

Re: 4.0.7 release?

[Bill Barker]

- Original Message -
From: "Jon Scott Stevens" <[EMAIL PROTECTED]>
To: "tomcat-dev" <[EMAIL PROTECTED]>
Sent: Wednesday, October 23, 2002 11:15 AM
Subject: Re: 4.0.7 release?


> on 2002/10/23 1:11 AM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote:
>
> > Jon Scott Stevens wrote:
> >
> >> Can I get a 4.0.7 release? It has an important configuration bug fix
> >> that I
> >> need for Scarab.
> >
> > There has been zero changes to the 4.0.x branch since 4.0.6 got
released.
> >
> > Remy
>
> Ok, I guess it went into HEAD. I didn't realize that 4.0.x was on the
branch
> now.
>
> A fix was done with regards to proxyName/proxyPort configuration in the
HEAD
> branch (based on a bug I reported) and I would love to see it make it into
> 4.0.x since Scarab still uses that because of XML parser issues when using
> JDK 1.3.x.
>
> So, if I backport the single fix, will you do a release? =)

Actually, Coyote isn't branched ATM, so there's nothing to backport.

>
> -jon
>
> --
> StudioZ.tv /\ Bar/Nightclub/Entertainment
> 314 11th Street @ Folsom /\ San Francisco
> http://studioz.tv/
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

Security Check in Classloader.

[Jean-Francois Arcand]

Hi,

In StandardClassLoader, starting line 815, the SecurityManager is invoked:

   // (.5) Permission to access this class when using a SecurityManager
   if (securityManager != null) {
   int i = name.lastIndexOf('.');
   if (i >= 0) {
   try {
   securityManager.checkPackageAccess(name.substring(0,i));
   } catch (SecurityException se) {
   String error = "Security Violation, attempt to use " +
   "Restricted Class: " + name;
   System.out.println(error);
   se.printStackTrace();
   log(error);
   throw new ClassNotFoundException(error);
   }
   }
   }

Why are we calling the SecurityManager.checkPackageAccess 
in StandardClassLoader? Since we give all permissions to 
org.apache.catalina, I think this call is useless. This call is required 
when invoked inside WebappClassLoader.

Thanks,

-- Jeanfrancois


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

DO NOT REPLY [Bug 13533] - JSPs compiled inconsistently

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

JSPs compiled inconsistently





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 19:26 ---
Judging from the nonsensical error messages from javac, I suspect this problem
is due to the fact that JDK javac is not MT-safe.  Jasper 1 uses a deprecated
javac interface that is MT-safe; but it has other problems.

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

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

[luehe]

luehe   2002/10/23 12:26:37

  Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Log:
  Fixed Bugtraq 4767492: NPE generated by JSP page translator if custom
  tag uses undefined attribute
  
  Revision  ChangesPath
  1.47  +6 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- Validator.java21 Oct 2002 20:13:32 -  1.46
  +++ Validator.java23 Oct 2002 19:26:36 -  1.47
  @@ -679,7 +679,7 @@
Hashtable tagDataAttrs = new Hashtable(attrs.getLength());
for (int i=0; i@ -748,7 +748,7 @@
  true);
} else {
err.jspError(n, "jsp.error.bad_attribute",
  -  attrs.getQName(i));
  +  attrs.getQName(i), n.getShortName());
}
}
}
  @@ -776,7 +776,7 @@
= new Node.JspAttribute(na, true);
} else {
err.jspError(n, "jsp.error.bad_attribute",
  -  na.getName());
  +  na.getName(), n.getShortName());
}
}
}
  
  
  
  1.48  +2 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- messages.properties   17 Oct 2002 22:56:02 -  1.47
  +++ messages.properties   23 Oct 2002 19:26:37 -  1.48
  @@ -150,7 +150,7 @@
   jsp.message.compiling_with=Compiling with: {0}
   jsp.message.template_text=template text
   jsp.error.missing_attribute=According to the TLD attribute {0} is mandatory for tag 
{1}
  -jsp.error.bad_attribute=Attribute {0} invalid according to the specified TLD
  +jsp.error.bad_attribute=Attribute {0} invalid for tag {1} according to TLD
   jsp.error.tld_not_found=Could not locate TLD {0}
   jsp.error.webxml_not_found=Could not locate web.xml
   jsp.cmd_line.usage=Usage: jsptoservlet [-o ] 
[-keepgenerated] \
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets CGIServlet.java

[amyroh]

amyroh  2002/10/23 12:57:31

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java StandardContext.java
StandardContextMapper.java
   catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
  Log:
  Reduced visibility of fields/methods where appropriate.
  
  Revision  ChangesPath
  1.4   +61 -62
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
  
  Index: ApplicationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ApplicationContext.java   9 Oct 2002 08:01:11 -   1.3
  +++ ApplicationContext.java   23 Oct 2002 19:57:30 -  1.4
  @@ -333,32 +333,6 @@
   
   
   /**
  - * Clear all application-created attributes.
  - */
  -public void clearAttributes() {
  -
  -// Create list of attributes to be removed
  -ArrayList list = new ArrayList();
  -synchronized (attributes) {
  -Iterator iter = attributes.keySet().iterator();
  -while (iter.hasNext()) {
  -list.add(iter.next());
  -}
  -}
  -
  -// Remove application originated attributes
  -// (read only attributes will be left in place)
  -Iterator keys = list.iterator();
  -while (keys.hasNext()) {
  -String key = (String) keys.next();
  -removeAttribute(key);
  -}
  -
  -
  -}
  -
  -
  -/**
* Return the resources object that is mapped to a specified path.
* The path must begin with a "/" and is interpreted as relative to the
* current context root.
  @@ -370,19 +344,6 @@
   }
   
   
  -/**
  - * Set an attribute as read only.
  - */
  -public void setAttributeReadOnly(String name) {
  -
  -synchronized (attributes) {
  -if (attributes.containsKey(name))
  -readOnlyAttributes.put(name, name);
  -}
  -
  -}
  -
  -
   // - ServletContext Methods
   
   
  @@ -997,6 +958,31 @@
   
   
   /**
  + * Clear all application-created attributes.
  + */
  +void clearAttributes() {
  +
  +// Create list of attributes to be removed
  +ArrayList list = new ArrayList();
  +synchronized (attributes) {
  +Iterator iter = attributes.keySet().iterator();
  +while (iter.hasNext()) {
  +list.add(iter.next());
  +}
  +}
  +
  +// Remove application originated attributes
  +// (read only attributes will be left in place)
  +Iterator keys = list.iterator();
  +while (keys.hasNext()) {
  +String key = (String) keys.next();
  +removeAttribute(key);
  +}
  +
  +}
  +
  +
  +/**
* Return the facade associated with this ApplicationContext.
*/
   ServletContext getFacade() {
  @@ -1006,6 +992,19 @@
   }
   
   
  +/**
  + * Set an attribute as read only.
  + */
  +void setAttributeReadOnly(String name) {
  +
  +synchronized (attributes) {
  +if (attributes.containsKey(name))
  +readOnlyAttributes.put(name, name);
  +}
  +
  +}
  +
  +
   //  Private Methods
   
   
  @@ -1020,26 +1019,26 @@
*/
   private String normalize(String path) {
   
  - String normalized = path;
  +String normalized = path;
   
  - // Normalize the slashes and add leading slash if necessary
  - if (normalized.indexOf('\\') >= 0)
  - normalized = normalized.replace('\\', '/');
  -
  - // Resolve occurrences of "/../" in the normalized path
  - while (true) {
  - int index = normalized.indexOf("/../");
  - if (index < 0)
  - break;
  - if (index == 0)
  - return (null);  // Trying to go outside our context
  - int index2 = normalized.lastIndexOf('/', index - 1);
  - normalized = normalized.substring(0, index2) +
  - normalized.substring(index + 3);
  - }
  +// Normalize the slashes and add leading slash if necessary
  +if (normalized.indexOf('\\') >= 0)
  +normalized = normalized.replace('\\', '/');
  +
  +// Resolve occurrences of "/../" in the normalized path
  +while (true) {
  +int index = normalized.indexOf("/../");
  +if (index < 0)
  +break;
  +if (index == 0)
  +return (null);  // Trying to go outside our context
  +int index2 = normalized.lastIndexOf('/', i

DO NOT REPLY [Bug 13907] New: - security manager does not give read permission on a context by default

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

security manager does not give read permission on a context by default

   Summary: security manager does not give read permission on a
context by default
   Product: Tomcat 4
   Version: 4.1.12
  Platform: Other
OS/Version: FreeBSD
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Under 4.0.3 with the default catalina.policy and -security, JSPs in each context have 
read access to files in that context. Under 4.1.12 this behaviour seems to be broken.

A test.jsp fails under 4.1.12 with the following error when run with the security 
manager:

org.apache.jasper.JasperException: access denied (java.io.FilePermission 
/usr/local/tomcat/webapps/examples/test2.new read)

the following is the content of the test JSP:

<%
String fullPath = pageContext.getServletContext().getRealPath("/test2.new");
out.println("Path: " + fullPath);
java.io.File foo = new java.io.File(fullPath);
if (foo.exists())
out.println("Exists: " + fullPath);
else {
out.println("does not exist");
}

%>

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

DO NOT REPLY [Bug 13908] New: - Odd configuration behavior when used with BEA JRockit VM

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

Odd configuration behavior when used with BEA JRockit VM

   Summary: Odd configuration behavior when used with BEA JRockit VM
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I began experimenting with using BEA JRockit VM (v7.0, sdk version 1.4.0). At 
first all seemed well. I was able to deploy and run applications through the 
Ant tasks. Then I restarted the Tomcat instance. It would not restart and 
logged the following error to logs/stdout.txt and logs/stderr.txt:
 BEGIN
Catalina.start: java.lang.IllegalAccessException: Class 
org.apache.commons.digester.ObjectCreateRule can not access a member of class 
org.apache.catalina.core.StandardContextValve with modifiers ""
java.lang.IllegalAccessException: Class 
org.apache.commons.digester.ObjectCreateRule can not access a member of class 
org.apache.catalina.core.StandardContextValve with modifiers ""
at org.apache.commons.digester.Digester.createSAXException
(Ljava.lang.String;Ljava.lang.Exception;)Lorg.xml.sax.SAXException;(Unknown 
Source)
at org.apache.commons.digester.Digester.createSAXException
(Ljava.lang.Exception;)Lorg.xml.sax.SAXException;(Unknown Source)
at org.apache.commons.digester.Digester.startElement
(Ljava.lang.String;Ljava.lang.String;Ljava.lang.String;Lorg.xml.sax.Attributes;)
V(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.startElement
(Lorg.apache.xerces.xni.QName;Lorg.apache.xerces.xni.XMLAttributes;Lorg.apache.x
erces.xni.Augmentations;)V(Unknown Source)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement
(Lorg.apache.xerces.xni.QName;Lorg.apache.xerces.xni.XMLAttributes;Lorg.apache.x
erces.xni.Augmentations;)V(Unknown Source)
at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement
(Lorg.apache.xerces.xni.QName;Lorg.apache.xerces.xni.XMLAttributes;Lorg.apache.x
erces.xni.Augmentations;)V(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement
(Lorg.apache.xerces.xni.QName;Lorg.apache.xerces.xni.XMLAttributes;Lorg.apache.x
erces.xni.Augmentations;)V(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement()Z
(Unknown Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(Z)Z(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Z)
Z(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Z)Z(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse
(Lorg.apache.xerces.xni.parser.XMLInputSource;)V(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse
(Lorg.apache.xerces.xni.parser.XMLInputSource;)V(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse
(Lorg.xml.sax.InputSource;)V(Unknown Source)
at org.apache.commons.digester.Digester.parse(Lorg.xml.sax.InputSource;)
Ljava.lang.Object;(Unknown Source)
at org.apache.catalina.startup.Catalina.start()V(Unknown Source)
at org.apache.catalina.startup.Catalina.execute()V(Unknown Source)
at org.apache.catalina.startup.Catalina.process([Ljava.lang.String;)V
(Unknown Source)
at COM.jrockit.reflect.NativeMethodInvoker.invoke0(ILjava.lang.Object;
[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at COM.jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;
[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at COM.jrockit.reflect.VirtualNativeMethodInvoker.invoke
(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
at java.lang.reflect.Method.invoke(Ljava.lang.Object;
[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
at org.apache.catalina.startup.Bootstrap.main([Ljava.lang.String;)V
(Unknown Source)
 END

I found this very odd since I have been working with this version of Tomcat for 
some time with the Sun JVM(1.4.0) and never experienced this. Upon further 
inspection, I found that when the manager or admin application saves the 
server.xml it differs substantially between the two VMs and this was the cause 
of the problem. When saved under JRockit, it adds a lot of extra listeners and 
valves to the file that are not present when run with the SUN VM. Consequently, 
the next time the system starts, it fails because these extra definitions throw

DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context

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

can't retrieve external context who's uri is a sub-dir of current context





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 21:07 ---
ok, from the servlet 2.3 spec:

-
getContext(String)
  public ServletContext getContext(java.lang.String uripath) 

Returns a ServletContext object that corresponds to a specified URL on the
server.
This method allows servlets to gain access to the context for various 
parts of
the server, and as needed obtain RequestDispatcher objects from the 
context.
The given path must be begin with “/”, is interpreted relative to the
server’s document root and is matched against the context roots of other 
web
applications hosted on this container.
In a security conscious environment, the servlet container may return null
for a given URL.

Parameters:
uripath - a String specifying the context path of another web application 
in
the container.

Returns: the ServletContext object that corresponds to the named URL, or
null if either none exists or the container wishes to restrict this access.
-


There doesn't appear to be anything in here at all suggesting that when you 
call getContext(String) with a parameter specifying a uri which is a sub-dir 
of the current context's uri, it should ignore your request and simply return 
the current context.

I also beleive that the following assumption is incorrect: "In the general 
case, '/store/common' is supposed to return context '/store' if
it exists.".
 
  The spec states that the given path is "matched" against the context roots 
of other web apps.  That implies to me that it must match exactly.

The solutions provided here do not address this bug: "can't retrieve external 
context who's uri is a sub-dir of current context".  Each of them actually 
still has the same problem (except for the initial postings attachment).


Here's a solution, with minimal changes, that fixes this bug:


-
445c445
< if ((contextPath.length() > 0) && (uri.startsWith(contextPath))) {
---
> if ((contextPath.length() > 1) && (uri.equals(contextPath))) {
-


Ryan Smith

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

DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default

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

security manager does not give read permission on a context by default

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 21:20 ---
That's the proper behaviour. You need to grant your app in catalina.policy file:


// The permissions granted to the context WEB-INF/classes directory
 grant codeBase "file:${catalina.home}/webapps/examples/-" {
  permission java.io.FilePermission "<>, "read";
 };

Look at your catalina.policy file :-)

-- Jeanfrancois

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

DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default

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

security manager does not give read permission on a context by default

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 21:31 ---
uh, according to the comments in catalina.policy (in two different places) and the 
behaviour in 4.0.3 (and I see no change in either the comments or the release notes 
about this changing in 4.1.12) the security manager is supposed to give read 
permissions on the webapp to each context. So is there documentation missing or is 
it a bug?:

// == WEB APPLICATION PERMISSIONS 
=


// These permissions are granted by default to all web applications
// In addition, a web application will be given a read FilePermission
// and JndiPermission for all files and directories in its document root.


// This file contains a default set of security policies to be enforced (by the
// JVM) when Catalina is executed with the "-security" option.  In addition
// to the permissions granted here, the following additional permissions are
// granted to the codebase specific to each web application:
//
// * Read access to the document root directory

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

DO NOT REPLY [Bug 13907] - security manager does not give read permission on a context by default

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

security manager does not give read permission on a context by default





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 21:43 ---
You are correct.  The behavior should be for the container to programmatically 
grant a file read permission for a context's codebase in the context's docBase 
directory (and all subdirectories).  You do not need to explicitly grant the 
each app a file read permission explicitly, unless you need to read outside of 
the docBase directory.  I can confirm that Tomcat 4.0.2b1 - 4.0.5 behaves this 
way, and I believe 4.1.x is supposed to.  If not, it's a bug.

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

Re: Security Check in Classloader.

[Jean-Francois Arcand]

Foget that email. The problem is in front of the computer, not in the 
class ;-)
-- Jeanfrancois

Jean-Francois Arcand wrote:

Hi,

In StandardClassLoader, starting line 815, the SecurityManager is 
invoked:

   // (.5) Permission to access this class when using a 
SecurityManager
   if (securityManager != null) {
   int i = name.lastIndexOf('.');
   if (i >= 0) {
   try {
   
securityManager.checkPackageAccess(name.substring(0,i));
   } catch (SecurityException se) {
   String error = "Security Violation, attempt to use " +
   "Restricted Class: " + name;
   System.out.println(error);
   se.printStackTrace();
   log(error);
   throw new ClassNotFoundException(error);
   }
   }
   }

Why are we calling the SecurityManager.checkPackageAccess in 
StandardClassLoader? Since we give all permissions to 
org.apache.catalina, I think this call is useless. This call is 
required when invoked inside WebappClassLoader.

Thanks,

-- Jeanfrancois


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java CatalinaService.java

[jfarcand]

jfarcand2002/10/23 19:42:03

  Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
CatalinaService.java
  Log:
  Wrongly recommend to protect o.a.coyote from package.access. The package can only be 
protection agains insertion.
  
  Revision  ChangesPath
  1.51  +6 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
  
  Index: Catalina.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- Catalina.java 16 Oct 2002 00:43:51 -  1.50
  +++ Catalina.java 24 Oct 2002 02:42:03 -  1.51
  @@ -485,7 +485,7 @@
   access = "sun.,";
   Security.setProperty("package.access",
   access + 
  -
"org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.tomcat.");
  +"org.apache.catalina.,org.apache.jasper.");
   String definition = Security.getProperty("package.definition");
   if( definition != null && definition.length() > 0 )
   definition += ",";
  @@ -495,7 +495,7 @@
   // FIX ME package "javax." was removed to prevent HotSpot
   // fatal internal errors
   definition + 
  -
"java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.tomcat.");
  +"java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.");
   }
   
   // Replace System.out and System.err with a custom PrintStream
  
  
  
  1.10  +6 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/CatalinaService.java
  
  Index: CatalinaService.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- CatalinaService.java  16 Oct 2002 00:43:52 -  1.9
  +++ CatalinaService.java  24 Oct 2002 02:42:03 -  1.10
  @@ -217,7 +217,7 @@
   access = "sun.,";
   Security.setProperty("package.access",
   access +
  -   
"org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.tomcat.");
  +   "org.apache.catalina.,org.apache.jasper.");
   String definition = Security.getProperty("package.definition");
   if( definition != null && definition.length() > 0 )
   definition += ",";
  @@ -227,7 +227,7 @@
   // FIX ME package "javax." was removed to prevent HotSpot
   // fatal internal errors
   definition +
  -
"java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.tomcat.");
  +"java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.");
   }
   
   // Start the new server
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityConfig.java

[jfarcand]

jfarcand2002/10/23 19:43:20

  Modified:catalina/src/share/org/apache/catalina/security
SecurityConfig.java
  Log:
  Wrongly recommend to protect o.a.coyote from package.access. The package can only be 
protection agai
  ns insertion.
  
  Revision  ChangesPath
  1.3   +8 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java
  
  Index: SecurityConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- SecurityConfig.java   16 Oct 2002 22:04:16 -  1.2
  +++ SecurityConfig.java   24 Oct 2002 02:43:20 -  1.3
  @@ -71,11 +71,15 @@
   
   private final static String PACKAGE_ACCESS =  "org.apache.catalina." 
   + ",org.apache.jasper."
  ++ ",org.apache.jsp."
  ++ ",org.apache.jk.";
  +
  +private final static String PACKAGE_DEFINITION= "java."
  ++ ",org.apache.catalina." 
  ++ ",org.apache.jasper."
   + ",org.apache.coyote."
  -+ ",org.apache.tomcat."
  -+ ".org.apache.jk.";
  -private final static String PACKAGE_DEFINITION= "java.,"
  -+ PACKAGE_ACCESS;
  ++ ",org.apache.jsp."
  ++ ",org.apache.jk.";
   /**
* Create a single instance of this class.
*/
  
  
  

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

DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped

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

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 07:36 ---
I don't really want to further spam the discussion, but I'd just like it noted
that after removing the examples webapp from my Tomcat, I've not experienced any
problems any more. I DO use log4j, maybe a slightly older version, but I still
do use it. I have not experienced any CL errors any more.

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

cvs commit: jakarta-tomcat-connectors/jk/support jk_pcre.m4

[mturk]

mturk   2002/10/23 00:58:46

  Modified:jk/support jk_pcre.m4
  Log:
  The preprocessor flag is HAS_PCRE not HAVE_PCRE.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-tomcat-connectors/jk/support/jk_pcre.m4
  
  Index: jk_pcre.m4
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_pcre.m4,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- jk_pcre.m422 Oct 2002 19:40:27 -  1.1
  +++ jk_pcre.m423 Oct 2002 07:58:46 -  1.2
  @@ -71,7 +71,7 @@
  esac
   
if ${TEST} ${use_pcre} ; then
  -   HAVE_PCRE="-DHAVE_PCRE"
  +   HAS_PCRE="-DHAS_PCRE"
  PCRE_LIBS="-lpcre -lpcreposix"
fi
 ])
  
  
  

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

Re: 4.0.7 release?

[Remy Maucherat]

Jon Scott Stevens wrote:


Can I get a 4.0.7 release? It has an important configuration bug fix 
that I
need for Scarab.

There has been zero changes to the 4.0.x branch since 4.0.6 got released.

Remy


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

DO NOT REPLY [Bug 13533] - JSPs compiled inconsistently

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

JSPs compiled inconsistently





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 08:33 ---
We have redeployed the webapp still using Tomcat 4.1.12 but with Jasper 1 
instead of Jasper 2. This now works ok, could this be a genuine bug in Jasper 2 
or is more likely to be a corrupt installation/setup issue?

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

DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context

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

can't retrieve external context who's uri is a sub-dir of current context





--- Additional Comments From [EMAIL PROTECTED]  2002-10-23 10:08 ---
The bit of code we're talking about is there in order to always allow for 
getting the current context, even if crossContext="false" (god knows why 
anyone would like to get the current context like that, but allowing it surely 
doesn't hurt).

I don't understand why we are adding on a trailing "/" in case the contextPath 
doesn't have one. That seems wrong to me since it would require the caller to 
say "/store/" in order to trigger the optimisation. The incoming uri we need 
to handle could be on the forms (have I missed anyone?):
"/"
"/store"
"/store/"
"/store/common"
"/store/common/even/more"

The context paths can be on the forms (again, correct me if I'm wrong):
""
"/store"

It seems we would need to treat the ROOT context differently to the rest of 
them. A propose for the fix would then be:

--
--- ApplicationContext.java-2002-10-21  Mon Sep 23 11:23:16 2002
+++ ApplicationContext.java Wed Oct 23 10:54:51 2002
@@ -439,13 +439,16 @@
 return (null);

 // Return the current context if requested
-String contextPath = context.getPath();
-if (!contextPath.endsWith("/"))
-contextPath = contextPath + "/";
-if ((contextPath.length() > 0) && (uri.startsWith(contextPath))) {
-return (this);
-}
-
+   if ( context.getPath().equals( "" ) ) {
+ if ( uri.equals( "/" ) ) {
+   return (this);
+ }
+   } else {
+ if ( uri.startsWith( context.getPath() ) ) {
+   return (this);
+ }
+   }
+
 // Return other contexts only if allowed
 if (!context.getCrossContext())
 return (null);
--


I've tested this with the following JSP code:
<%
  ServletContext ctx = getServletContext();
  System.out.println( "/: "+ctx.getContext( "/" ) );
  System.out.println( "/publisher: "+ctx.getContext( "/publisher" ) );
  System.out.println( "/publisher/: "+ctx.getContext( "/publisher/" ) );
  System.out.println( "/publisher/protected: "+ctx.getContext
( "/publisher/protected" ) );
  System.out.println( "/publisher/protected/: "+ctx.getContext
( "/publisher/protected/" ) );
%>

With crossContext="false".

Running the JSP in the ROOT context gives me:
/: org.apache.catalina.core.ApplicationContextFacade@a45a24
/publisher: null
/publisher/: null
/publisher/protected: null
/publisher/protected/: null

Running the JSP in the /publisher context gives me:
/: null
/publisher: org.apache.catalina.core.ApplicationContextFacade@15c6c8d
/publisher/: org.apache.catalina.core.ApplicationContextFacade@15c6c8d
/publisher/protected: org.apache.catalina.core.ApplicationContextFacade@15c6c8d
/publisher/protected/: 
org.apache.catalina.core.ApplicationContextFacade@15c6c8d

Martin Algesten

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

Re: Netbeans 3.4 with builtin Tomcat 4.0.1(problem with pathinfo)

[Radim Kubacki]

Ulrik Sannsell wrote:

Hello,

...

When i call it with http://localhost/servlet/my.servlet?param=1 it starts up
the correct servlet and everything seems fine. However when i try to add the
pathinfo to it as in http://localhost/servlet/my.servlet/some/path?param=1
it fails telling me that the requested resource
(/servlet/my.servlet/some/path) is not available.

Hope that someone can enlighten me on this problem as this is something i
cannot resolve.


Use your own servlet and servlet-mapping in web.xml that will map your 
servlet to these URIs. Now it just uses default mapping for servlets 
defined for whole Tomcat (which is BTW originally disabled in latest 
versions IIRC) that is not designed to do what you are trying.

Radim

Regards,

Ulrik Sannsell




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

jasper questions

[Costin Manolache]

I'm trying to understand the last part of the JSP execution - and 
how the buffer is flushed and closed.

Acording to javadocs, JspFactory.releasePageContext() should
be invoked, and that will call PageContext.release().

In release() javadoc: 

* This method shall "reset" the internal state of a PageContext, 
releasing
 * all internal references, and preparing the PageContext for potential
 * reuse by a later invocation of initialize(). This method is typically
 * called from JspFactory.releasePageContext().


There is no mention that this method will flush the buffers as 
side effect. At least that's my reading.

I think a more correct implementation would be to call 
out.flush()/out.close() explicitely and then call release().

The benefit would be that the connector will be able to 
automatically add Content-Length ( at least for small pages ), 
and that's usually good for performance or when talking with
certain clients. ( that's what coyote does for servlets - but
not for JSPs since flush() is called too early ).

-- 
Costin



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

DO NOT REPLY [Bug 13014] - OS/390/USS - Invalid  in servlet 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=13014

OS/390/USS - Invalid   in servlet mapping





--- Additional Comments From [EMAIL PROTECTED]  2002-10-24 06:50 ---
What is the procedure for distributing a fix as described by Seyed Ali Madani ?
The fix is for v4.0.6 but the problem is reported under v4.1.10.

And shouldn't the fixed binary be distributed from Apache's web site instead 
of distributing it personnaly ?

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