Interesting

[Jon Scott Stevens]

I wonder if one could use these techniques to hack a servlet engine somehow
and get from one context to another (assuming you had access to run servlets
in it...ie: shared hosting)...

http://www.javaspecialists.co.za/archive/Issue014.html

-jon


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

[GUMP] Build Failure - jakarta-tomcat-jk-ant

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml does not exist!
Build failed

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

[GUMP] Build Failure - jakarta-tomcat-catalina

[bobh]

This email is autogenerated from the output from:



Buildfile: build.xml

deploy-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build

deploy-static:

deploy-catalina:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo] 

Error

[Eugeny N Dzhurinsky]

what is it?

Apache Tomcat 4.0.6
JDK 1.3.1_p7
FreeBSD 4.7


   "HttpProcessor[2002][2]" (TID:0x28e54540, sys_thread_t:0x83f2a80,
state:CW) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:420)
at
org.apache.catalina.connector.http.HttpProcessor.await(HttpProcessor.java:378)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1119)
at java.lang.Thread.run(Thread.java:484)
"HttpProcessor[2002][1]" (TID:0x28e55798, sys_thread_t:0x83f2880,
state:CW) prio=5
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at
org.apache.catalina.connector.http.SocketInputStream.fill(SocketInputStream.java:593)
at
org.apache.catalina.connector.http.SocketInputStream.read(SocketInputStream.java:530)
at
org.apache.catalina.connector.http.SocketInputStream.readRequestLine(SocketInputStream.java:199)
at
org.apache.catalina.connector.http.HttpProcessor.parseRequest(HttpProcessor.java:710)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:974)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125)
at java.lang.Thread.run(Thread.java:484)
"HttpProcessor[2002][0]" (TID:0x28e5a778, sys_thread_t:0x83f2680,
state:CW) prio=5
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:420)
at
org.apache.catalina.connector.http.HttpProcessor.await(HttpProcessor.java:378)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1119)
at java.lang.Thread.run(Thread.java:484)
"HttpConnector[2002]" (TID:0x28e8, sys_thread_t:0x8704280,
state:CW) prio=5
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:421)
at java.net.ServerSocket.implAccept(ServerSocket.java:243)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at
org.apache.catalina.connector.http.HttpConnector.run(HttpConnector.java:993)
at java.lang.Thread.run(Thread.java:484)
"Finalizer" (TID:0x28e79528, sys_thread_t:0x80d0280, state:CW) prio=8
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:108)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:123)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:162)
"Reference Handler" (TID:0x28e79300, sys_thread_t:0x8094680, state:CW)
prio=10
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:420)
at
java.lang.ref.Reference$ReferenceHandler.run(Reference.java:110)
"Signal dispatcher" (TID:0x28e79330, sys_thread_t:0x8094480, state:CW)
prio=5
"main" (TID:0x28e791b0, sys_thread_t:0x804f280, state:CW) prio=5
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:421)
at java.net.ServerSocket.implAccept(ServerSocket.java:243)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at
org.apache.catalina.core.StandardServer.await(StandardServer.java:293)
at org.apache.catalina.startup.Catalina.start(Catalina.java:794)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)
Monitor Cache Dump:
java.lang.Class@28DB0040/293C7A30: owner "HttpProcessor[2002][3]"
(0x83f2c80) 2 entries
ua.marka.Billing.util.db.BillDbConnector@28CCE3E0/29EC7538: owner
"HttpProcessor[2002][3]" (0x83f2c80) 1 entry
java.net.PlainSocketImpl@28E523D8/2901B570: owner "main" (0x804f280) 1
entry
org.apache.catalina.connector.http.HttpProcessor@28EA5688/29025848:

Waiting to be notified:
"HttpProcessor[2002][0]" (0x83f2680)
java.lang.ref.ReferenceQueue$Lock@28E79540/28EAF460: 
Waiting to be notified:
"Finalizer" (0x80d0280)
java.net.PlainSocketImpl@28E75BF8/28FA1788: owner
"HttpConnector[2002]" (0x8704280) 1 entry
java.lang.ref.Reference$Lock@28E79310/28EAEF80: 
Waiting to be notified:
"Reference Handler" (0x8094680)
org.apache.catalina.connector.http.HttpProcessor@28E55708/29055C68:

Waiting to be notified:
"HttpProcessor[2002][2]" (0x83f2a80)
Registered Monitor Dump:
utf8 hash table: 
JNI pinning lock: 
JNI global reference lock: 
BinClass lock: 
Class linking lock: 
System class loader lock: 
Code rewrite lock: 
Heap lock: 
Monitor cache lock: owner "Thread-7" (0x8c3a080) 1 entry
Dynamic loading lock: 
Monitor IO lock: 
User signal monitor: 
W

DO NOT REPLY [Bug 9931] - Base64 decoder chokes on a whitespace: FASTER?

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

Base64 decoder chokes on a whitespace: FASTER?





--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 09:55 ---

I've got some timing info for the small base64 test case, and for a largish
(864k) data file.

The inline method was consistently superior in both cases. Given this, I'm not
sure that slowing up the tests warrants a large test case, or bulking up the
tree, although it might be nice to keep around somehow ... I'm still working how
to run single junit testcases conveniently from the command line (if you do want
large tests, I do have some code for this).

Typical figures for the large sample on my machine are: 125/147/517 (ms.,
min/mean/max) versus 124/237/601 for the old method (average of 1000 calls to
encode). These are the *least* favourable figures (fastest old/slowest new) from
four runs of each. Typically inlining seemed to almost halve the speed. With the
small sample, .015 vs .019 was average (total ms. for 1000 calls to encode).

A few other points:

1) my patch doesn't terminate the output in a newline, unless it ends on a chunk
boundary by chance. The perl base64 encoder seems to do this, and the RFC
implies it, so it probably is the way to go. It should be easy, but make sure
you don't add two newlines by mistake. Let me know if you'd like a patch for this.

BTW, Base64Test.assertEquals(byte[] a, byte[] b) seems to be broken - it only
compares the arrays up to a.length, and doesn't check that they have the same size.

2) decode is *slow*. In my timings, decoding the large file took three or four
times as long as encoding, probably due to the Vectors. It should be a lot
faster to brute force copy all non-whitespace chars into a new array, and then
resize this at the end, if inlining is too tricky.

I nearly jumped at this one, but then I searched for Base64 on search.apache.org

There seem to be dozens instances of this code out there, a few of which may
have inlined whitespace stripping (e.g. in tomcat, maybe), but most of which
seem to have come from the same original codebase. Isn't this exactly what 
commons is for?

I guess that leaves the question, should xmlrpc patch and pass stuff up to
commons, or should xmlrpc start using the commons classes.

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

FW: JMX : Questions

[Thierry Legrain]

 

 

-Original Message-
From: Thierry Legrain 
Sent: Monday, January 27, 2003 11:36 AM
To: '[EMAIL PROTECTED]'
Cc: Thierry Legrain
Subject: JMX : Questions

 

I have realized a generic MBeanBrowser and I want to test it with TomCat.

 

How to connect MBeanServer with an external program?

Can I implement "my connector" to manage Tomcat?

How to write web app which handle MBeanServer?

Can I use JNDI lookup to manipulate MBeanServer (and HOW)?

 

Thanks.

Thierry.

DO NOT REPLY [Bug 16449] New: - Race condition when compiling jsp pages

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

Race condition when compiling jsp pages

   Summary: Race condition when compiling jsp pages
   Product: Tomcat 4
   Version: 4.1.19
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There is a race condition when compiling jsp pages, the cause of this race 
condition is the use of the Double-Checked idiom.

For more information on why the Double-Checked idiom does NOT work
please read the following
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Thanks,

John Trollinger

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

DO NOT REPLY [Bug 16449] - Race condition when compiling jsp pages

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

Race condition when compiling jsp pages





--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 12:09 ---
Created an attachment (id=4561)
patch for o.a.j.servlet.JspServletWrapper.java

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

Re: Interesting

[Costin Manolache]

Jon Scott Stevens wrote:

I wonder if one could use these techniques to hack a servlet engine somehow
and get from one context to another (assuming you had access to run servlets
in it...ie: shared hosting)...

http://www.javaspecialists.co.za/archive/Issue014.html

-jon


Interesting - but it won't work if the security manager is enabled.
If the security manager is disabled ( as it is in 99% of the cases ) - 
there is no protection at all, if you can run servlets - you can do
anything a C program can. Just load a JNI library and then control the 
VM at the low level, and access/modify anything that tomcat user can.

It may be a good idea if 5.0 would have the secure mode as default.
Users will complain their apps won't work and tomcat will be a bit
slower -  but if this raises their awarness on security and maybe they
fix some of the webapps to work in the sandbox, then it's worth it.
Restoring the current mode can be easy - like adding a "-insecure"
option or some TOMCAT_INSECURE env :-)

The sandbox is IMHO the biggest benefit of Java over all other
languages ( including .net - I know they have similar concept, but I 
don't think it matches the JVM ).

Costin



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

Cleanup of javax.servlet.context.tempdir

[Shapira, Yoav]

Howdy,
So tomcat provides a temporary directory per-cotnext accessible via
javax.servlet.context.tempdir per the 2.3 Servlet Specification.  No
problem there.

I don't think the spec (including the 2.4 PFD version) says anything
about cleaning up the temporary directory.  Does tomcat provide any
mechanisms for administrative cleanup (e.g. via the manager app) of the
temporary directories?  Does tomcat provide any mechanism, e.g. a
configuration parameter on the  tag, for automatic cleanup of
the temporary directory when the context is shut down?  Does anyone
think these things would be useful?

My current scenario is a webapp that needs to write temporary files
(intermediate things in large scientific calculations) to disk.  I write
them to the context temporary directory.  One part of the cronjob that
periodically (weekly) restarts tomcat cleans up the tempdir.  This works
fine, but I'm wondering if there's a better way.

Any ideas, opinions, etc. will be appreciated.  If people think it's
useful, I could write and contribute some code to implement one or more
of the above in tomcat 4.1.x / 5.x.  Thanks,

Yoav Shapira
Millennium ChemInformatics



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

Re: Interesting

[Jeanfrancois Arcand]

Costin Manolache wrote:


Jon Scott Stevens wrote:


I wonder if one could use these techniques to hack a servlet engine 
somehow
and get from one context to another (assuming you had access to run 
servlets
in it...ie: shared hosting)...

http://www.javaspecialists.co.za/archive/Issue014.html

-jon


Interesting - but it won't work if the security manager is enabled.
If the security manager is disabled ( as it is in 99% of the cases ) - 
there is no protection at all, if you can run servlets - you can do
anything a C program can. Just load a JNI library and then control the 
VM at the low level, and access/modify anything that tomcat user can.

It may be a good idea if 5.0 would have the secure mode as default.
Users will complain their apps won't work and tomcat will be a bit
slower -  but if this raises their awarness on security and maybe they
fix some of the webapps to work in the sandbox, then it's worth it.
Restoring the current mode can be easy - like adding a "-insecure"
option or some TOMCAT_INSECURE env :-) 

+1  And I'm sure that for the majority of Tomcat user, the performance 
hit will not be so high.

-- Jeanfrancois



The sandbox is IMHO the biggest benefit of Java over all other
languages ( including .net - I know they have similar concept, but I 
don't think it matches the JVM ).




Costin



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threadsThreadPool.java ThreadPoolMX.java

[Costin Manolache]

FYI: I did the same in the main branch. All of DynamicMBean features are
now porte to modeler. There is no need for JMX dependency in jtc/util
( the branch is still needed in coyote, jk, http11 )

Costin



[EMAIL PROTECTED] wrote:

billbarker2003/01/24 20:49:24

  Modified:util/java/org/apache/tomcat/util/threads Tag: coyote_10
ThreadPool.java
  Removed: util/java/org/apache/tomcat/util/threads Tag: coyote_10
ThreadPoolMX.java
  Log:
  Removing JMX dependencies from this branch (as voted on in tomcat-dev).
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.9.2.1   +0 -9  jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.9
  retrieving revision 1.9.2.1
  diff -u -r1.9 -r1.9.2.1
  --- ThreadPool.java	14 Jan 2003 18:47:39 -	1.9
  +++ ThreadPool.java	25 Jan 2003 04:49:24 -	1.9.2.1
  @@ -159,15 +159,6 @@
*   call register() in order to set a name.
*/
   public static ThreadPool createThreadPool(boolean jmx) {
  -if( jmx ) {
  -try {
  -Class.forName( "org.apache.commons.modeler.Registry");
  -Class tpc=Class.forName( "org.apache.tomcat.util.threads.ThreadPoolMX");
  -ThreadPool res=(ThreadPool)tpc.newInstance();
  -return res;
  -} catch( Exception ex ) {
  -}
  -}
   return new ThreadPool();
   }




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

Re: Interesting

[Glenn Nielsen]

Jeanfrancois Arcand wrote:



Costin Manolache wrote:


Jon Scott Stevens wrote:


I wonder if one could use these techniques to hack a servlet engine 
somehow
and get from one context to another (assuming you had access to run 
servlets
in it...ie: shared hosting)...

http://www.javaspecialists.co.za/archive/Issue014.html

-jon



Interesting - but it won't work if the security manager is enabled.
If the security manager is disabled ( as it is in 99% of the cases ) - 
there is no protection at all, if you can run servlets - you can do
anything a C program can. Just load a JNI library and then control the 
VM at the low level, and access/modify anything that tomcat user can.

It may be a good idea if 5.0 would have the secure mode as default.
Users will complain their apps won't work and tomcat will be a bit
slower -  but if this raises their awarness on security and maybe they
fix some of the webapps to work in the sandbox, then it's worth it.
Restoring the current mode can be easy - like adding a "-insecure"
option or some TOMCAT_INSECURE env :-) 


+1  And I'm sure that for the majority of Tomcat user, the performance 
hit will not be so high.

-- Jeanfrancois


+1 In my testing I found that the SecurityManager added 7% overhead.
For me security is well worth the 7%.




The sandbox is IMHO the biggest benefit of Java over all other
languages ( including .net - I know they have similar concept, but I 
don't think it matches the JVM ).



Hear, hear.  That is what got me involved with Tomcat.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


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

Re: Cleanup of javax.servlet.context.tempdir

[Glenn Nielsen]

As of Tomcat 4.1.19 the manager will remove the tempdir when you
/remove a web application.

In your case I would add some code to a servlet init method to cleanup
the old temporary files. Then configure the servlet to load on startup.

I would not want the manager to muck around with the tempdir of an
installed web application.  There are many things that can get saved
in the tempdir.  JSP .java and .class files, serialized session data,
etc.  I think it is best if the code which generates temp files in the
tempdir manages its own files.

Regards,

Glenn

Shapira, Yoav wrote:

Howdy,
So tomcat provides a temporary directory per-cotnext accessible via
javax.servlet.context.tempdir per the 2.3 Servlet Specification.  No
problem there.

I don't think the spec (including the 2.4 PFD version) says anything
about cleaning up the temporary directory.  Does tomcat provide any
mechanisms for administrative cleanup (e.g. via the manager app) of the
temporary directories?  Does tomcat provide any mechanism, e.g. a
configuration parameter on the  tag, for automatic cleanup of
the temporary directory when the context is shut down?  Does anyone
think these things would be useful?

My current scenario is a webapp that needs to write temporary files
(intermediate things in large scientific calculations) to disk.  I write
them to the context temporary directory.  One part of the cronjob that
periodically (weekly) restarts tomcat cleans up the tempdir.  This works
fine, but I'm wondering if there's a better way.

Any ideas, opinions, etc. will be appreciated.  If people think it's
useful, I could write and contribute some code to implement one or more
of the above in tomcat 4.1.x / 5.x.  Thanks,

Yoav Shapira
Millennium ChemInformatics



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

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

[jfarcand]

jfarcand2003/01/27 09:35:28

  Modified:.build.xml build.properties.default
  Log:
  Add support for cvs tag when using the checkout target.
  
  Revision  ChangesPath
  1.71  +2 -1  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.70
  retrieving revision 1.71
  diff -u -r1.70 -r1.71
  --- build.xml 23 Jan 2003 02:52:47 -  1.70
  +++ build.xml 27 Jan 2003 17:35:28 -  1.71
  @@ -1069,9 +1069,10 @@
   
 
   
  -
  +
   
   
  
  
  
  1.59  +2 -2  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.58
  retrieving revision 1.59
  diff -u -r1.58 -r1.59
  --- build.properties.default  23 Jan 2003 02:51:27 -  1.58
  +++ build.properties.default  27 Jan 2003 17:35:28 -  1.59
  @@ -33,7 +33,7 @@
   
   # - CVS root for the jakarta repositories --
   cvsroot=":pserver:[EMAIL PROTECTED]:/home/cvspublic"
  -
  +cvstag=""
   
   # - Default Base Path for Dependent Packages -
   #base.path=/usr/share/java
  
  
  

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

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

[jfarcand]

jfarcand2003/01/27 10:05:10

  Modified:.build.xml build.properties.default
  Log:
  Default download to the HEAD target.
  
  Revision  ChangesPath
  1.72  +5 -5  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.71
  retrieving revision 1.72
  diff -u -r1.71 -r1.72
  --- build.xml 27 Jan 2003 17:35:28 -  1.71
  +++ build.xml 27 Jan 2003 18:05:10 -  1.72
  @@ -1089,19 +1089,19 @@
 
   
   
   
   
   
 
   
  
  
  
  1.60  +2 -2  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.59
  retrieving revision 1.60
  diff -u -r1.59 -r1.60
  --- build.properties.default  27 Jan 2003 17:35:28 -  1.59
  +++ build.properties.default  27 Jan 2003 18:05:10 -  1.60
  @@ -33,7 +33,7 @@
   
   # - CVS root for the jakarta repositories --
   cvsroot=":pserver:[EMAIL PROTECTED]:/home/cvspublic"
  -cvstag=""
  +cvstag="HEAD"
   
   # - Default Base Path for Dependent Packages -
   #base.path=/usr/share/java
  
  
  

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

DO NOT REPLY [Bug 16449] - Race condition when compiling jsp pages

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

Race condition when compiling jsp pages

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 18:08 ---
The idea is that you do not care about those issues. I knew when I wrote the
code that it was not perfectly thread safe (it would if the check was on a
boolean, but unfortunately the boolean belongs to another object). I doubt you
can reproduce this bug in the real world, and if you can, it has very little
consequences, so it is not worth the performance impact.

I'm -1 for this patch.

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparser XMLEncodingDetector.java XercesEncodingDetector.java

[luehe]

luehe   2003/01/27 10:10:48

  Modified:jasper2/src/share/org/apache/jasper/compiler PageInfo.java
ParserController.java Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
   jasper2/src/share/org/apache/jasper/xmlparser
XMLEncodingDetector.java
XercesEncodingDetector.java
  Log:
  Fixed 16127 ("Seems to be a problem doing a static include of content
  when using a different charset.")
  
  In addition, the presence of an XML prolog no longer implies a JSP
  document, as it may actually be used with standard syntax to produce
  an XML-formatted result (in which case Jasper must treat the XML
  prolog as template text).
  
  Revision  ChangesPath
  1.17  +3 -18 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java
  
  Index: PageInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/PageInfo.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- PageInfo.java 8 Nov 2002 19:55:47 -   1.16
  +++ PageInfo.java 27 Jan 2003 18:10:47 -  1.17
  @@ -89,13 +89,6 @@
   private String errorPage = null;
   private String pageEncoding = null;
   
  -/*
  - * Auto-detected encoding, or encoding specified in XML prolog
  - * (declaration).
  - * Only meaningful for XML documents.
  - */
  -private String xmlPrologEncoding = null;
  -
   private int maxTagNesting = 0;
   private boolean scriptless = false;
   private boolean scriptingInvalid = false;
  @@ -233,14 +226,6 @@
return pageEncoding;
   }
   
  -public void setXmlPrologEncoding(String xmlPrologEncoding) {
  - this.xmlPrologEncoding = xmlPrologEncoding;
  -}
  -
  -public String getXmlPrologEncoding() {
  - return xmlPrologEncoding;
  -}
  -
   public int getMaxTagNesting() {
   return maxTagNesting;
   }
  
  
  
  1.30  +97 -54
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- ParserController.java 22 Jan 2003 20:08:24 -  1.29
  +++ ParserController.java 27 Jan 2003 18:10:47 -  1.30
  @@ -67,12 +67,10 @@
   /**
* Controller for the parsing of a JSP page.
* 
  - * A translation unit (JSP source file and any files included via the
  - * include directive) may involve the processing of JSP pages
  - * written with different syntaxes (currently the original JSP syntax,
  - * as well as the XML syntax (as of JSP 1.2)). This class encapsulates 
  - * the behavior related to the selection and invocation of 
  - * the proper parser.
  + * The same ParserController instance is used for a JSP page and any JSP
  + * segments included by it (via an include directive), where each segment may
  + * be provided in standard or XML syntax. This class selects and invokes the
  + * appropriate parser for the JSP page and its included segments.
*
* @author Pierre Delisle
* @author Jan Luehe
  @@ -110,6 +108,8 @@
*/
   private boolean isTopFile = true;
   
  +private String sourceEnc;
  +
   /*
* Constructor
*/
  @@ -196,9 +196,27 @@
   
// Figure out what type of JSP document and encoding type we are
// dealing with
  - String encoding = figureOutJspDocument(absFileName, jarFile);
  + figureOutJspDocument(absFileName, jarFile);
   
if (isTopFile) {
  + if (isXml) {
  + // Make sure the encoding determined from the XML prolog
  + // matches that in the JSP config element, if present
  + String jspConfigPageEnc = pageInfo.getPageEncoding();
  + if (jspConfigPageEnc != null
  + && !jspConfigPageEnc.equals(sourceEnc)) {
  + err.jspError("jsp.error.prolog_config_encoding_mismatch",
  +  sourceEnc, jspConfigPageEnc);
  + }
  + // override the encoding that may have been set from JSP config
  + // info (in Compiler.generateJava()), since that applies to
  + // standard syntax only
  + pageInfo.setPageEncoding(sourceEnc);
  + } else {
  + if (pageInfo.getPageEncoding() == null) {
  + pageInfo.setPageEncoding(sourceEnc);
  + }
  + }
pag

[4.1.20] Tagging soon ?

[Remy Maucherat]

I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as 
I think fixing the issue is important) tag a new 4.1.20 milestone within 
a few days.

Comments ?

Remy



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

[5.0] New mapper

[Remy Maucherat]

(This question is for Costin)

As I've mentioned before, I'm writing a new mapper to replace the 
current 5.0 request mapper, which is a major performance problem right now.

The implementation goes well enough (I'll likely commit something today 
or tomorrow; in the end, there are no fancy algorithms involved), but 
there's the problem of keeping the mapper structure in sync with 
Catalina's structure.

To do that, I was planning to use a simple MBean registration listener 
(as all the components we're interested in register with JMX) with the 
MBean server. (I can only see a way of doing that using JMX 1.2)

So, is it ok to do that ? Is there a better way (I don't want to use the 
Catalina listeners, obviously) ?

Remy



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

DO NOT REPLY [Bug 16127] - Seems to be a problem doing a static include of content when using a different charset.

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

Seems to be a problem doing a static include of content when using a different charset.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

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

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

[jfarcand]

jfarcand2003/01/27 10:18:21

  Modified:.build.properties.default
  Log:
  Do not use quote.
  
  Revision  ChangesPath
  1.61  +2 -2  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- build.properties.default  27 Jan 2003 18:05:10 -  1.60
  +++ build.properties.default  27 Jan 2003 18:18:21 -  1.61
  @@ -33,7 +33,7 @@
   
   # - CVS root for the jakarta repositories --
   cvsroot=":pserver:[EMAIL PROTECTED]:/home/cvspublic"
  -cvstag="HEAD"
  +cvstag=HEAD
   
   # - Default Base Path for Dependent Packages -
   #base.path=/usr/share/java
  
  
  

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

Re: using ajp (isapi_redirector2.dll) without tomcat

[James Chang]

I have downloaded apache binary dist and the ajp connector source, and
builded the IIS redirector (It was rather strange that apr.h is in apache
binary dist but not in the apache source release).

What I found with debug messages is,  HttpFilterProc() is called with I
request http://localhost/examples/x, which means the dll is installed
correctly and the configuration files are correct (mappings and etc).
However there is no line of code in HttpFilterProc() that actually calls
anything to open the socket and send data.  I checked several possible
functions to see if they are the ones who send data, but all turn out to be
some string manipulation functions.

Could someone tell me which function call in HttpFilterProc actaully result
in open socket to 8009 port?

Thanks

- Original Message -
From: "James Chang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 1:17 AM
Subject: using ajp (isapi_redirector2.dll) without tomcat


Hi:

I am trying to get ajp to work with other jsp/servlet engines other then
tomcat.   Right now I am working on IIS with isapi_redirector2.dll and
listening on port 8009 with my own ajp listener.  The problem is somehow the
dll never calls to port 8009 when I am accessing http://localhost/examples/*


I downloaded isapi_redirector2.dll from:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.
2/bin/win32/

I have set up the registry settings and use the simple works2.properties
file
as shown below.  IIS shows the dll is loaded correctly, but when I try to
request to
http://localhost/examples/x , the isapi_redirector2.dll doesn't send any
request to port 8009.

Could anyone tell me what is wrong with my configuration file?  Or is
the dll somehow need tomcat to work (I have set it to use socket, but maybe
the dll needs some configuration file or shared library from tomcat)??

Any pointer will be usefull.
Thanks!


the registry I used is:
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi
Redirector\2.0]
"serverRoot"="d:\\tm"
"extensionUri"="/jakarta/isapi_redirector2.dll"
"workersFile"="D:\\shared\\iisredir\\workers2.properties"
"authComplete"="0"
"threadPool"="5"

All strings are properly installed.


My workers2.properties file contains:

# Define the communication channel
[channel.socket:localhost:8009]
info=Ajp13 forwarding over socket
tomcatId=localhost:8009

# Map the Tomcat examples webapp to the Web server uri space
[uri:/examples/*]
info=Map the whole webapp

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config coyote.xml

[remm]

remm2003/01/27 10:31:57

  Modified:webapps/tomcat-docs/config coyote.xml
  Log:
  - Documentation update.
  
  Revision  ChangesPath
  1.5   +20 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/config/coyote.xml
  
  Index: coyote.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/coyote.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- coyote.xml12 Jan 2003 17:26:48 -  1.4
  +++ coyote.xml27 Jan 2003 18:31:56 -  1.5
  @@ -128,6 +128,18 @@
 2048 bytes will be provided.
   
   
  +
  +  The Connector may use HTTP/1.1 GZIP compression in
  +  an attempt to save server bandwidth. The acceptable values for the
  +  parameter is "off" (disable compression), "on" (allow compression, which
  +  causes text data to be compressed), "force" (forces compression in all
  +  cases), or a numerical integer value (which is equivalent to "on", but
  +  specifies the minimum amount of data before the output is compressed). If
  +  the content-length is not known and compression is set to "on" or more
  +  aggressive, the output will also be compressed. If not specified, this
  +  attribute is set to "false".
  +
  +
   
 The number of milliseconds this Connector will wait,
 after accepting a connection, for the request URI line to be
  @@ -138,6 +150,14 @@
 The debugging detail level of log messages generated by this
 component, with higher numbers creating more detailed output.
 If not specified, this attribute is set to zero (0).
  +
  +
  +
  +  This flag allows the servlet container to use a different, longer
  +  connection timeout while a servlet is being executed, which in the end
  +  allows either the servlet a longer amount of time to complete its
  +  execution, or a longer timeout during data upload. If not specified, 
  +  this attribute is set to "false".
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/docs/config coyote.xml

[remm]

remm2003/01/27 10:32:08

  Modified:webapps/docs/config coyote.xml
  Log:
  - Documentation update.
  
  Revision  ChangesPath
  1.3   +22 -2 jakarta-tomcat-catalina/webapps/docs/config/coyote.xml
  
  Index: coyote.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/coyote.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- coyote.xml15 Jan 2003 03:40:44 -  1.2
  +++ coyote.xml27 Jan 2003 18:32:08 -  1.3
  @@ -102,7 +102,7 @@
   
 The standard implementation of the Coyote HTTP/1.1 
 Connector is 
  -  org.apache.coyote.tomcat4.CoyoteConnector.
  +  org.apache.coyote.tomcat5.CoyoteConnector.
 It supports the following additional attributes (in addition to the
 common attributes listed above):
   
  @@ -128,6 +128,18 @@
 2048 bytes will be provided.
   
   
  +
  +  The Connector may use HTTP/1.1 GZIP compression in
  +  an attempt to save server bandwidth. The acceptable values for the
  +  parameter is "off" (disable compression), "on" (allow compression, which
  +  causes text data to be compressed), "force" (forces compression in all
  +  cases), or a numerical integer value (which is equivalent to "on", but
  +  specifies the minimum amount of data before the output is compressed). If
  +  the content-length is not known and compression is set to "on" or more
  +  aggressive, the output will also be compressed. If not specified, this
  +  attribute is set to "false".
  +
  +
   
 The number of milliseconds this Connector will wait,
 after accepting a connection, for the request URI line to be
  @@ -140,6 +152,14 @@
 If not specified, this attribute is set to zero (0).
   
   
  +
  +  This flag allows the servlet container to use a different, longer
  +  connection timeout while a servlet is being executed, which in the end
  +  allows either the servlet a longer amount of time to complete its
  +  execution, or a longer timeout during data upload. If not specified, 
  +  this attribute is set to "false".
  +
  +
   
 The maximum number of request processing threads to be created
 by this Connector, which therefore determines the
  @@ -269,7 +289,7 @@
   
 The fully qualified class name of the SSL server socket
 factory implementation class.  You must specify
  -  org.apache.coyote.tomcat4.CoyoteServerSocketFactory here.
  +  org.apache.coyote.tomcat5.CoyoteServerSocketFactory here.
 
   
   
  
  
  

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

DO NOT REPLY [Bug 16449] - Race condition when compiling jsp pages

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

Race condition when compiling jsp pages





--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 18:36 ---

The sad thing is, I can reproduce this in the real world (well atleast in our 
web app) and considering the that that sync is only called when a jsp page is 
being recompiled I don't see how it is a performance consern (although I could 
be wrong about when it is called)

So if I am write about the only on a compile / recompile thing I think it 
should be fixed as it will fix 2 bugs with my web app (1. being some weird fast 
click / javascript combo thing, the other the same jsp page being included on 
the same page more than once)

please think about it.

thanks,

john

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

Re: [4.1.20] Tagging soon ?

[Hans Bergsten]

Remy Maucherat wrote:

I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as 
I think fixing the issue is important) tag a new 4.1.20 milestone within 
a few days.

Comments ?

That would be great, but can you please apply the TagLibraryInfoImpl
patch from bug #14302 before you so? Without it, JspC fails for JSP
pages that use tag libraries with the TLD packaged in the JAR file.
This is the same problem as described by bugs #13212 and #14537.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


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

Re: [4.1.20] Tagging soon ?

[Glenn Nielsen]

I was planning on doing some research and testing of custom tag pooling options
(as we discussed last week) this week.  It would be nice if the results from
that could get into th 4.1.20 release.  Could be a nice performance improvement
for Jasper2.

Regards,

Glenn

Remy Maucherat wrote:

I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as 
I think fixing the issue is important) tag a new 4.1.20 milestone within 
a few days.

Comments ?

Remy



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 



--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


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

DO NOT REPLY [Bug 16449] - Race condition when compiling jsp pages

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

Race condition when compiling jsp pages





--- Additional Comments From [EMAIL PROTECTED]  2003-01-27 19:43 ---
Please apply the patch. I, for one, favor correctness over speed.

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

how to detect 'hanging' requests

[list]

hello!

i'm looking for a detection of 'hanging' or 'unable to finish' requests. 
e.g.: while(true) loops in a jsp. no one would program something like 
this but on a server with multiple applications it happens sometime that 
under some circumstances a infinite loop or a recoursive loop is 
created. the cpu utilization is then near 100% and the only solution is 
to restart the server 

is it possible to set something like:
- maximum execution time for a request
- maximum memory consumtion for a request (in case of recoursion the 
memory consumtion can be extreme high)

or to 'identify' these uggly peace of  code?

many thanx in advance,
joe


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

using ajp (isapi_redirector2.dll) without tomcat on IIS

[James Chang]

I have downloaded apache binary dist and the ajp connector source, and
builded the IIS redirector (It was rather strange that apr.h is in apache
binary dist but not in the apache source release).

What I found with debug messages is,  HttpFilterProc() is called with I
request http://localhost/examples/x, which means the dll is installed
correctly and the configuration files are correct (mappings and etc).
However there is no line of code in HttpFilterProc() that actually calls
anything to open the socket and send data.  I checked several possible
functions to see if they are the ones who send data, but all turn out to be
some string manipulation functions.

Could someone tell me which function call in HttpFilterProc actaully result
in open socket to 8009 port?

Thanks

- Original Message -
From: "James Chang" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 8:53 PM
Subject: using ajp without tomcat


> Hi:
>
> I am trying to get ajp to work for other jsp/servlet engines other
then
> tomcat.   Right now I am working on IIS with isapi_redirector2.dll and
> listening on port 8009 with my own ajp listener.
>
> I downloaded isapi_redirector2.dll from:
>
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.
> 2/bin/win32/
>
> set up the registry settings and use the simple works2.properties file
> below.  IIS shows the dll is loaded correctly, but when I try to request
to
> http://localhost/examples/x , the isapi_redirector2.dll doesn't send
any
> request to port 8009.
>
> Could anyone tell me what is wrong with my configuration file?  Or is
> the dll somehow need tomcat to work (I have set it to use socket, but
maybe
> the dll needs some configuration file or shared library from tomcat)??
>
> Any pointer will be usefull.
> Thanks!
>
>
> the registry I used is:
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi
> Redirector\2.0]
> "serverRoot"="d:\\tm"
> "extensionUri"="/jakarta/isapi_redirector2.dll"
> "workersFile"="D:\\shared\\iisredir\\workers2.properties"
> "authComplete"="0"
> "threadPool"="5"
>
> All strings are properly installed.
>
>
> My workers2.properties file contains:
>
> # Define the communication channel
> [channel.socket:localhost:8009]
> info=Ajp13 forwarding over socket
> tomcatId=localhost:8009

Trying to fix Gump

[Larry Isaacs]

I'm trying to get Gump working with respect to
jakarta-tomcat* projects.  I need to know which projects
are intended to be dependent on jakarta-tomcat-coyote_10.

Currently, jakarta-tomcat-coyote_10 project lists
tomcat-catalina as a dependent project, in addition to
jakarta-tomcat.  Is the coyote_10 branch intended for
use with any other jakarta-tomcat versions besides
3.3.x?  If somebody can save me the time of trying to
hunt this down from prior e-mails, I would appreciate it.
Thanks.

Larry






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

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java ThreadPoolMX.java

[Larry Isaacs]

Hi Costin,

jtc/util still contains org.apache.tomcat.util.mx.DynamicMBeanProxy
which imports "javax.management.*".  Is the intent to update or remove
this class so the dependency on JMX can be removed?  Thanks.

Cheers,
Larry

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 27, 2003 10:39 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
> eads ThreadPool.java ThreadPoolMX.java
> 
> 
> FYI: I did the same in the main branch. All of DynamicMBean 
> features are
> now porte to modeler. There is no need for JMX dependency in jtc/util
> ( the branch is still needed in coyote, jk, http11 )
> 
> Costin
> 
> 
> 
> [EMAIL PROTECTED] wrote:
> > billbarker2003/01/24 20:49:24
> > 
> >   Modified:util/java/org/apache/tomcat/util/threads 
> Tag: coyote_10
> > ThreadPool.java
> >   Removed: util/java/org/apache/tomcat/util/threads 
> Tag: coyote_10
> > ThreadPoolMX.java
> >   Log:
> >   Removing JMX dependencies from this branch (as voted on 
> in tomcat-dev).
> >   
> >   Revision  ChangesPath
> >   No   revision
> >   
> >   
> >   No   revision
> >   
> >   
> >   1.9.2.1   +0 -9  
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
> eads/ThreadPool.java
> >   
> >   Index: ThreadPool.java
> >   
> ===
> >   RCS file: 
> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomca
> t/util/threads/ThreadPool.java,v
> >   retrieving revision 1.9
> >   retrieving revision 1.9.2.1
> >   diff -u -r1.9 -r1.9.2.1
> >   --- ThreadPool.java   14 Jan 2003 18:47:39 -  1.9
> >   +++ ThreadPool.java   25 Jan 2003 04:49:24 -  1.9.2.1
> >   @@ -159,15 +159,6 @@
> > *   call register() in order to set a name.
> > */
> >public static ThreadPool createThreadPool(boolean jmx) {
> >   -if( jmx ) {
> >   -try {
> >   -Class.forName( 
> "org.apache.commons.modeler.Registry");
> >   -Class tpc=Class.forName( 
> "org.apache.tomcat.util.threads.ThreadPoolMX");
> >   -ThreadPool res=(ThreadPool)tpc.newInstance();
> >   -return res;
> >   -} catch( Exception ex ) {
> >   -}
> >   -}
> >return new ThreadPool();
> >}
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

Re: Cleanup of javax.servlet.context.tempdir

[Craig R. McClanahan]

On Mon, 27 Jan 2003, Glenn Nielsen wrote:

> Date: Mon, 27 Jan 2003 11:11:29 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Cleanup of javax.servlet.context.tempdir
>
> As of Tomcat 4.1.19 the manager will remove the tempdir when you
> /remove a web application.
>
> In your case I would add some code to a servlet init method to cleanup
> the old temporary files. Then configure the servlet to load on startup.
>

Or the contextDestroyed() method of a ServletContextListener.

> I would not want the manager to muck around with the tempdir of an
> installed web application.  There are many things that can get saved
> in the tempdir.  JSP .java and .class files, serialized session data,
> etc.  I think it is best if the code which generates temp files in the
> tempdir manages its own files.
>

+1.

> Regards,
>
> Glenn
>

Craig



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

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java ThreadPoolMX.java

[Costin Manolache]

Larry Isaacs wrote:

> Hi Costin,
> 
> jtc/util still contains org.apache.tomcat.util.mx.DynamicMBeanProxy
> which imports "javax.management.*".  Is the intent to update or remove
> this class so the dependency on JMX can be removed?  Thanks.

To deprecate - for sure, there is no point in maintaining it when the
same functionality is in modeler. I made quite a few improvements to
the equivalent code in modeler ( support for more types, automatic detection
of .xml descriptors, etc ).

About remove - I don't know if it was included in any official release,
and if removing it won't break code. I know of a use in 3.3, is anyone
else using it ? 

We definitely need a way to document what APIs are "FROZEN" 
( like mozilla ). 


Costin

> 
> Cheers,
> Larry
> 
>> -Original Message-
>> From: Costin Manolache [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, January 27, 2003 10:39 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: cvs commit:
>> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
>> eads ThreadPool.java ThreadPoolMX.java
>> 
>> 
>> FYI: I did the same in the main branch. All of DynamicMBean
>> features are
>> now porte to modeler. There is no need for JMX dependency in jtc/util
>> ( the branch is still needed in coyote, jk, http11 )
>> 
>> Costin
>> 
>> 
>> 
>> [EMAIL PROTECTED] wrote:
>> > billbarker2003/01/24 20:49:24
>> > 
>> >   Modified:util/java/org/apache/tomcat/util/threads
>> Tag: coyote_10
>> > ThreadPool.java
>> >   Removed: util/java/org/apache/tomcat/util/threads
>> Tag: coyote_10
>> > ThreadPoolMX.java
>> >   Log:
>> >   Removing JMX dependencies from this branch (as voted on
>> in tomcat-dev).
>> >   
>> >   Revision  ChangesPath
>> >   No   revision
>> >   
>> >   
>> >   No   revision
>> >   
>> >   
>> >   1.9.2.1   +0 -9
>> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
>> eads/ThreadPool.java
>> >   
>> >   Index: ThreadPool.java
>> >   
>> ===
>> >   RCS file:
>> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomca
>> t/util/threads/ThreadPool.java,v
>> >   retrieving revision 1.9
>> >   retrieving revision 1.9.2.1
>> >   diff -u -r1.9 -r1.9.2.1
>> >   --- ThreadPool.java  14 Jan 2003 18:47:39 -  1.9
>> >   +++ ThreadPool.java  25 Jan 2003 04:49:24 -  1.9.2.1
>> >   @@ -159,15 +159,6 @@
>> > *   call register() in order to set a name.
>> > */
>> >public static ThreadPool createThreadPool(boolean jmx) {
>> >   -if( jmx ) {
>> >   -try {
>> >   -Class.forName(
>> "org.apache.commons.modeler.Registry");
>> >   -Class tpc=Class.forName(
>> "org.apache.tomcat.util.threads.ThreadPoolMX");
>> >   -ThreadPool res=(ThreadPool)tpc.newInstance();
>> >   -return res;
>> >   -} catch( Exception ex ) {
>> >   -}
>> >   -}
>> >return new ThreadPool();
>> >}
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:
>>  [EMAIL PROTECTED]>
>> For
>> additional commands,
>> e-mail: 
>> 
>>



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

DO NOT REPLY [Bug 16474] New: - Unable to obtain correct data for version, path, or domain information from Cookie

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

Unable to obtain correct data for version, path, or domain information from Cookie

   Summary: Unable to obtain correct data for version, path, or
domain information from Cookie
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Other
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using a simple client that sends a cookie per RFC 2109:

Cookie: $Version=1; CookieName=CookieValue; $Path=/; $Domain=.test.com

On the server side, HttpServletRequest.getCookies() returns an array of Cookies
with 1 element.  Cookie.getName() and Cookie.getValue() both return the expected
values, bug Cookie.getVersion() returns 0, and Cookie.getDomain() and
Cookie.getPath() returns null.

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

Getting UserGroups from Apache

[Ignacio J. Ortega]

Hola a todos:

I recall hear from someone in the past that there are some problems
passing roles from Apache2 ( Using UserGroups or alike) to Tomcat, but i
dont recall the exact issue, anyone? 

Saludos, 
Ignacio J. Ortega 

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

Re: Trying to fix Gump

[Costin Manolache]

Larry Isaacs wrote:

> I'm trying to get Gump working with respect to
> jakarta-tomcat* projects.  I need to know which projects
> are intended to be dependent on jakarta-tomcat-coyote_10.
> 
> Currently, jakarta-tomcat-coyote_10 project lists
> tomcat-catalina as a dependent project, in addition to
> jakarta-tomcat.  Is the coyote_10 branch intended for
> use with any other jakarta-tomcat versions besides
> 3.3.x?  If somebody can save me the time of trying to
> hunt this down from prior e-mails, I would appreciate it.
> Thanks.

My understanding: the branch will be used with 3.3. 
I don't know about 4.1 - since it already has deps on 
modeler. 

tomcat-catalina should use the main branch - it is used for 5.0.

Costin



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

Re: [5.0] New mapper

[Costin Manolache]

Remy Maucherat wrote:

> (This question is for Costin)
> 
> As I've mentioned before, I'm writing a new mapper to replace the
> current 5.0 request mapper, which is a major performance problem right
> now.
> 
> The implementation goes well enough (I'll likely commit something today
> or tomorrow; in the end, there are no fancy algorithms involved), but
> there's the problem of keeping the mapper structure in sync with
> Catalina's structure.
> 
> To do that, I was planning to use a simple MBean registration listener
> (as all the components we're interested in register with JMX) with the
> MBean server. (I can only see a way of doing that using JMX 1.2)
> 
> So, is it ok to do that ? Is there a better way (I don't want to use the
> Catalina listeners, obviously) ?

If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.lang.String; instead of
java.lang.String[] ). And of course - fix download to get jmxri instead
of mx4j. 

When MX4J implements 1.2, we'll switch back.
I'm using JMXRI1.2 - and so far it works very nice. 

Regarding the registration listener: there are 2 issues you need to 
be carefull. First, it would be good if the code is independent of
the load order - i.e. listen for notifications but also do a query for
the existing objects. You can do that using JMX query, or by
using the attributes. After you take care of the existing mappings, 
you can start listening for registration - you can do both with plain
JMX1.1.

I don't know if all the components are registered - we do have the Context
and Servlet, but you'll need to make sure the Context mbean is exposing the
mappings. Unfortunately JSR77 ( or other standards I know ) do not define
any standard attribute that a "WebModule" mbean would use to expose
supported mappings - so the code will remain dependent of catalina, but
with less cupling.

BTW, I am now able to create Context mbeans and have them registered 
automatically - and I'll try to get the same working for Valves, Connectors
and JkHandlers. If this is used with an mbean server that supports
reloading ( like jboss.mx ) - we'll be able to replace modules without
restarting the VM ( which is pretty cool ).

Costin






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

RE: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java ThreadPoolMX.java

[Larry Isaacs]

I'll assume DynamicMBeanProxy will stay for now and
make sure the jtc/util projects in Gump still show a
dependency on JMX.

Larry

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 27, 2003 3:55 PM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit: 
> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
> eads ThreadPool.java ThreadPoolMX.java
> 
> 
> Larry Isaacs wrote:
> 
> > Hi Costin,
> > 
> > jtc/util still contains org.apache.tomcat.util.mx.DynamicMBeanProxy
> > which imports "javax.management.*".  Is the intent to 
> update or remove
> > this class so the dependency on JMX can be removed?  Thanks.
> 
> To deprecate - for sure, there is no point in maintaining it when the
> same functionality is in modeler. I made quite a few improvements to
> the equivalent code in modeler ( support for more types, 
> automatic detection
> of .xml descriptors, etc ).
> 
> About remove - I don't know if it was included in any 
> official release,
> and if removing it won't break code. I know of a use in 3.3, is anyone
> else using it ? 
> 
> We definitely need a way to document what APIs are "FROZEN" 
> ( like mozilla ). 
> 
> 
> Costin
> 
> > 
> > Cheers,
> > Larry
> > 
> >> -Original Message-
> >> From: Costin Manolache [mailto:[EMAIL PROTECTED]]
> >> Sent: Monday, January 27, 2003 10:39 AM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: cvs commit:
> >> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
> >> eads ThreadPool.java ThreadPoolMX.java
> >> 
> >> 
> >> FYI: I did the same in the main branch. All of DynamicMBean
> >> features are
> >> now porte to modeler. There is no need for JMX dependency 
> in jtc/util
> >> ( the branch is still needed in coyote, jk, http11 )
> >> 
> >> Costin
> >> 
> >> 
> >> 
> >> [EMAIL PROTECTED] wrote:
> >> > billbarker2003/01/24 20:49:24
> >> > 
> >> >   Modified:util/java/org/apache/tomcat/util/threads
> >> Tag: coyote_10
> >> > ThreadPool.java
> >> >   Removed: util/java/org/apache/tomcat/util/threads
> >> Tag: coyote_10
> >> > ThreadPoolMX.java
> >> >   Log:
> >> >   Removing JMX dependencies from this branch (as voted on
> >> in tomcat-dev).
> >> >   
> >> >   Revision  ChangesPath
> >> >   No   revision
> >> >   
> >> >   
> >> >   No   revision
> >> >   
> >> >   
> >> >   1.9.2.1   +0 -9
> >> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/thr
> >> eads/ThreadPool.java
> >> >   
> >> >   Index: ThreadPool.java
> >> >   
> >> ===
> >> >   RCS file:
> >> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomca
> >> t/util/threads/ThreadPool.java,v
> >> >   retrieving revision 1.9
> >> >   retrieving revision 1.9.2.1
> >> >   diff -u -r1.9 -r1.9.2.1
> >> >   --- ThreadPool.java  14 Jan 2003 18:47:39 -  1.9
> >> >   +++ ThreadPool.java  25 Jan 2003 04:49:24 -
>   1.9.2.1
> >> >   @@ -159,15 +159,6 @@
> >> > *   call register() in order to set a name.
> >> > */
> >> >public static ThreadPool createThreadPool(boolean jmx) {
> >> >   -if( jmx ) {
> >> >   -try {
> >> >   -Class.forName(
> >> "org.apache.commons.modeler.Registry");
> >> >   -Class tpc=Class.forName(
> >> "org.apache.tomcat.util.threads.ThreadPoolMX");
> >> >   -ThreadPool res=(ThreadPool)tpc.newInstance();
> >> >   -return res;
> >> >   -} catch( Exception ex ) {
> >> >   -}
> >> >   -}
> >> >return new ThreadPool();
> >> >}
> >> 
> >> 
> >> 
> >> 
> >> --
> >> To unsubscribe, e-mail:
> >>  [EMAIL PROTECTED]>
> >> For
> >> additional commands,
> >> e-mail: 
> >> 
> >>
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

DO NOT REPLY [Bug 16476] New: - session always old

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

session always old

   Summary: session always old
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In ver 4.1.18 & 4.17 I never get a null value from request.getSession( false ),
and the value of isNew() is always false.

I have tried the same code on 4.0 & 3.2 and it produced the expected results.

It always behaves as if the session is old, but it doesn't have any attributes
set, so I don't think that I am getting an old session.

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

Re: Interesting

[Costin Manolache]

Glenn Nielsen wrote:


>>> Interesting - but it won't work if the security manager is enabled.
>>> If the security manager is disabled ( as it is in 99% of the cases ) -
>>> there is no protection at all, if you can run servlets - you can do
>>> anything a C program can. Just load a JNI library and then control the
>>> VM at the low level, and access/modify anything that tomcat user can.
>>>
>>> It may be a good idea if 5.0 would have the secure mode as default.
>>> Users will complain their apps won't work and tomcat will be a bit
>>> slower -  but if this raises their awarness on security and maybe they
>>> fix some of the webapps to work in the sandbox, then it's worth it.
>>> Restoring the current mode can be easy - like adding a "-insecure"
>>> option or some TOMCAT_INSECURE env :-)
>> 
>> 
>> +1  And I'm sure that for the majority of Tomcat user, the performance
>> hit will not be so high.

Read the whole message :-)

The big problem is that many webapps will just break. And people will
have to start learning how to configure the policy. 

I do agree that it is worth it - but if we're going to do it we should
be prepared for a _lot_ of problems.  Performance is the smallest problem
we'll have.


>>> The sandbox is IMHO the biggest benefit of Java over all other
>>> languages ( including .net - I know they have similar concept, but I
>>> don't think it matches the JVM ).
>> 
> 
> Hear, hear.  That is what got me involved with Tomcat.

Well, it is what got me involved with Java in the first place :-)

Costin


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

Re: Trying to fix Gump

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 12:57 PM
Subject: Re: Trying to fix Gump


> Larry Isaacs wrote:
>
> > I'm trying to get Gump working with respect to
> > jakarta-tomcat* projects.  I need to know which projects
> > are intended to be dependent on jakarta-tomcat-coyote_10.
> >
> > Currently, jakarta-tomcat-coyote_10 project lists
> > tomcat-catalina as a dependent project, in addition to
> > jakarta-tomcat.  Is the coyote_10 branch intended for
> > use with any other jakarta-tomcat versions besides
> > 3.3.x?  If somebody can save me the time of trying to
> > hunt this down from prior e-mails, I would appreciate it.
> > Thanks.
>
> My understanding: the branch will be used with 3.3.
> I don't know about 4.1 - since it already has deps on
> modeler.

The original proposal was that 4.1 would use the coyote_10 branch (so that
it could keep on using modeler-1.0).  However, it's probably up to Remy,
since he's the one who will be packaging the releases :).

>
> tomcat-catalina should use the main branch - it is used for 5.0.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

not responding

[Ries, Josie]

I have just Apache tomcat and since then Visual Age will just stop
responding and CPU usage is at 100%.  This happens without a pattern and is
now happening very regularly.  Any ideas?

Josie Ries
Information Specialist 
EDS Business Services 
 MI/TN Solution Center
 phone: 586-774-0308
* mailto:[EMAIL PROTECTED]
pager: 877-835-5977


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

RE: Trying to fix Gump

[Larry Isaacs]

Getting the various jakarta-tomcat's to build together
in Gump is tricky.  The change to make jakarta-tomcat depend
on jakarta-tomcat-coyote_10 instead of
jakarta-tomcat-connectors represents a fundamental
build change.  jakarta-tomcat-connectors doesn't actually
build anything (it just forces source to be fetched),
where jakarta-tomcat-coyote_10 does build something.

How to best resolve this depends on who is going to
depend on jakarta-tomcat-coyote_10.  Since jakarta-tomcat-4.0
doesn't currently depend on it, I'll assume it is only
jakarta-tomcat that needs it.  I can make additional changes
later if that assumption proves incorrect.

Larry

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 27, 2003 3:58 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Trying to fix Gump
> 
> 
> Larry Isaacs wrote:
> 
> > I'm trying to get Gump working with respect to
> > jakarta-tomcat* projects.  I need to know which projects
> > are intended to be dependent on jakarta-tomcat-coyote_10.
> > 
> > Currently, jakarta-tomcat-coyote_10 project lists
> > tomcat-catalina as a dependent project, in addition to
> > jakarta-tomcat.  Is the coyote_10 branch intended for
> > use with any other jakarta-tomcat versions besides
> > 3.3.x?  If somebody can save me the time of trying to
> > hunt this down from prior e-mails, I would appreciate it.
> > Thanks.
> 
> My understanding: the branch will be used with 3.3. 
> I don't know about 4.1 - since it already has deps on 
> modeler. 
> 
> tomcat-catalina should use the main branch - it is used for 5.0.
> 
> Costin
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

Re: Interesting

[Glenn Nielsen]

Costin Manolache wrote:

Glenn Nielsen wrote:




Interesting - but it won't work if the security manager is enabled.
If the security manager is disabled ( as it is in 99% of the cases ) -
there is no protection at all, if you can run servlets - you can do
anything a C program can. Just load a JNI library and then control the
VM at the low level, and access/modify anything that tomcat user can.

It may be a good idea if 5.0 would have the secure mode as default.
Users will complain their apps won't work and tomcat will be a bit
slower -  but if this raises their awarness on security and maybe they
fix some of the webapps to work in the sandbox, then it's worth it.
Restoring the current mode can be easy - like adding a "-insecure"
option or some TOMCAT_INSECURE env :-)



+1  And I'm sure that for the majority of Tomcat user, the performance
hit will not be so high.




Read the whole message :-)

The big problem is that many webapps will just break. And people will
have to start learning how to configure the policy. 

I do agree that it is worth it - but if we're going to do it we should
be prepared for a _lot_ of problems.  Performance is the smallest problem
we'll have.



One of the things which has been on my TODO list for a while is to
write some documentation about how to code API's and web applications
which are SecurityManager friendly. I frequently run across code which
was written in a way which makes setting security policies difficult,
or require granting permissions you really don't want to grant to a web
application running in a sandbox. Having a document to point user's
to would help.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--


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

RE: Trying to fix Gump

[Larry Isaacs]

Okay, I'll make sure I keep the option of using
coyote_10 for Tomcat 4.1 open in how I fix things for
Tomcat 3.3.x.

Larry

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 27, 2003 4:30 PM
> To: Tomcat Developers List
> Subject: Re: Trying to fix Gump
> 
> 
> 
> - Original Message -
> From: "Costin Manolache" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 27, 2003 12:57 PM
> Subject: Re: Trying to fix Gump
> 
> 
> > Larry Isaacs wrote:
> >
> > > I'm trying to get Gump working with respect to
> > > jakarta-tomcat* projects.  I need to know which projects
> > > are intended to be dependent on jakarta-tomcat-coyote_10.
> > >
> > > Currently, jakarta-tomcat-coyote_10 project lists
> > > tomcat-catalina as a dependent project, in addition to
> > > jakarta-tomcat.  Is the coyote_10 branch intended for
> > > use with any other jakarta-tomcat versions besides
> > > 3.3.x?  If somebody can save me the time of trying to
> > > hunt this down from prior e-mails, I would appreciate it.
> > > Thanks.
> >
> > My understanding: the branch will be used with 3.3.
> > I don't know about 4.1 - since it already has deps on
> > modeler.
> 
> The original proposal was that 4.1 would use the coyote_10 
> branch (so that
> it could keep on using modeler-1.0).  However, it's probably 
> up to Remy,
> since he's the one who will be packaging the releases :).
> 
> >
> > tomcat-catalina should use the main branch - it is used for 5.0.
> >
> > Costin
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> > For additional commands, e-mail:
> 
> >
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

JVM Error

[Alexander Leyke]

Hello,

I work on JK2 family module for AOLserver and use JNI to communicate 
with Tomcat, so the JVM is running inside the Web server process. I 
experience a problem with JVM 1.3.1 on Solaris 2.7/E250 and wonder if 
anyone else has encountered a similar issue. It manifests itself as JVM 
crashing, writing a message to the tune "HotSpot Virtual Machine 
Error/Cannot obtain thread information" and dumping core due to SIGSEGV. 
It appears that I can reproduce the error by launching AOLserver with 
JVM in-process, executing a couple of requests and then letting the 
server sit idle for about 10 minutes. Subsequent request to Tomcat has a 
good chance of crashing the server.

Examining core in dbx reveals that SEGV always happens in AOLserver 
request thread, bound to JVM by virtue of using a JNI channel. I can 
trace the signal to a C++ method, Thread* 
ThreadLocalStorage::get_thread_via_cache(), local to libjvm.so 
(debugging data is available if anyone is interested). What could be 
causing this problem and how can I correct it?

I also see a SEGV during JVM initialization. JVM establishes signal 
handlers to trap and absorb signals, so this one doesn't cause any 
visible damage. I detect it in dbx and truss, and it seems to originate 
in JRE library libnet.so evaluating equivalent of C expression *(int*)0. 
I am puzzled because it looks like intentional dereference of NULL pointer.

Your help is appreciated!
Alex


Typical problem report for the crash:

Unexpected Signal : 11 occurred at PC=0xfdcbc5c4
Function name=JVM_Clone
Library=/opt/java/jre/lib/sparc/server/libjvm.so

Cannot obtain thread information

Dynamic libraries:
0x1 bin/nsd
0xff38  /usr/lib/libsocket.so.1
0xff28  /usr/lib/libnsl.so.1
0xff3a  /usr/lib/libdl.so.1
0xff35  /usr/lib/librt.so.1
0xff24  /usr/lib/libthread.so.1
0xff20  /usr/lib/libresolv.so.2
0xff1d  /usr/lib/libm.so.1
0xff10  /usr/lib/libc.so.1
0xff0e  /usr/lib/libmp.so.2
0xff0c  /usr/lib/libaio.so.1
0xff33  /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
0xff03  /home/aleykekh/aolserver-3.4-opt/bin/nssock.so
0xfe7e  /home/aleykekh/aolserver-3.4-opt/bin/nslog.so
0xfe7c  /home/aleykekh/aolserver-3.4-opt/bin/nscgi.so
0xfe75  /home/aleykekh/newtomcat/jakarta-tomcat-connectors-4.1.12-src/jk/build/jk2/aolserver/libnsjk2.so
0xfe70  /home/aleykekh/newtomcat/apache2/lib/libapr-0.so.0
0xfe6c  /home/aleykekh/newtomcat/apache2/lib/libaprutil-0.so.0
0xfe68  /usr/local/lib/libexpat.so.0
0xfdc0  /opt/java/jre/lib/sparc/server/libjvm.so
0xfe65  /usr/lib/libCrun.so.1
0xff05  /usr/lib/libw.so.1
0xfe61  /export/0/j2se-1.3.1/jre/lib/sparc/native_threads/libhpi.so
0xfe3d  /export/0/j2se-1.3.1/jre/lib/sparc/libverify.so
0xfe39  /export/0/j2se-1.3.1/jre/lib/sparc/libjava.so
0xfe35  /export/0/j2se-1.3.1/jre/lib/sparc/libzip.so
0xfe31  /usr/lib/nss_files.so.1
0xfe5e  /home/aleykekh/aolserver-3.4-opt/bin/nscp.so
0xfa7e  /export/0/j2se-1.3.1/jre/lib/sparc/libnet.so

Local Time = Fri Jan 24 16:28:43 2003
Elapsed Time = 992
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002CC 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#


The "Function name" at the top of report varies, eg., 
JVM_GetMethodIxArgsSize, JVM_RawMonitorEnter.



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

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

[amyroh]

amyroh  2003/01/27 14:19:24

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationContext.java
  Log:
  Fix to return MalformedURLException when the path doesn't begin with a "/".
  Bugtraq 4806986.
  
  Revision  ChangesPath
  1.7   +8 -4  
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.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ApplicationContext.java   6 Nov 2002 13:37:03 -   1.6
  +++ ApplicationContext.java   27 Jan 2003 22:19:24 -  1.7
  @@ -598,6 +598,10 @@
   public URL getResource(String path)
   throws MalformedURLException {
   
  +if (!path.startsWith("/")) {
  +throw new 
MalformedURLException(sm.getString("applicationContext.requestDispatcher.iae"));
  +}
  +
   path = normalize(path);
   if (path == null)
   return (null);
  
  
  

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

Re: [GUMP] Build Failure - jakarta-tomcat-catalina

[Amy Roh]

Costin,

Did you forget to update StandardContext that works with TldConfig?  The 
current workspace doesn't compile due to the following error.

build-catalina-core:
[javac] Compiling 306 source files to /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes
[javac] /home/rubys/jakarta/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java:259: cannot resolve symbol
[javac] symbol  : method setTldScanTime (long)
[javac] location: class org.apache.catalina.core.StandardContext
[javac] ((StandardContext)context).setTldScanTime(t2-t1);
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 1 error

BUILD FAILED
file:///home/rubys/jakarta/jakarta-tomcat-catalina/catalina/build.xml:611: Compile failed; see the compiler error output for details.


Thanks,
Amy


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

Re: using ajp (isapi_redirector2.dll) without tomcat on IIS (is_inited =0 in HttpExtensionProc)

[James Chang]

Hi,

Here is more information I got.  It looks like what happened is, the
socket open and data sending is done in HttpExtensionProc,
However the static int is_inited is always 0 when that function is called.
However is_inited is been set to 1 upon dll initialization by another
thread,
and when HttpFilterProc is called by IIS, the is_inited is 1.

Almost looks like the 2 functions (filterProc and ExtensionProc) is been
called from 2 different stack frame from IIS, but when the address
of the variable is the same (XP virtual memory trick?).

I am using windows XP Pro latest patch (as of jan 27, 2003) and IIS
5.01.
Anybody got any ideas?

Thanks


- Original Message -
From: "James Chang" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, January 27, 2003 2:02 PM
Subject: using ajp (isapi_redirector2.dll) without tomcat on IIS


I have downloaded apache binary dist and the ajp connector source, and
builded the IIS redirector (It was rather strange that apr.h is in apache
binary dist but not in the apache source release).

What I found with debug messages is,  HttpFilterProc() is called with I
request http://localhost/examples/x, which means the dll is installed
correctly and the configuration files are correct (mappings and etc).
However there is no line of code in HttpFilterProc() that actually calls
anything to open the socket and send data.  I checked several possible
functions to see if they are the ones who send data, but all turn out to be
some string manipulation functions.

Could someone tell me which function call in HttpFilterProc actaully result
in open socket to 8009 port?

Thanks

- Original Message -
From: "James Chang" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 8:53 PM
Subject: using ajp without tomcat


> Hi:
>
> I am trying to get ajp to work for other jsp/servlet engines other
then
> tomcat.   Right now I am working on IIS with isapi_redirector2.dll and
> listening on port 8009 with my own ajp listener.
>
> I downloaded isapi_redirector2.dll from:
>
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.
> 2/bin/win32/
>
> set up the registry settings and use the simple works2.properties file
> below.  IIS shows the dll is loaded correctly, but when I try to request
to
> http://localhost/examples/x , the isapi_redirector2.dll doesn't send
any
> request to port 8009.
>
> Could anyone tell me what is wrong with my configuration file?  Or is
> the dll somehow need tomcat to work (I have set it to use socket, but
maybe
> the dll needs some configuration file or shared library from tomcat)??
>
> Any pointer will be usefull.
> Thanks!
>
>
> the registry I used is:
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Jakarta Isapi
> Redirector\2.0]
> "serverRoot"="d:\\tm"
> "extensionUri"="/jakarta/isapi_redirector2.dll"
> "workersFile"="D:\\shared\\iisredir\\workers2.properties"
> "authComplete"="0"
> "threadPool"="5"
>
> All strings are properly installed.
>
>
> My workers2.properties file contains:
>
> # Define the communication channel
> [channel.socket:localhost:8009]
> info=Ajp13 forwarding over socket
> tomcatId=localhost:8009

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

Tomcat 4.1.18 server crashes

[Philip Li]

> My Tomcat 4.1.18 server, running on Win2K Advanced Server, seems to
> crash regularly, and consistently, without any obvious reason (nothing
> showed up in the log at the time of crash) under the following
> conditions:
> 
> I am trying to refresh a database display page regularly using 
> 
> 
> 
> The refresh rate is 5 seconds.  The database page opens two database
> connections using JDBC.ODBC driver to connect to a SQL2000 server. I
> also got the following error message intermittently when I try to
> update the database from within the page:
> java.sql.SQLException: [Microsoft][ODBC SQL Server Driver]Connection
> is busy with results for another hstmt
> 
> Any ideas and/or suggestions would be greatly appreciated.  Thanks
> very much in advance.
> 
> Philip
> p.s.- Tomcat 4.1.12 server behaves exactly the same way.
> 
> 

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

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

[luehe]

luehe   2003/01/27 15:15:34

  Modified:jasper2/src/share/org/apache/jasper/compiler
ParserController.java Validator.java
  Log:
  Treat "UTF-16", "UTF-16BE", and "UTF-16LE" as identical when comparing
  - the detected XML encoding of a JSP document
(as per section 4.3.3 of the XML specification),
  - the encoding specified in the 'pageEncoding' attribute of the page
directive of the JSP document, and
  - the encoding specified in a JSP configuration
element whose URL pattern matches the document.
  
  This fixes JSP 2.0 TCK test "i18nXmlPageResponseEncodingTest".
  
  Revision  ChangesPath
  1.31  +5 -2  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- ParserController.java 27 Jan 2003 18:10:47 -  1.30
  +++ ParserController.java 27 Jan 2003 23:15:33 -  1.31
  @@ -201,10 +201,13 @@
if (isTopFile) {
if (isXml) {
// Make sure the encoding determined from the XML prolog
  - // matches that in the JSP config element, if present
  + // matches that in the JSP config element, if present.
  + // Treat "UTF-16", "UTF-16BE", and "UTF-16LE" as identical.
String jspConfigPageEnc = pageInfo.getPageEncoding();
if (jspConfigPageEnc != null
  - && !jspConfigPageEnc.equals(sourceEnc)) {
  + && !jspConfigPageEnc.equals(sourceEnc)
  + && (!jspConfigPageEnc.startsWith("UTF-16")
  + || !sourceEnc.startsWith("UTF-16"))) {
err.jspError("jsp.error.prolog_config_encoding_mismatch",
 sourceEnc, jspConfigPageEnc);
}
  
  
  
  1.70  +9 -4  
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.69
  retrieving revision 1.70
  diff -u -r1.69 -r1.70
  --- Validator.java27 Jan 2003 18:10:47 -  1.69
  +++ Validator.java27 Jan 2003 23:15:34 -  1.70
  @@ -257,13 +257,18 @@
 * attribute of the page directive of the JSP page, and in
 * a JSP configuration element (whose URL pattern matches
 * the page).
  +  *
 * At this point, we've already verified (in 
 * ParserController.parse()) that the page character
 * encodings specified in a JSP config element and XML
 * prolog match.
  +  *
  +  * Treat "UTF-16", "UTF-16BE", and "UTF-16LE" as identical.
 */
String compareEnc = pageInfo.getPageEncoding();
  - if (!value.equals(compareEnc)) {
  + if (!value.equals(compareEnc) 
  + && (!value.startsWith("UTF-16")
  + || !compareEnc.startsWith("UTF-16"))) {
if (pageInfo.isXml()) {
err.jspError(n,
 "jsp.error.prolog_pagedir_encoding_mismatch",
  
  
  

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

Re: JVM Error

[Costin Manolache]

I've seen similar problems - java is very sensitive to each thread
beeing 'registered'. My understanding is that attaching the
thread will set all the TLDs that are needed, and jk2 is calling the 
attach method - so I don't know what is wrong here.

My bet would be on thread creation - I would add some printf with the
TID serving the request ( before attaching the thread ). One thing that
may happen in 10 minutes is the thread management code adding or removing
threads. 

Costin

Alexander Leyke wrote:

> Hello,
> 
> I work on JK2 family module for AOLserver and use JNI to communicate
> with Tomcat, so the JVM is running inside the Web server process. I
> experience a problem with JVM 1.3.1 on Solaris 2.7/E250 and wonder if
> anyone else has encountered a similar issue. It manifests itself as JVM
> crashing, writing a message to the tune "HotSpot Virtual Machine
> Error/Cannot obtain thread information" and dumping core due to SIGSEGV.
> It appears that I can reproduce the error by launching AOLserver with
> JVM in-process, executing a couple of requests and then letting the
> server sit idle for about 10 minutes. Subsequent request to Tomcat has a
> good chance of crashing the server.
> 
> Examining core in dbx reveals that SEGV always happens in AOLserver
> request thread, bound to JVM by virtue of using a JNI channel. I can
> trace the signal to a C++ method, Thread*
> ThreadLocalStorage::get_thread_via_cache(), local to libjvm.so
> (debugging data is available if anyone is interested). What could be
> causing this problem and how can I correct it?
> 
> I also see a SEGV during JVM initialization. JVM establishes signal
> handlers to trap and absorb signals, so this one doesn't cause any
> visible damage. I detect it in dbx and truss, and it seems to originate
> in JRE library libnet.so evaluating equivalent of C expression *(int*)0.
> I am puzzled because it looks like intentional dereference of NULL
> pointer.
> 
> Your help is appreciated!
> Alex
> 
> 
> Typical problem report for the crash:
> 
> Unexpected Signal : 11 occurred at PC=0xfdcbc5c4
> Function name=JVM_Clone
> Library=/opt/java/jre/lib/sparc/server/libjvm.so
> 
> Cannot obtain thread information
> 
> Dynamic libraries:
> 0x1 bin/nsd
> 0xff38  /usr/lib/libsocket.so.1
> 0xff28  /usr/lib/libnsl.so.1
> 0xff3a  /usr/lib/libdl.so.1
> 0xff35  /usr/lib/librt.so.1
> 0xff24  /usr/lib/libthread.so.1
> 0xff20  /usr/lib/libresolv.so.2
> 0xff1d  /usr/lib/libm.so.1
> 0xff10  /usr/lib/libc.so.1
> 0xff0e  /usr/lib/libmp.so.2
> 0xff0c  /usr/lib/libaio.so.1
> 0xff33  /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
> 0xff03  /home/aleykekh/aolserver-3.4-opt/bin/nssock.so
> 0xfe7e  /home/aleykekh/aolserver-3.4-opt/bin/nslog.so
> 0xfe7c  /home/aleykekh/aolserver-3.4-opt/bin/nscgi.so
> 0xfe75 
>
/home/aleykekh/newtomcat/jakarta-tomcat-connectors-4.1.12-src/jk/build/jk2/aolserver/libnsjk2.so
> 0xfe70  /home/aleykekh/newtomcat/apache2/lib/libapr-0.so.0
> 0xfe6c  /home/aleykekh/newtomcat/apache2/lib/libaprutil-0.so.0
> 0xfe68  /usr/local/lib/libexpat.so.0
> 0xfdc0  /opt/java/jre/lib/sparc/server/libjvm.so
> 0xfe65  /usr/lib/libCrun.so.1
> 0xff05  /usr/lib/libw.so.1
> 0xfe61 
> /export/0/j2se-1.3.1/jre/lib/sparc/native_threads/libhpi.so
> 0xfe3d  /export/0/j2se-1.3.1/jre/lib/sparc/libverify.so
> 0xfe39  /export/0/j2se-1.3.1/jre/lib/sparc/libjava.so
> 0xfe35  /export/0/j2se-1.3.1/jre/lib/sparc/libzip.so
> 0xfe31  /usr/lib/nss_files.so.1
> 0xfe5e  /home/aleykekh/aolserver-3.4-opt/bin/nscp.so
> 0xfa7e  /export/0/j2se-1.3.1/jre/lib/sparc/libnet.so
> 
> Local Time = Fri Jan 24 16:28:43 2003
> Elapsed Time = 992
> #
> # HotSpot Virtual Machine Error : 11
> # Error ID : 4F530E43505002CC 01
> # Please report this error at
> # http://java.sun.com/cgi-bin/bugreport.cgi
> #
> 
> 
> The "Function name" at the top of report varies, eg.,
> JVM_GetMethodIxArgsSize, JVM_RawMonitorEnter.



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

Re: [GUMP] Build Failure - jakarta-tomcat-catalina

[Costin Manolache]

I'll update it - I wanted to run more tests and it seems I forgot to commit
it.

Sorry
Costin

Amy Roh wrote:

> Costin,
> 
> Did you forget to update StandardContext that works with TldConfig?  The
> current workspace doesn't compile due to the following error.
> 
>> build-catalina-core:
>> [javac] Compiling 306 source files to
>> [/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes
>> [javac]
>>
[/home/rubys/jakarta/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/TldConfig.java:259:
>> [cannot resolve symbol
>> [javac] symbol  : method setTldScanTime (long)
>> [javac] location: class org.apache.catalina.core.StandardContext
>> [javac] ((StandardContext)context).setTldScanTime(t2-t1);
>> [javac] ^
>> [javac] Note: Some input files use or override a deprecated API.
>> [javac] Note: Recompile with -deprecation for details.
>> [javac] 1 error
>> 
>> BUILD FAILED
>>
file:///home/rubys/jakarta/jakarta-tomcat-catalina/catalina/build.xml:611:
>> Compile failed; see the compiler error output for details.
> 
> Thanks,
> Amy



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

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

[costin]

costin  2003/01/27 15:27:27

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Few changes - sorry for mixing them up in a single commit.
  
  - use commons-logging
  
  - one small experiment: change the logger on context startup, so each context can
  log in a separate log. The 'experimental' part is the namming of the log - I'm not
  sure which is best
  
  - merged the code from mbeans/ directory - the ContextMBean is no longer needed ( but
  some code needs to be fixed - some of the added methods have names that conflict 
with the
  base class )
  
  - fixed registration so all servlets will be registered
  
  - added code to support dynamic addition of Contexts as mbeans ( i.e. using only JMX
  registration ). The Context mbean will register itself with the server.
  
  - use TldCache to read the Tlds.
  
  Revision  ChangesPath
  1.14  +391 -93   
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- StandardContext.java  16 Jan 2003 21:38:25 -  1.13
  +++ StandardContext.java  27 Jan 2003 23:27:26 -  1.14
  @@ -67,12 +67,14 @@
   
   import java.io.File;
   import java.io.IOException;
  +import java.io.Serializable;
   import java.util.ArrayList;
   import java.util.HashMap;
   import java.util.Iterator;
   import java.util.TreeMap;
   import java.util.Hashtable;
   import java.util.Stack;
  +import java.net.URLDecoder;
   import javax.servlet.FilterConfig;
   import javax.servlet.ServletContext;
   import javax.servlet.ServletContextEvent;
  @@ -82,6 +84,8 @@
   import javax.naming.NamingException;
   import javax.naming.directory.DirContext;
   import javax.management.ObjectName;
  +import javax.management.MBeanServer;
  +import javax.management.MalformedObjectNameException;
   import org.apache.naming.ContextBindings;
   import org.apache.naming.resources.BaseDirContext;
   import org.apache.naming.resources.FileDirContext;
  @@ -105,6 +109,9 @@
   import org.apache.catalina.Response;
   import org.apache.catalina.Valve;
   import org.apache.catalina.Wrapper;
  +import org.apache.catalina.startup.ContextConfig;
  +import org.apache.catalina.startup.TldConfig;
  +import org.apache.catalina.mbeans.MBeanUtils;
   import org.apache.catalina.deploy.ApplicationParameter;
   import org.apache.catalina.deploy.ContextEjb;
   import org.apache.catalina.deploy.ContextEnvironment;
  @@ -129,6 +136,7 @@
   
   import org.apache.tomcat.util.log.SystemLogHandler;
   import org.apache.commons.modeler.Registry;
  +import org.apache.commons.modeler.ManagedBean;
   import org.apache.commons.logging.Log;
   import org.apache.commons.logging.LogFactory;
   
  @@ -144,9 +152,9 @@
   
   public class StandardContext
   extends ContainerBase
  -implements Context
  +implements Context, Serializable
{
  -private static Log log = LogFactory.getLog(StandardContext.class);
  +private Log log = LogFactory.getLog(StandardContext.class);
   
   
   
  @@ -179,7 +187,7 @@
* The set of instantiated application listener objects, in a one-to-one
* correspondence to the class names in applicationListeners.
*/
  -private Object applicationListenersObjects[] = new Object[0];
  +private transient Object applicationListenersObjects[] = new Object[0];
   
   
   /**
  @@ -198,7 +206,7 @@
   /**
* The Locale to character set mapper for this application.
*/
  -private CharsetMapper charsetMapper = null;
  +private transient CharsetMapper charsetMapper = null;
   
   
   /**
  @@ -229,7 +237,7 @@
   /**
* The ServletContext implementation associated with this Context.
*/
  -private ApplicationContext context = null;
  +private transient ApplicationContext context = null;
   
   
   /**
  @@ -314,7 +322,7 @@
   /**
* The naming context listener for this web application.
*/
  -private NamingContextListener namingContextListener = null;
  +private transient NamingContextListener namingContextListener = null;
   
   
   /**
  @@ -501,9 +509,14 @@
   
   private ArrayList wrappers=new ArrayList();
   
  -// - Context Properties
  +private long startupTime;
  +private long tldScanTime;
   
  +// - Context Properties
   
  +public void setName( String name ) {
  +super.setName( name );
  +}
   /**
* Is caching allowed ?
*/
  @@ -634,6 +647,8 @@
   
   CharsetMapper oldCharsetMapper = this.charsetMappe

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

[costin]

costin  2003/01/27 15:33:10

  Modified:catalina/src/share/org/apache/catalina/core
StandardWrapper.java
  Log:
  Remove unneeded param.
  
  Store the startup time instead of displaying it ( will be visible in the jmx console 
)
  
  added missing getter.
  
  Removed the final - duplication the code inside is too painfull.
  
  BTW - in the previous commit, I also made StandardContext serializable. It won't
  work ( a lot of other classes are not serializable ), but in time we may get to a 
point
  where we can cache the configured state of the context and avoid parsing unless 
needed.
  
  Revision  ChangesPath
  1.13  +17 -16
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java
  
  Index: StandardWrapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapper.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- StandardWrapper.java  24 Jan 2003 23:47:45 -  1.12
  +++ StandardWrapper.java  27 Jan 2003 23:33:10 -  1.13
  @@ -91,6 +91,7 @@
   import org.apache.catalina.util.InstanceSupport;
   import org.apache.tomcat.util.log.SystemLogHandler;
   import org.apache.commons.modeler.Registry;
  +
   /**
* Standard implementation of the Wrapper interface that represents
* an individual servlet definition.  No child Containers are allowed, and
  @@ -100,8 +101,7 @@
* @author Remy Maucherat
* @version $Revision$ $Date$
*/
  -
  -public final class StandardWrapper
  +public class StandardWrapper
   extends ContainerBase
   implements ServletConfig, Wrapper {
   
  @@ -251,6 +251,7 @@
   // To support jmx attributes
   private StandardWrapperValve swValve;
   private long loadTime=0;
  +private long classLoadTime=0;
   
   // - Properties
   
  @@ -423,9 +424,11 @@
   } catch (NumberFormatException e) {
   setLoadOnStartup(0);
   }
  -
   }
   
  +public String getLoadOnStartupString() {
  +return Integer.toString( getLoadOnStartup());
  +}
   
   
   /**
  @@ -928,10 +931,7 @@
   ((ContainerServlet) servlet).setWrapper(this);
   }
   
  -if( System.currentTimeMillis() -t1 > 200 ) {
  -log.info("Created servlet class " + actualClass + " " +
  - (System.currentTimeMillis() - t1 ) );
  -}
  +classLoadTime=System.currentTimeMillis() -t1;
   // Call the initialization method of this servlet
   try {
   instanceSupport.fireInstanceEvent(InstanceEvent.BEFORE_INIT_EVENT,
  @@ -1011,7 +1011,8 @@
   }
   }
   }
  -registerJMX((ContainerBase)getParent(), this);
  +if( oname != null )
  +registerJMX((ContainerBase)getParent());
   return servlet;
   
   }
  @@ -1441,11 +1442,11 @@
   
   }
   
  -void registerJMX(ContainerBase ctx, StandardWrapper wrapper) {
  +protected void registerJMX(ContainerBase ctx) {
   try {
  -String name=wrapper.getJspFile();
  +String name=this.getJspFile();
   if( name==null ) {
  -name=wrapper.getServletName();
  +name=this.getServletName();
   }
   // it should be full name
   String parentName=ctx.getName();
  @@ -1455,7 +1456,7 @@
   String oname="j2eeType=Servlet,name=" + name + ",WebModule=" +
   webMod + ctx.getJSR77Suffix();
   
  -Registry.getRegistry().registerComponent(wrapper,
  +Registry.getRegistry().registerComponent(this,
   ctx.getDomain(), "Servlet", oname);
   } catch( Exception ex ) {
   log.info("Error registering servlet with jmx " + this);
  
  
  

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

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

[costin]

costin  2003/01/27 15:35:47

  Modified:catalina/src/share/org/apache/catalina/core
ContainerBase.java
  Log:
  Added a "type" attribute, corresponding to the j2eeType or type from the name.
  
  Make the j2eesuffix ( used internally ) protected, so it won't show in the console.
  
  Revision  ChangesPath
  1.4   +14 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java
  
  Index: ContainerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ContainerBase.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ContainerBase.java11 Jan 2003 05:07:50 -  1.3
  +++ ContainerBase.java27 Jan 2003 23:35:47 -  1.4
  @@ -601,7 +601,6 @@
   String oldName = this.name;
   this.name = name;
   support.firePropertyChange("name", oldName, this.name);
  -
   }
   
   
  @@ -817,7 +816,7 @@
   throw new IllegalArgumentException("addChild:  Child name '" +
  child.getName() +
  "' is not unique");
  -child.setParent((Container) this);  // May throw IAE
  +child.setParent(this);  // May throw IAE
   if (started && (child instanceof Lifecycle)) {
   try {
   ((Lifecycle) child).start();
  @@ -1462,6 +1461,7 @@
   }
   
   //  JMX and Registration  
  +protected String type;
   protected String domain;
   protected String suffix;
   protected ObjectName oname;
  @@ -1475,7 +1475,11 @@
   return domain;
   }
   
  -public String getJSR77Suffix() {
  +public String getType() {
  +return type;
  +}
  +
  +protected String getJSR77Suffix() {
   return suffix;
   }
   
  @@ -1484,6 +1488,12 @@
   oname=name;
   mserver=server;
   domain=name.getDomain();
  +
  +type=name.getKeyProperty("type");
  +if( type==null ) {
  +type=name.getKeyProperty("j2eeType");
  +}
  +
   String j2eeApp=name.getKeyProperty("J2EEApplication");
   String j2eeServer=name.getKeyProperty("J2EEServer");
   if( j2eeApp==null ) {
  
  
  

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

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

[costin]

costin  2003/01/27 15:36:16

  Modified:catalina/src/share/org/apache/catalina/core
StandardEngine.java
  Log:
  Remove debugging message.
  
  Revision  ChangesPath
  1.3   +4 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java
  
  Index: StandardEngine.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardEngine.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- StandardEngine.java   3 Jan 2003 16:59:08 -   1.2
  +++ StandardEngine.java   27 Jan 2003 23:36:16 -  1.3
  @@ -195,7 +195,6 @@
* This property should not be changed once it is set.
*/
   public void setJvmRoute(String routeId) {
  -this.log("setJvmRoute=" + routeId);
   jvmRouteId = routeId;
   }
   
  
  
  

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

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

[costin]

costin  2003/01/27 15:40:13

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
  Log:
  Changed to c-l.
  
  Set the class loader on digester - it seems the HEAD works better this way.
  
  Revision  ChangesPath
  1.6   +24 -26
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- StandardHostDeployer.java 15 Jan 2003 03:40:42 -  1.5
  +++ StandardHostDeployer.java 27 Jan 2003 23:40:13 -  1.6
  @@ -1,7 +1,4 @@
   /*
  - * $Header$
  - * $Revision$
  - * $Date$
*
* 
*
  @@ -99,6 +96,8 @@
   
   public class StandardHostDeployer implements Deployer {
   
  +private static org.apache.commons.logging.Log log=
  +org.apache.commons.logging.LogFactory.getLog( StandardHostDeployer.class );
   
   // --- Constructors
   
  @@ -128,6 +127,12 @@
   
   
   /**
  + * The ContextRuleSet associated with our
  + * digester instance.
  + */
  +private ContextRuleSet contextRuleSet = null;
  +
  + /**
* The Digester instance to use for deploying web applications
* to this Host.  WARNING - Usage of this
* instance must be appropriately synchronized to prevent simultaneous
  @@ -135,14 +140,6 @@
*/
   private Digester digester = null;
   
  -
  -/**
  - * The ContextRuleSet associated with our
  - * digester instance.
  - */
  -private ContextRuleSet contextRuleSet = null;
  -
  -
   /**
* The StandardHost instance we are associated with.
*/
  @@ -229,7 +226,7 @@
   (sm.getString("standardHost.warRequired"));
   
   // Calculate the document base for the new web application
  -host.log(sm.getString("standardHost.installing",
  +log.info(sm.getString("standardHost.installing",
 contextPath, war.toString()));
   String url = war.toString();
   String docBase = null;
  @@ -307,9 +304,10 @@
   host.fireContainerEvent(PRE_INSTALL_EVENT, context);
   host.addChild(context);
   host.fireContainerEvent(INSTALL_EVENT, context);
  +} catch (ClassNotFoundException e) {
  +log.info("", e);
   } catch (Exception e) {
  -host.log(sm.getString("standardHost.installError", contextPath),
  - e);
  +log.info("Error installing", e);
   throw new IOException(e.toString());
   }
   
  @@ -364,7 +362,7 @@
   (sm.getString("standardHost.warRequired"));
   
   // Calculate the document base for the new web application
  -host.log(sm.getString("standardHost.installing",
  +log.info(sm.getString("standardHost.installing",
 contextPath, war.toString()));
   String url = war.toString();
   String docBase = null;
  @@ -401,8 +399,8 @@
   StandardServer server = (StandardServer) 
engine.getService().getServer();
   server.storeContext(context);
   } catch (Exception e) {
  -host.log(sm.getString("standardHost.installError", contextPath),
  - e);
  +log.error(sm.getString("standardHost.installError", contextPath),
  +  e);
   throw new IOException(e.toString());
   }
   
  @@ -451,7 +449,7 @@
   String docBase = null; // Optional override for value in config file
   if (war != null) {
   String url = war.toString();
  -host.log(sm.getString("standardHost.installingWAR", url));
  +log.info(sm.getString("standardHost.installingWAR", url));
   // Calculate the WAR file absolute pathname
   if (url.startsWith("jar:")) {
   url = url.substring(4, url.length() - 2);
  @@ -474,6 +472,7 @@
   stream = config.openStream();
   Digester digester = createDigester();
   digester.setDebug(host.getDebug());
  +digester.setClassLoader(this.getClass().getClassLoader());
   digester.clear();
   digester.push(this);
   digester.parse(stream);
  @@ -559,12 +558,12 @@
   (sm.getString("standardHost.pathMissing", contextPath));
   
   // Remove this web application
  -host.log(sm.getString("standardHost.removing", contextPath));
  +log.info(sm.getString("standardHost.removing

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy ApplicationParameter.java ContextEjb.java ContextEnvironment.java ContextLocalEjb.java ContextResource.java ContextResourceLink.java ErrorPage.java FilterDef.java FilterMap.java LoginConfig.java MessageDestinationRef.java NamingResources.java ResourceParams.java SecurityCollection.java SecurityConstraint.java

[costin]

costin  2003/01/27 15:45:19

  Modified:catalina/src/share/org/apache/catalina/deploy
ApplicationParameter.java ContextEjb.java
ContextEnvironment.java ContextLocalEjb.java
ContextResource.java ContextResourceLink.java
ErrorPage.java FilterDef.java FilterMap.java
LoginConfig.java MessageDestinationRef.java
NamingResources.java ResourceParams.java
SecurityCollection.java SecurityConstraint.java
  Log:
  Add "Serializable".
  
  Revision  ChangesPath
  1.2   +7 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ApplicationParameter.java
  
  Index: ApplicationParameter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ApplicationParameter.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ApplicationParameter.java 18 Jul 2002 16:48:05 -  1.1
  +++ ApplicationParameter.java 27 Jan 2003 23:45:18 -  1.2
  @@ -64,6 +64,8 @@
   
   package org.apache.catalina.deploy;
   
  +import java.io.Serializable;
  +
   
   /**
* Representation of a context initialization parameter that is configured
  @@ -76,7 +78,7 @@
* @version $Revision$ $Date$
*/
   
  -public final class ApplicationParameter {
  +public final class ApplicationParameter implements Serializable {
   
   
   // - Properties
  
  
  
  1.2   +7 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextEjb.java
  
  Index: ContextEjb.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextEjb.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ContextEjb.java   18 Jul 2002 16:48:05 -  1.1
  +++ ContextEjb.java   27 Jan 2003 23:45:18 -  1.2
  @@ -64,6 +64,8 @@
   
   package org.apache.catalina.deploy;
   
  +import java.io.Serializable;
  +
   
   /**
* Representation of an EJB resource reference for a web application, as
  @@ -74,7 +76,7 @@
* @version $Revision$ $Date$
*/
   
  -public final class ContextEjb {
  +public final class ContextEjb implements Serializable {
   
   
   // - Properties
  
  
  
  1.2   +7 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextEnvironment.java
  
  Index: ContextEnvironment.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextEnvironment.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ContextEnvironment.java   18 Jul 2002 16:48:05 -  1.1
  +++ ContextEnvironment.java   27 Jan 2003 23:45:19 -  1.2
  @@ -64,6 +64,8 @@
   
   package org.apache.catalina.deploy;
   
  +import java.io.Serializable;
  +
   
   /**
* Representation of an application environment entry, as represented in
  @@ -73,7 +75,7 @@
* @version $Revision$ $Date$
*/
   
  -public final class ContextEnvironment {
  +public final class ContextEnvironment implements Serializable {
   
   
   // - Properties
  
  
  
  1.2   +7 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextLocalEjb.java
  
  Index: ContextLocalEjb.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextLocalEjb.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ContextLocalEjb.java  18 Jul 2002 16:48:05 -  1.1
  +++ ContextLocalEjb.java  27 Jan 2003 23:45:19 -  1.2
  @@ -64,6 +64,8 @@
   
   package org.apache.catalina.deploy;
   
  +import java.io.Serializable;
  +
   
   /**
* Representation of a local EJB resource reference for a web application, as
  @@ -74,7 +76,7 @@
* @version $Revision$ $Date$
*/
   
  -public final class ContextLocalEjb {
  +public final class ContextLocalEjb implements Serializable {
   
   
   // - Properties
  
  
  
  1.2   +7 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextResource.java
  
  Index: ContextResource.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/deploy/ContextResource.java,v
  retrieving revis

Re: Question about duplication of secure property in RequestBase and HttpRequestBase

[John Sisson]

Thanks for the reply Tim, but I don't think my question was clear enough.

Both the RequestBase and HttpRequestBase classes have their own isSecure
instance variable and have their own setSecure() and isSecure() methods.
The code in both classes seems to do the same thing.  My question is, is
there any reason why the methods and instance variable are duplicated in the
HttpRequestBase class.  It seems that the code in HttpRequestBase relating
to the "secure" instance variable is not needed, as it is provided in its
superclass, RequestBase.

Thanks,

John

- Original Message -
From: "Tim Funk" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 2:28 AM
Subject: Re: Question about duplication of secure property in RequestBase
and HttpRequestBase


> org.apache.catalina.connector.RequestBase implements ServletRequest.
>
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/catalina/docs/api/org/apache
/catalina/connector/RequestBase.html
>
> And isSecure is part of the interface of ServletRequest.
>
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletReques
t.html#isSecure()
>
> -Tim
>
> John Sisson wrote:
> > Hi,
> >
> > I noticed that both org.apache.catalina.connector.RequestBase and
org.apache.catalina.connector.HttpRequestBase both have a "secure" instance
variable and the setSecure(bool) isSecure() methods.  Does anybody know the
reason for this?
> >
> > Thanks,
> >
> > John
> >
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>

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

DO NOT REPLY [Bug 16479] New: - unwraps ServletResponseWrapper

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

 unwraps ServletResponseWrapper

   Summary:  unwraps ServletResponseWrapper
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


class org.apache.jasper.runtime.PageContextImpl has a forward() method that 
inappropriately unwrapps the response wrapper if one exists.  See the code 
below to see the suggested fix.  The current behavior appears to violate the 
Servlet Specification as the dispatched response object is NOT same one for the 
current page context.  This is verified to be a problem in Tomcat 4.0.5, and 
appears to have the same problem in Tomcat 4.1.12.  However, I have not 
verified if this was fixed in 4.1.18.  The suggest fix is below:

public void forward(String relativeUrlPath)
throws ServletException, IOException
{
:
:
/** @todo - REMOVE THE FOLLOW WHILE LOOP */
// Make sure that the response object is not the wrapper for include
while (response instanceof HttpServletResponseWrapper)
response = ((HttpServletResponseWrapper)response).getResponse();
:
:
}

Thanks.

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

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

[kinman]

kinman  2003/01/27 16:13:39

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
TagFileProcessor.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_fr.properties messages_ja.properties
   jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
  Log:
  - Implements name-from-attribute and alias in variable directives in tag file
  
  Revision  ChangesPath
  1.154 +66 -19
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.153
  retrieving revision 1.154
  diff -u -r1.153 -r1.154
  --- Generator.java22 Jan 2003 20:54:54 -  1.153
  +++ Generator.java28 Jan 2003 00:13:37 -  1.154
  @@ -2478,6 +2478,43 @@
return attrValue;
}
   
  + /**
  +  * Generate code to create a map for the alias variables
  +  * @return the name of the map
  +  */
  + private String generateAliasMap(Node.CustomTag n, String tagHandlerVar)
  + throws JasperException {
  +
  + TagInfo tagInfo = n.getTagInfo();
  + TagVariableInfo[] tagVars = tagInfo.getTagVariableInfos();
  + String aliasMapVar = "null";
  +
  + boolean aliasSeen = false;
  + for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-servletapi-5/jsr154/src/share/dtd web-jsptaglibrary_2_0.xsd

[kinman]

kinman  2003/01/27 16:19:10

  Modified:jsr152/src/share/dtd web-jsptaglibrary_2_0.xsd
   jsr152/src/share/javax/servlet/jsp/el
ExpressionEvaluator.java FunctionMapper.java
   jsr152/src/share/javax/servlet/jsp/tagext SimpleTag.java
   jsr154/src/share/dtd web-jsptaglibrary_2_0.xsd
  Log:
  - Patch by Mark Roth:
  
  Final API patch before PFD2 release of JSP 2.0 specification.
  
  jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd
   - Updated description for function-signature element
  
  jsr154/src/share/dtd/web-jsptaglibrary_2_0.xsd
   - Updated description for function-signature element
  
  jsr152/src/share/javax/servlet/jsp/el/FunctionMapper.java
   - Changed description of prefix parameter to resolveFunction
("" means no prefix)
  
  jsr152/src/share/javax/servlet/jsp/el/ExpressionEvaluator.java
   - Changed description of defaultPrefix parameter to resolveFunction
("" means the default is no prefix)
   - Changed description of defaultPrefix parameter to evaluate
("" means the default is no prefix)
  
  jsr152/src/share/javax/servlet/jsp/tagext/SimpleTag.java
   - Changed javadocs for setJspBody().  null is no longer passed
if the body is empty.  Instead, setJspBody() is not called.
  
  Revision  ChangesPath
  1.7   +27 -6 
jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd
  
  Index: web-jsptaglibrary_2_0.xsd
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_2_0.xsd,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- web-jsptaglibrary_2_0.xsd 8 Nov 2002 21:30:20 -   1.6
  +++ web-jsptaglibrary_2_0.xsd 28 Jan 2003 00:19:10 -  1.7
  @@ -10,7 +10,7 @@
   
   
   
  -@(#)web-jsptaglibrary_2_0.xsds   1.24 11/01/02
  +@(#)web-jsptaglibrary_2_0.xsds   1.26 01/24/03
   
   
   
  @@ -52,8 +52,8 @@
   
   

Re: [4.1.20] Tagging soon ?

[Glenn Nielsen]

Xerces 2.3 was just released and claims it fixes the bug we saw with Tomcat.
Perhaps we should test and verify this so we can use it for the distributions.

Glenn

Remy Maucherat wrote:

I plan to port the changes made to JSPC in the Tomcat 5 branch, and (as 
I think fixing the issue is important) tag a new 4.1.20 milestone within 
a few days.

Comments ?

Remy



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

Re: [4.1.20] Tagging soon ?

[Jeanfrancois Arcand]

We should waiit  for 4.1.20The last 3 versions were broken, and we 
should test it extensively. Unfortunatly, I cannot test it tonigh and 
tomorrow (but latter this the week). We should wait based on experience :-)

-- Jeanfrancois



Glenn Nielsen wrote:

Xerces 2.3 was just released and claims it fixes the bug we saw with 
Tomcat.
Perhaps we should test and verify this so we can use it for the 
distributions.

Glenn

Remy Maucherat wrote:

I plan to port the changes made to JSPC in the Tomcat 5 branch, and 
(as I think fixing the issue is important) tag a new 4.1.20 milestone 
within a few days.

Comments ?

Remy



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 






--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

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

[kinman]

kinman  2003/01/27 17:42:57

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
   jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
  Log:
  - Suppress generation of alias map if there is no aliases.
  
  Revision  ChangesPath
  1.155 +33 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.154
  retrieving revision 1.155
  diff -u -r1.154 -r1.155
  --- Generator.java28 Jan 2003 00:13:37 -  1.154
  +++ Generator.java28 Jan 2003 01:42:57 -  1.155
  @@ -2487,7 +2487,7 @@
   
TagInfo tagInfo = n.getTagInfo();
TagVariableInfo[] tagVars = tagInfo.getTagVariableInfos();
  - String aliasMapVar = "null";
  + String aliasMapVar = null;
   
boolean aliasSeen = false;
for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

RE: [GUMP] Build Failure - jakarta-tomcat-catalina

[Larry Isaacs]

Is there an update to MBeanUtils?  My local Gump is getting:

[javac] Compiling 306 source files to 
\Gump\Base\jakarta-tomcat-catalina\build\server\classes
[javac] 
C:\Gump\Base\jakarta-tomcat-catalina\catalina\src\share\org\apache\catalina\core\StandardContext.java:4441:
 createObjectName(java.lang.String,org.apache.catalina.deploy.ContextEnvironment) is 
not public in org.apache.catalina.mbeans.MBeanUtils; cannot be accessed from outside 
package
[javac] MBeanUtils.createObjectName(this.getDomain(), envs[i]);
[javac]   ^
...
 
Cheers,
Larry

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, January 27, 2003 6:15 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [GUMP] Build Failure - jakarta-tomcat-catalina
> 
> 
> I'll update it - I wanted to run more tests and it seems I 
> forgot to commit
> it.
> 
> Sorry
> Costin
> 
> Amy Roh wrote:
> 
> > Costin,
> > 
> > Did you forget to update StandardContext that works with 
> TldConfig?  The
> > current workspace doesn't compile due to the following error.
> > 
> >> build-catalina-core:
> >> [javac] Compiling 306 source files to
> >> 
> [/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes
> >> [javac]
> >>
> [/home/rubys/jakarta/jakarta-tomcat-catalina/catalina/src/shar
> e/org/apache/catalina/startup/TldConfig.java:259:
> >> [cannot resolve symbol
> >> [javac] symbol  : method setTldScanTime (long)
> >> [javac] location: class 
> org.apache.catalina.core.StandardContext
> >> [javac] 
> ((StandardContext)context).setTldScanTime(t2-t1);
> >> [javac] ^
> >> [javac] Note: Some input files use or override a 
> deprecated API.
> >> [javac] Note: Recompile with -deprecation for details.
> >> [javac] 1 error
> >> 
> >> BUILD FAILED
> >>
> file:///home/rubys/jakarta/jakarta-tomcat-catalina/catalina/bu
ild.xml:611:
>> Compile failed; see the compiler error output for details.
> 
> Thanks,
> Amy



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


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

DO NOT REPLY [Bug 16479] - unwraps ServletResponseWrapper

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

 unwraps ServletResponseWrapper

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-28 03:13 ---
It appears that this problem was fixed around 4.1.10.  I'm not sure if this is 
a duplicate of another bug, so I'll just mark this as invalid.

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

JspC compile JSP with JSTL

[Kelly Chen]

I just wonder if anyone have done this before. I am using JspC to 
compile JSP from the command line.  It was working OK until I tried to 
use JSTL. As soon as I add the following lines to the to be compiled JSP
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>

JspC starts to run into error. I debug a bit more into Jasper, the root 
problem is caused by a SAX exception

 [jasper2] [TldLocationsCache] tldConfigJar(/WEB-INF/lib/standard.jar): Process
ing entry 'META-INF/c.tld'
 [jasper2] Parsing /WEB-INF/lib/standard.jar
 [jasper2] The string "--" is not permitted within comments.+ line307
 [jasper2] org.xml.sax.SAXParseException: The string "--" is not permitted with
in comments.
[jasper2] at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
[jasper2] at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Sour
e)
[jasper2] at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:
6)
[jasper2] at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(Pars
rUtils.java:171)
[jasper2] at org.apache.jasper.compiler.TldLocationsCache.parseTldForUri(T
dLocationsCache.java:288)
[jasper2] at org.apache.jasper.compiler.TldLocationsCache.tldConfigJar(Tld
ocationsCache.java:254)
[jasper2] at org.apache.jasper.compiler.TldLocationsCache.processJars(TldL
cationsCache.java:218)
.

I couldn't really make much sense out of the error message. the standard.jar is jakarta-taglibs, standard-1.0.2. I have been trying to use different version of dom/sax parser, different version of Jasper library. The result is all the same. Do I miss anything obvious? 

I know Jasper supports 1.2 JSTL and it must have been worked from Tomcat, because I have seen UI page shows JSP with the core taglib without issue. I just couldn't figure why JspC couldn't do the same. 

--
Kelly Chen   Tumbleweed Communication Corp.
T:650-216-2043   700 Saginaw Drive
F:650-216-2565   Redwood City, CA 94063





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

Re: JspC compile JSP with JSTL

[Jeanfrancois Arcand]

Replace the xercesImpl.jar with Xerces 2.1.0. There is a bug in Xerces 
that cause that strage error.,

-- Jeanfrancois

Kelly Chen wrote:

I just wonder if anyone have done this before. I am using JspC to 
compile JSP from the command line.  It was working OK until I tried to 
use JSTL. As soon as I add the following lines to the to be compiled JSP
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>

JspC starts to run into error. I debug a bit more into Jasper, the 
root problem is caused by a SAX exception

 [jasper2] [TldLocationsCache] 
tldConfigJar(/WEB-INF/lib/standard.jar): Process
ing entry 'META-INF/c.tld'
 [jasper2] Parsing /WEB-INF/lib/standard.jar
 [jasper2] The string "--" is not permitted within comments.+ line307
 [jasper2] org.xml.sax.SAXParseException: The string "--" is not 
permitted with
in comments.
[jasper2] at org.apache.xerces.parsers.DOMParser.parse(Unknown 
Source)
[jasper2] at 
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Sour
e)
[jasper2] at 
javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:
6)
[jasper2] at 
org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(Pars
rUtils.java:171)
[jasper2] at 
org.apache.jasper.compiler.TldLocationsCache.parseTldForUri(T
dLocationsCache.java:288)
[jasper2] at 
org.apache.jasper.compiler.TldLocationsCache.tldConfigJar(Tld
ocationsCache.java:254)
[jasper2] at 
org.apache.jasper.compiler.TldLocationsCache.processJars(TldL
cationsCache.java:218)
.

I couldn't really make much sense out of the error message. the 
standard.jar is jakarta-taglibs, standard-1.0.2. I have been trying to 
use different version of dom/sax parser, different version of Jasper 
library. The result is all the same. Do I miss anything obvious?
I know Jasper supports 1.2 JSTL and it must have been worked from 
Tomcat, because I have seen UI page shows JSP with the core taglib 
without issue. I just couldn't figure why JspC couldn't do the same.



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

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

[costin]

costin  2003/01/27 21:29:22

  Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
  Log:
  Another commit - my workspace is almost in sync now.
  
  Make few methods public - so same code will be used to create the names.
  More important - replace the use of the hashcode in the Valve names with a seq.
  number.
  
  One change I'm not committing yet is use of .ser cache for mbeans-descriptors.xml.
  
  Revision  ChangesPath
  1.10  +41 -18
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
  
  Index: MBeanUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- MBeanUtils.java   22 Nov 2002 22:36:51 -  1.9
  +++ MBeanUtils.java   28 Jan 2003 05:29:22 -  1.10
  @@ -68,6 +68,7 @@
   import java.lang.reflect.Method;
   import java.net.URL;
   import java.net.URLEncoder;
  +import java.util.Hashtable;
   
   import javax.management.Attribute;
   import javax.management.InstanceAlreadyExistsException;
  @@ -102,6 +103,7 @@
   import org.apache.catalina.User;
   import org.apache.catalina.UserDatabase;
   import org.apache.catalina.Valve;
  +import org.apache.catalina.valves.ValveBase;
   import org.apache.catalina.core.StandardService;
   import org.apache.catalina.deploy.ContextEnvironment;
   import org.apache.catalina.deploy.ContextResource;
  @@ -870,7 +872,7 @@
*
* @exception MalformedObjectNameException if a name cannot be created
*/
  -static ObjectName createObjectName(String domain,
  +public static ObjectName createObjectName(String domain,
 ContextEnvironment environment)
   throws MalformedObjectNameException {
   
  @@ -924,7 +926,7 @@
*
* @exception MalformedObjectNameException if a name cannot be created
*/
  -static ObjectName createObjectName(String domain,
  +public static ObjectName createObjectName(String domain,
 ContextResource resource)
   throws MalformedObjectNameException {
   
  @@ -983,7 +985,7 @@
*
* @exception MalformedObjectNameException if a name cannot be created
*/
  -static ObjectName createObjectName(String domain,
  +public static ObjectName createObjectName(String domain,
 ContextResourceLink resourceLink)
   throws MalformedObjectNameException {
   
  @@ -1522,8 +1524,13 @@
* @exception MalformedObjectNameException if a name cannot be created
*/
   static ObjectName createObjectName(String domain,
  -  Valve valve)
  +   Valve valve)
   throws MalformedObjectNameException {
  +if( valve instanceof ValveBase ) {
  +ObjectName name=((ValveBase)valve).getObjectName();
  +if( name != null )
  +return name;
  +}
   
   ObjectName name = null;
   Container container = null;
  @@ -1538,15 +1545,15 @@
   
   if (container instanceof Engine) {
   Service service = ((Engine)container).getService();
  +String local=",service=" + service.getName();
   name = new ObjectName(domain + ":type=Valve,sequence=" +
  -  valve.hashCode() + ",service=" +
  -  service.getName());
  +  getSeq(local) + local );
   } else if (container instanceof Host) {
   Service service = ((Engine)container.getParent()).getService();
  +String local=",host=" +container.getName() + ",service=" +
  +service.getName();
   name = new ObjectName(domain + ":type=Valve,sequence=" +
  -  valve.hashCode() + ",host=" +
  -  container.getName() + ",service=" +
  -  service.getName() );
  +  getSeq(local) + local);
   } else if (container instanceof Context) {
   String path = ((Context)container).getPath();
   if (path.length() < 1) {
  @@ -1554,17 +1561,29 @@
   }
   Host host = (Host) container.getParent();
   Service service = ((Engine) host.getParent()).getService();
  +String local=",path=" + path + ",host=" +
  +host.getName() + ",service=" + service.getName();
   name = new ObjectName(domain + ":type=Valve,sequence=" +
  -  valve.hashCode() + ",path=" +
  -  

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java HandlerRequest.java

[costin]

costin  2003/01/27 21:42:24

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
HandlerRequest.java
  Log:
  Fix the name of the jk handler.
  
  Fix a NPE - req must be created first.
  
  Revision  ChangesPath
  1.33  +1 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- ChannelSocket.java20 Jan 2003 19:20:32 -  1.32
  +++ ChannelSocket.java28 Jan 2003 05:42:24 -  1.33
  @@ -360,7 +360,7 @@
   if( this.domain != null ) {
   try {
   Registry.getRegistry().registerComponent(tp, domain,"ThreadPool",
  -"type=ThreadPool,worker=jk,name=" + getAddress() + "%" + 
port);
  +"type=ThreadPool,worker=jk,name=Jk" + port);
   } catch (Exception e) {
   log.error("Can't register threadpool" );
   }
  
  
  
  1.23  +1 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
  
  Index: HandlerRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- HandlerRequest.java   20 Jan 2003 23:48:40 -  1.22
  +++ HandlerRequest.java   28 Jan 2003 05:42:24 -  1.23
  @@ -418,7 +418,6 @@
   {
   // FORWARD_REQUEST handler
   Request req=(Request)ep.getRequest();
  -req.setStartTime(System.currentTimeMillis());
   if( req==null ) {
   req=new Request();
   Response res=new Response();
  @@ -444,6 +443,7 @@
   }
   }
   
  +req.setStartTime(System.currentTimeMillis());
   JkInputStream jkBody=(JkInputStream)ep.getNote( bodyNote );
   if( jkBody==null ) {
   jkBody=new JkInputStream();
  
  
  

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

Re: [4.1.20] Tagging soon ?

[Remy Maucherat]

Jeanfrancois Arcand wrote:

We should waiit  for 4.1.20The last 3 versions were broken, and we 
should test it extensively. Unfortunatly, I cannot test it tonigh and 
tomorrow (but latter this the week). We should wait based on experience :-)

Indeed, experience shows we have to be careful with new Xerces releases ;-)

Remy


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

DO NOT REPLY [Bug 14200] - TLDs under WEB-INF are not scanned for URI mappings

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

TLDs under WEB-INF are not scanned for URI mappings

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-28 06:46 ---
Looks like this one only got fixed for TC 5. I'd appreciate it if someone can
port it to TC 4.1 as well (it doesn't work in TC 4.1.18, have not tested 4.1.19
yet).

It's been clarified by JSR-152 that the auto-discovery of TLDs includes TLDs
located directly in the file system under WEB-INF (for JSP 2.0, but there's no
reason not to do the same for JSP 1.2).

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeansMBeanUtils.java

[Craig R. McClanahan]

On 28 Jan 2003 [EMAIL PROTECTED] wrote:

> Date: 28 Jan 2003 05:29:22 -
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: cvs commit:
> jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans
> MBeanUtils.java
>
> costin  2003/01/27 21:29:22
>
>   Modified:catalina/src/share/org/apache/catalina/mbeans
> MBeanUtils.java
>   Log:
>   Another commit - my workspace is almost in sync now.
>
>   Make few methods public - so same code will be used to create the names.
>   More important - replace the use of the hashcode in the Valve names with a seq.
>   number.
>

Just a word of warning ... we tried sequence numbers for Valves initially,
but got into problems when contexts were reloaded.  Make sure you've
covered all of those corner cases.

Craig


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

Help: Why HttpFilterProc and HttpExtensionsProc on 2 different process in isapi_redirector2.dll?

[James Chang]

Hi,

   System: windows XP pro, IIS 5.1.   isapi_redirector2.dll is not doing
its job.
isapi_redirector2.dll from:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v2.0.
2/bin/win32/

What happened is, when IIS starts up, it calls dll_Main for all its
threads and calls GetVersion() 1 time, in the function isapi_redirector2.dll
initializes everything and set is_inited to TRUE.  All those happens in one
process (the same process IIS calls HttpFilterProc).

However when the match is found and the redirector tries to call Tomcat,
IIS calls HttpExtensionProc from ANOTHER process, basically in this process
nothing is initialized (the process id get by GetCurrentProcessId() is
different from the first process).

Anyone got any ideas?

Thanks



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