DO NOT REPLY [Bug 15894] - Access to other sessions possible (session is immediately recycled after invalidation/expiration)

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

Access to other sessions possible (session is immediately recycled after 
invalidation/expiration)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-15 06:21 ---
Fixed now in the CVS.

I went for a hybrid of your 2 and 3.

The answer for when 3.3.2 is going to be released is: Hopefully soon.

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

cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpSessionFacade.java Servlet22Interceptor.java

[billbarker]

billbarker2003/01/14 22:11:24

  Modified:src/facade22/org/apache/tomcat/facade HttpSessionFacade.java
Servlet22Interceptor.java
  Log:
  Remember when the actual session has been invalidated.
  
  It is possible for the realSession to become valid again because it is being used by 
somebody else.  Thus we can't rely on the realSession on its own.
  
  Also keep a copy of the sessionId so that we don't return somebody elses Id instead.
  
  I'm going to some lengths here to avoid doing a String comparision for every access.
  
  Hopefully the last fix for bug #15894
  Reported By: Christian Wicke [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.20  +8 -2  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java
  
  Index: HttpSessionFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpSessionFacade.java,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- HttpSessionFacade.java10 Jan 2003 05:40:12 -  1.19
  +++ HttpSessionFacade.java15 Jan 2003 06:11:23 -  1.20
  @@ -93,6 +93,9 @@
   private static StringManager sm =
   StringManager.getManager("org.apache.tomcat.resources");
   ServerSession realSession;
  +//  We need to keep the Id, since it may change in realSession.
  +private String sessionId;
  +private boolean isValid = false;
   
   HttpSessionFacade() {
   }
  @@ -102,18 +105,21 @@
   void setRealSession(ServerSession s) {
realSession=s;
realSession.setFacade( this );
  + sessionId = realSession.getId().toString();
  + isValid = true;
}
   
   /** Package-level method - accessible only by core
*/
   void recycle() {
  + isValid = false;
//  realSession=null;
   }
   
   //  public facade 
   
   public String getId() {
  - return realSession.getId().toString();
  + return sessionId;
   }
   
   /**
  @@ -301,7 +307,7 @@
   
   // duplicated code, private
   private void checkValid() {
  - if (!realSession.getTimeStamp().isValid()) {
  + if (! (realSession.getTimeStamp().isValid() && isValid )) {
throw new IllegalStateException
(sm.getString("standardSession.getAttributeNames.ise"));
}
  
  
  
  1.22  +3 -0  
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java
  
  Index: Servlet22Interceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Servlet22Interceptor.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- Servlet22Interceptor.java 12 Oct 2002 06:01:28 -  1.21
  +++ Servlet22Interceptor.java 15 Jan 2003 06:11:23 -  1.22
  @@ -235,6 +235,9 @@
sess.removeAttribute( key );
}
}
  + if( httpSess != null && newState==ServerSession.STATE_EXPIRED ) {
  + ((HttpSessionFacade)httpSess).recycle();
  + }
} 
return 0;
   }
  
  
  

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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Glenn Nielsen]

The book I have on JMX didn't mention anything about security.
Therefor my concern.  I'll take a look at the JMX 1.2 spec & RI.

Yeah, the SecurityManager is definitely the right way to go.

Thanks,

Glenn

Costin Manolache wrote:

Glenn Nielsen wrote:



I have one general comment.  For security I would like to see two
different
MBeanServers used.  One for config management the other for runtime
monitoring. This way you could implement diffrent access controls for
config management
from runtime  monitoring.



That's one concern I have with JMX - there is some protection using 
the Policy ( in JMX1.2 ), but if you don't run the sandbox you're 
on your own.

All JMX implementations seem to support some "interceptors" and we can
try to implement our own add-on scheme ( not sure if Sun RI extensions are
documented or exist - but MX4J and Jboss provide that ). 

I'm afraid using 2 MBeanServers is not the best solution - if we put the
mbean server in the parent loader, I'm pretty sure user code will be able 
to get it ( if it wants to ). And the code can become very complicated. 

You know my opinion on this - if you don't run the sandbox, user code can 
control the VM without problems ( with some JNI code - or introspection,
or by overriding files ). If you run sandbox - the JMX1.2 policy-based 
access control should be good enough.

Costin



Glenn

Costin Manolache wrote:


Remy Maucherat wrote:




This looks fine. Do I get some sample code before voting, so I can see
the thing in action ?



I'm working on converting Jk to Listeners.

I want to first check in some changes to enable the "what is each thread
doing" feature - but that would add the dependency to JMX.

Time for a branch...

Should I do the changes in a branch, or branch the current stable code
and make changes in HEAD ?





I posted some more notes on my weblog ( which I just started few days
ago ), and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).


Arg, you fell for blogging ! ;-P
I'm not going to (although I do enjoy reading blogs): discussions should
stay on the mailing lists, which do have centralized archives. If lists
get more quiet because of blogging, then it's good (less emails to read
every day :-D ).



I have a feeling the blogging is already affecting the lists. And it
certainly helps organize yourself - that was the main argument for me.

Are other tomcat developers blogging ? Should we keep a list - maybe in
wiki ?

It would be nice to be able to take all blogs about tomcat and feed them
into the list ( I have a category for tocmat and one for ant - but I
don't know too much about blogging yet ).


Costin







--
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-5 build.properties.default

[glenn]

glenn   2003/01/14 19:38:00

  Modified:.build.properties.default
  Log:
  Port manager webapp changes from Tomcat 4
  
  Revision  ChangesPath
  1.55  +8 -1  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- build.properties.default  9 Dec 2002 11:16:29 -   1.54
  +++ build.properties.default  15 Jan 2003 03:38:00 -  1.55
  @@ -150,6 +150,13 @@
   
commons-pool.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-pool/v1.0.1/commons-pool-1.0.1.tar.gz
   
   
  +# - Commons FileUpload, nightly build -
  +commons-fileupload.home=${base.path}/commons-fileupload
  +commons-fileupload.lib=${commons-fileupload.home}
  +commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-dev.jar
  
+#commons-fileupload.loc=http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-fileupload/commons-fileupload-20030106.zip
  +
  +
   # - JavaGroups, version 2.0.3 or later -
   javagroups.home=${base.path}/JavaGroups-2.0.3.bin
   javagroups.lib=${javagroups.home}
  
  
  

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

JK connector build problem - help required

[Kulkarni, Charudatta (SUPP)]

Hi ,

My setup

Solaris 2.6
Apache 1.3.27
Tomcat 4.1.18
Trying to build JK connector [jakarta-tomcat-connectors-4.1.18-src] for above

Getting errors as follows :

$ ant native
Buildfile: build.xml

jkant:
[mkdir] Created dir: 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/classes
[mkdir] Created dir: 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/classes/META-INF
[mkdir] Created dir: 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/lib
[javac] Compiling 17 source files to 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/classes
 [copy] Copying 1 file to 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/classes/META-INF
  [jar] Building jar: 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/lib/jkant.jar

detect:
 [echo]  jakarta-tomcat-connectors 

report:
 [echo] Tomcat33: ${tomcat33.detect} ../../jakarta-tomcat/build/tomcat
 [echo] Tomcat40:  true /export/home/charuk/tomcat18
 [echo] Tomcat41: ${tomcat41.detect} ../../jakarta-tomcat-4.1/build
 [echo] Tomcat5:  ${tomcat5.detect} ../../jakarta-tomcat-5/build
 [echo] Apache13: true /export/home/charuk/apache27
 [echo] Apache2: ${apache2.detect} /opt/apache2
 [echo] iPlanet:  ${iplanet.detect} /opt/iplanet6
 [echo] IIS:  ${iis.detect} ${iis.home}

native:

init:
 [echo] /export/home/charuk

apache20:

apache13:
   [so] Compiling 0 out of 18
Linking 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/mod_jk.so
   [so] Link failed 1
   [so] Command:libtool --mode=link cc -module -avoid-version -rpath 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13 -o 
mod_jk.la 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_msg_buff.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp13_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_md5.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_pool.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp14.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp12_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_map.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_sockbuf.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_uri_worker_map.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp_common.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_lb_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_context.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_connect.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp13.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_util.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp14_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/apache-1.3/mod_jk.lo
   [so] Output:
   [so] rm -fr .libs/mod_jk.la .libs/mod_jk.* .libs/mod_jk.*
   [so] /usr/local/bin/gcc -shared  
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_msg_buff.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp13_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_md5.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_pool.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp14.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp12_worker.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_map.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_sockbuf.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_uri_worker_map.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_ajp_common.lo
 
/export/home/charuk/jakarta-tomcat-connectors-4.1.18-src/jk/build/jk/apache13/common/jk_lb_worker.lo
 
/export/home/charuk/jakarta-

Re: [4.1.19] New tag

[Glenn Nielsen]

All of the manager testing and doc review/changes have been completed.

Tomcat 4.1.19 may be released. :-)

Thanks for waiting Remy.

Glenn

Glenn Nielsen wrote:

I just committed what looks like the last code bug fix.

But we are working on some minor changes to the manager docs which show 
examples
using windows URL's and paths in addition to the unix style.  Those 
minor doc
changes should be in later tonight or tomorrow morning.  I'll let you 
know when we are done.

Regards,

Glenn

Remy Maucherat wrote:

Glenn Nielsen wrote:


OK.

Please hold off for a bit.  We have found 2 more bugs in the manager 
from
our testing.  Tracking them down now.



BTW, are you done with your bugfixing ?

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 









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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs html-manager-howto.xml

[glenn]

glenn   2003/01/14 17:40:12

  Modified:webapps/tomcat-docs html-manager-howto.xml
  Log:
  Final changes to docs, ready to do Tomcat 4.1.19 release
  
  Revision  ChangesPath
  1.4   +12 -12jakarta-tomcat-4.0/webapps/tomcat-docs/html-manager-howto.xml
  
  Index: html-manager-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/html-manager-howto.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- html-manager-howto.xml13 Jan 2003 21:13:54 -  1.3
  +++ html-manager-howto.xml15 Jan 2003 01:40:12 -  1.4
  @@ -315,19 +315,19 @@
   refer to the entire WAR file.
   
   In this example the web application located in the directory
  -/path/to/foo on the Tomcat server is installed as the
  -web application context named /footoo.
  +C:\path\to\foo on the Tomcat server (running on Windows)
  +is installed as the web application context named /footoo.
   
   Context Path: /footoo
  -WAR or Directory URL: file:/path/to/foo
  +WAR or Directory URL: file:C:/path/to/foo
   
   
   
   In this example the ".war" file /path/to/bar.war on the
  -Tomcat server is installed as the web application context named
  -/bar. Notice that there is no path parameter
  -so the context path defaults to the name of the web application archive
  -file without the ".war" extension.
  +Tomcat server (running on Unix) is installed as the web application
  +context named /bar. Notice that there is no path
  +parameter so the context path defaults to the name of the web application
  +archive file without the ".war" extension.
   
   WAR or Directory URL: jar:file:/path/to/bar.war!/
   
  @@ -369,9 +369,9 @@
   A Context configuration ".xml" file can contain valid XML for a
   web application Context just as if it were configured in your
   Tomcat server.xml configuration file. Here is an
  -example:
  +example for Tomcat running on Windows:
   
  -
   
 
  @@ -387,15 +387,15 @@
   docBase configured in the context configuration ".xml" file.
   
   Here is an example of installing an application using a Context
  -configuration ".xml" file.
  +configuration ".xml" file for Tomcat running on Windows.
   
  -XML Configuration file URL: file:/path/to/context.xml
  +XML Configuration file URL: file:C:/path/to/context.xml
   
   
   
   Here is an example of installing an application using a Context
   configuration ".xml" file and a web application ".war" file located
  -on the server.
  +on the server (Tomcat running on Unix).
   
   XML Configuration file URL: file:/path/to/context.xml
   WAR or Directory URL: jar:file:/path/to/bar.war!/
  
  
  

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

DO NOT REPLY [Bug 15961] - getBodyContent() is not returning null when the action has only jsp:attribute actions within the body.

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

getBodyContent() is not returning null when the action has only jsp:attribute actions 
within the body.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-15 00:49 ---
The issue has been resolved for Classic tag handlers, however a clarification
has been added to the spec with regards to this case with Simple tag handlers:

JSP.12.6, item 5, bullet 1: Change to:

* If the tag is declared to have a body-content
  of "empty" or no body or an empty body is passed
  for this invocation, then null is passed to
  setJspBody().

If the TLD doesn't mark body-content as empty and an empty jsp:body element is
provided, getJspBody() doesn't return null as it should.

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

DO NOT REPLY [Bug 16088] New: - Translation error not generated if body of jsp:attribute, providing an attribute value of type JspFragment, contains a scripting element

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

Translation error not generated if body of jsp:attribute, providing an attribute value 
of type JspFragment, contains a scripting element

   Summary: Translation error not generated if body of
jsp:attribute, providing an attribute value of type
JspFragment, contains a scripting element
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


>From JSP.5.10

   "For custom action attributes of type javax.servlet.jsp.tagext.JspFragment, 
the container must create a JspFragment out of the body of the 
 action and pass it to the tag handler.  This applies for
both Classic Tag Handlers and Simple Tag Handlers.  A translation error must
result if the body of the  action is not scriptless in this
case"

Given

<%@ page contentType="text/plain" %>
<%@ taglib uri="http://blurb.org"; prefix="attr" %>



<%= "fragment body" %>


-

In the TLD, the classic tag has one attribute named 'fragment' with the 
 element body set to true.

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

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

[luehe]

luehe   2003/01/14 16:20:46

  Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Generator.java
   jasper2/src/share/org/apache/jasper/runtime Tag:
tomcat_4_branch PageContextImpl.java
  Log:
  Fixed 15105: pushBody()/popBody() error on tomcat 4.1.X
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.35.2.15 +3 -4  
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.35.2.14
  retrieving revision 1.35.2.15
  diff -u -r1.35.2.14 -r1.35.2.15
  --- Generator.java8 Jan 2003 22:24:28 -   1.35.2.14
  +++ Generator.java15 Jan 2003 00:20:46 -  1.35.2.15
  @@ -1368,7 +1368,6 @@
// Assume EVAL_BODY_BUFFERED
out.pushIndent();
out.printil("javax.servlet.jsp.tagext.BodyContent _bc = 
pageContext.pushBody();");
  - out.printil("_bc.clear();");
out.printil("out = _bc;");
   
out.printin(tagHandlerVar);
  
  
  
  No   revision
  
  
  No   revision
  
  
  1.11.2.5  +6 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java
  
  Index: PageContextImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
  retrieving revision 1.11.2.4
  retrieving revision 1.11.2.5
  diff -u -r1.11.2.4 -r1.11.2.5
  --- PageContextImpl.java  8 Nov 2002 14:56:44 -   1.11.2.4
  +++ PageContextImpl.java  15 Jan 2003 00:20:46 -  1.11.2.5
  @@ -448,7 +448,10 @@
   newOuts[depth] = new BodyContentImpl(out);
   outs = newOuts;
   }
  +
  + outs[depth].clearBody();
   out = outs[depth];
  +
   return outs[depth];
   }
   
  
  
  

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

DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.X

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

pushBody()/popBody() error on tomcat 4.1.X

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-15 00:20 ---
Ismael,

you've got a valid point there. :)
I just committed a fix for Tomcat 4.1.x.
As I said, this is already fixed in Tomcat 5.

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

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

[costin]

costin  2003/01/14 16:19:16

  Modified:catalina/src/share/org/apache/catalina/core
StandardWrapperValve.java
  Log:
  Collect information about processing time, errors, requestCounts.
  
  Revision  ChangesPath
  1.8   +52 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
  
  Index: StandardWrapperValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- StandardWrapperValve.java 25 Nov 2002 21:03:50 -  1.7
  +++ StandardWrapperValve.java 15 Jan 2003 00:19:16 -  1.8
  @@ -124,6 +124,14 @@
*/
   private FilterDef filterDef = null;
   
  +// Some JMX statistics. This vavle is associated with a StandardWrapper.
  +// We exponse the StandardWrapper as JMX ( j2eeType=Servlet ). The fields
  +// are here for performance.
  +private long processingTime;
  +private long maxTime;
  +private int requestCount;
  +private int errorCount;
  +
   
   /**
* The descriptive information related to this implementation.
  @@ -173,6 +181,9 @@
   // Initialize local variables we may need
   boolean unavailable = false;
   Throwable throwable = null;
  +// This should be a Request attribute...
  +long t1=System.currentTimeMillis();
  +requestCount++;
   StandardWrapper wrapper = (StandardWrapper) getContainer();
   ServletRequest sreq = request.getRequest();
   ServletResponse sres = response.getResponse();
  @@ -354,6 +365,11 @@
   exception(request, response, e);
   }
   }
  +long t2=System.currentTimeMillis();
  +
  +long time=t2-t1;
  +processingTime += time;
  +if( time > maxTime) maxTime=time;
   
   }
   
  @@ -373,7 +389,7 @@
*/
   private void exception(Request request, Response response,
  Throwable exception) {
  -
  +errorCount++;
   ServletRequest sreq = request.getRequest();
   sreq.setAttribute(Globals.EXCEPTION_ATTR, exception);
   
  @@ -435,5 +451,36 @@
   
   }
   
  +public long getProcessingTime() {
  +return processingTime;
  +}
  +
  +public void setProcessingTime(long processingTime) {
  +this.processingTime = processingTime;
  +}
  +
  +public long getMaxTime() {
  +return maxTime;
  +}
  +
  +public void setMaxTime(long maxTime) {
  +this.maxTime = maxTime;
  +}
  +
  +public int getRequestCount() {
  +return requestCount;
  +}
  +
  +public void setRequestCount(int requestCount) {
  +this.requestCount = requestCount;
  +}
  +
  +public int getErrorCount() {
  +return errorCount;
  +}
  +
  +public void setErrorCount(int errorCount) {
  +this.errorCount = errorCount;
  +}
   
   }
  
  
  

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

Re: [4.1.19] New tag

[Glenn Nielsen]

I just committed what looks like the last code bug fix.

But we are working on some minor changes to the manager docs which show examples
using windows URL's and paths in addition to the unix style.  Those minor doc
changes should be in later tonight or tomorrow morning.  I'll let you know when 
we are done.

Regards,

Glenn

Remy Maucherat wrote:
Glenn Nielsen wrote:


OK.

Please hold off for a bit.  We have found 2 more bugs in the manager from
our testing.  Tracking them down now.



BTW, are you done with your bugfixing ?

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: 

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

[glenn]

glenn   2003/01/14 15:28:29

  Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  Fix problems with empty String war parameters/args when using a context xml config
  
  Revision  ChangesPath
  1.32  +8 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- ManagerServlet.java   14 Jan 2003 17:43:47 -  1.31
  +++ ManagerServlet.java   14 Jan 2003 23:28:29 -  1.32
  @@ -591,6 +591,10 @@
   protected void install(PrintWriter writer, String config,
  String path, String war) {
   
  +if (war != null && war.length() == 0) {
  +war = null;
  +}
  +
   if (debug >= 1) {
   if (config != null && config.length() > 0) {
   if (war != null) {
  
  
  

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

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

[luehe]

luehe   2003/01/14 15:14:58

  Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
  Log:
  Visit subnodes of UninterpretedTag during validation
  
  Revision  ChangesPath
  1.67  +5 -3  
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.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- Validator.java14 Jan 2003 22:32:58 -  1.66
  +++ Validator.java14 Jan 2003 23:14:58 -  1.67
  @@ -660,6 +660,8 @@
   if (n.getNamedAttributeNodes().size() != 0) {
err.jspError(n, "jsp.error.namedAttribute.invalidUse");
   }
  +
  + visitBody(n);
   }
   
public void visit(Node.CustomTag n) throws JasperException {
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/memory MemoryProtocolHandler.java

[remm]

remm2003/01/14 15:08:10

  Added:   coyote/src/java/org/apache/coyote/memory
MemoryProtocolHandler.java
  Log:
  - Add (untested) memory protocol handler.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/memory/MemoryProtocolHandler.java
  
  Index: MemoryProtocolHandler.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */ 
  package org.apache.coyote.memory;
  
  import java.io.IOException;
  
  import org.apache.tomcat.util.buf.ByteChunk;
  
  import org.apache.coyote.Adapter;
  import org.apache.coyote.InputBuffer;
  import org.apache.coyote.OutputBuffer;
  import org.apache.coyote.ProtocolHandler;
  import org.apache.coyote.Request;
  import org.apache.coyote.Response;
  
  
  /**
   * Abstract the protocol implementation, including threading, etc.
   * Processor is single threaded and specific to stream-based protocols,
   * will not fit Jk protocols like JNI.
   *
   * @author Remy Maucherat
   */
  public class MemoryProtocolHandler
  implements ProtocolHandler {
  
  
  // - Properties
  
  
  /**
   * Pass config info.
   */
  public void setAttribute(String name, Object value) {
  }
  
  public Object getAttribute(String name) {
  return null;
  }
  
  
  /**
   * Associated adapter.
   */
  protected Adapter adapter = null;
  
  /**
   * The adapter, used to call the connector.
   */
  public void setAdapter(Adapter adapter) {
  this.adapter = adapter;
  }
  
  public Adapter getAdapter() {
  return (adapter);
  }
  
  
  //  ProtocolHandler Methods
  
  
  /**
   * Init the protocol.
   */
  public void init()
  throws Exception {
  }
  
  
  /**
   * Start the protocol.
   */
  public void start()
  throws Exception {
  }
  
  
  public void destroy()
  throws Exception {
  }
  
  
  // 

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/memory - New directory

[remm]

remm2003/01/14 15:06:58

  jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/memory - New directory

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

Re: [4.1.19] New tag

[Remy Maucherat]

Glenn Nielsen wrote:

OK.

Please hold off for a bit.  We have found 2 more bugs in the manager from
our testing.  Tracking them down now.


BTW, are you done with your bugfixing ?

Remy


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

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

[remm]

remm2003/01/14 14:41:01

  Modified:catalina/src/share/org/apache/catalina/startup Embedded.java
  Log:
  - Oops.
  
  Revision  ChangesPath
  1.4   +7 -16 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Embedded.java
  
  Index: Embedded.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- Embedded.java 14 Jan 2003 22:39:42 -  1.3
  +++ Embedded.java 14 Jan 2003 22:41:01 -  1.4
  @@ -1140,18 +1140,6 @@
new MemoryRealm());
   embedded.setDebug(5);
   embedded.setLogger(new SystemOutLogger());
  -/*
  -String home = System.getProperty("catalina.home");
  -if (home == null) {
  -System.err.println("You must set the 'catalina.home' system property");
  -System.exit(1);
  -}
  -String base = System.getProperty("catalina.base");
  -if (base == null) {
  -base = home;
  -System.setProperty("catalina.base", base);
  -}
  -*/
   
   // Start up this embedded server (to prove we can dynamically
   // add and remove containers and connectors later)
  @@ -1161,6 +1149,9 @@
   System.err.println("start: " + e.toString());
   e.printStackTrace();
   }
  +
  +String home = System.getProperty("catalina.home");
  +String base = System.getProperty("catalina.base");
   
   // Assemble and install a very basic container hierarchy
   // that simulates a portion of the one configured in server.xml
  
  
  

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

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

[remm]

remm2003/01/14 14:39:43

  Modified:catalina/src/share/org/apache/catalina/startup Embedded.java
  Log:
  - Update connectors section.
  - Beautify.
  
  Revision  ChangesPath
  1.3   +35 -31
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Embedded.java
  
  Index: Embedded.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Embedded.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Embedded.java 5 Dec 2002 15:53:57 -   1.2
  +++ Embedded.java 14 Jan 2003 22:39:42 -  1.3
  @@ -541,7 +541,7 @@
   try {
   
   Class clazz = 
  -Class.forName("org.apache.coyote.tomcat4.CoyoteConnector");
  +Class.forName("org.apache.coyote.tomcat5.CoyoteConnector");
   connector = (Connector) clazz.newInstance();
   
   if (address != null) {
  @@ -549,19 +549,21 @@
  "" + address);
   }
   IntrospectionUtils.setProperty(connector, "port", "" + port);
  -IntrospectionUtils.setProperty(connector, "useURIValidationHack", 
  -   "" + false);
   
   if (protocol.equals("ajp")) {
   IntrospectionUtils.setProperty
   (connector, "protocolHandlerClassName",
"org.apache.jk.server.JkCoyoteHandler");
  +} else if (protocol.equals("memory")) {
  +IntrospectionUtils.setProperty
  +(connector, "protocolHandlerClassName",
  + "org.apache.coyote.memory.MemoryProtocolHandler");
   } else if (protocol.equals("https")) {
   connector.setScheme("https");
   connector.setSecure(true);
   try {
   Class serverSocketFactoryClass = Class.forName
  -("org.apache.coyote.tomcat4.CoyoteServerSocketFactory");
  +   ("org.apache.coyote.tomcat5.CoyoteServerSocketFactory");
   ServerSocketFactory factory = 
   (ServerSocketFactory) 
   serverSocketFactoryClass.newInstance();
  @@ -1052,6 +1054,7 @@
   
   // -- Protected Methods
   
  +
   /** Initialize naming - this should only enable java:env and root naming.
* If tomcat is embeded in an application that already defines those -
* it shouldn't do it.
  @@ -1085,37 +1088,36 @@
   }
   }
   
  +
   protected void initDirs() {
  -String catalinaHome=System.getProperty("catalina.home");
  -if ( catalinaHome== null) {
  +
  +String catalinaHome = System.getProperty("catalina.home");
  +if (catalinaHome == null) {
   // Backwards compatibility patch for J2EE RI 1.3
   String j2eeHome = System.getProperty("com.sun.enterprise.home");
  -if (j2eeHome != null)
  +if (j2eeHome != null) {
   catalinaHome=System.getProperty("com.sun.enterprise.home");
  -else if( System.getProperty("catalina.base") !=null ) {
  -catalinaHome=System.getProperty("catalina.base" );
  +} else if (System.getProperty("catalina.base") != null) {
  +catalinaHome = System.getProperty("catalina.base");
   } else {
  -// Original embeded behavior
  -//throw new LifecycleException
  -//("Must set 'catalina.home' system property");
  -// Catalina behavior
  -//System.setProperty("catalina.home",
  -//System.getProperty("user.dir"));
  -// use IntrospectionUtils and guess the dir
  -catalinaHome=IntrospectionUtils.guessInstall("catalina.home",
  -   "catalina.base","catalina.jar");
  -if( catalinaHome==null)
  -catalinaHome=IntrospectionUtils.guessInstall("tomcat.install",
  -   "catalina.home","tomcat.jar");
  -
  +// Use IntrospectionUtils and guess the dir
  +catalinaHome = IntrospectionUtils.guessInstall
  +("catalina.home", "catalina.base", "catalina.jar");
  +if (catalinaHome == null) {
  +catalinaHome = IntrospectionUtils.guessInstall
  +("tomcat.install", "catalina.home", "tomcat.jar");
  +}
   }
   }
  -if( catalinaHome!=null )
  -System.setProperty( "catalin.home", catalinaHome);
  +if (catalinaHome != null) {
  

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

[luehe]

luehe   2003/01/14 14:32:59

  Modified:jasper2/src/share/org/apache/jasper/compiler Node.java
Validator.java
  Log:
  Fixed 16077: Invalid error generated when translating a valid JSP document
  
  Revision  ChangesPath
  1.54  +6 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
  
  Index: Node.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java,v
  retrieving revision 1.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- Node.java 11 Jan 2003 00:52:14 -  1.53
  +++ Node.java 14 Jan 2003 22:32:58 -  1.54
  @@ -195,6 +195,9 @@
   /**
* Searches all subnodes of this node for jsp:attribute standard
* actions, and returns that set of nodes as a Node.Nodes object.
  + *
  + * @return Possibly empty Node.Nodes object containing any jsp:attribute
  + * subnodes of this Node
*/
   public Node.Nodes getNamedAttributeNodes() {
   
  
  
  
  1.66  +4 -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.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- Validator.java8 Jan 2003 18:42:43 -   1.65
  +++ Validator.java14 Jan 2003 22:32:58 -  1.66
  @@ -657,7 +657,7 @@
   }
   
public void visit(Node.UninterpretedTag n) throws JasperException {
  -if (n.getNamedAttributeNodes() != null) {
  +if (n.getNamedAttributeNodes().size() != 0) {
err.jspError(n, "jsp.error.namedAttribute.invalidUse");
   }
   }
  
  
  

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

DO NOT REPLY [Bug 16077] - Invalid error generated when translating a valid JSP document

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

Invalid error generated when translating a valid JSP document

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Jeanfrancois Arcand]

Costin Manolache wrote:


I don't know if we can get consensus or not - but IMO this is
the right solution, and I'm not going  to look for another one.
I decided to make this proposal - to get this out of my 
list.

Hope your list is not too big :-)



Tomcat is composed of multiple components. We agreed that JMX is
the right way to configure and manage the components. The proposal
is to use JMX notifications to consolidate all callback and extension 
mechanisms.

+1


 


The only exception will be Valve - where the calling mechanism 
just doesn't fit and the effort and changes will be too big. Valve
will remain unchanged - but for any new modules and as we optimize/enhance
existing modules we should switch to notifications. 

I will give a try with the valve also. What we have to change is 
StandardPipeline, ValveBase and ValveContext to use the 
NotificationListener mechanism (simplification). Does I'm missing 
something here? If not, I can make the change to see how it goes (on a 
separate branch for sure).


Coyote ActionHook and JkHandler will be deprecated and replaced witht the 
NotificationListener interface. The current parameters will be passed 
in the Notification subclass ( we can reuse the same notification object - 
one per Request object ). Small refactorings will be needed - but I don't
think it'll destabilize the code too much.

I don't expect this to destabilize the code too much - but if we decide to 
do that, a branch may be a good idea.

+1



Please post your opinion - and if you are interested to help doing it.


Yes, I'm interested to help, but not as my first task.



I posted some more notes on my weblog ( which I just started few days ago ),
and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).


I prefer the mailling list, and if I have to do one, I will do it in 
french since most of us understand french (oups...againt the souveranist 
Quebecois dream that come back :-) )

-- Jeanfrancois


Costin


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


 



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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Remy Maucherat]

Costin Manolache wrote:

Glenn Nielsen wrote:



I have one general comment.  For security I would like to see two
different
MBeanServers used.  One for config management the other for runtime
monitoring. This way you could implement diffrent access controls for
config management
from runtime  monitoring.



That's one concern I have with JMX - there is some protection using 
the Policy ( in JMX1.2 ), but if you don't run the sandbox you're 
on your own.

All JMX implementations seem to support some "interceptors" and we can
try to implement our own add-on scheme ( not sure if Sun RI extensions are
documented or exist - but MX4J and Jboss provide that ). 

I'm afraid using 2 MBeanServers is not the best solution - if we put the
mbean server in the parent loader, I'm pretty sure user code will be able 
to get it ( if it wants to ). And the code can become very complicated. 

You know my opinion on this - if you don't run the sandbox, user code can 
control the VM without problems ( with some JNI code - or introspection,
or by overriding files ). If you run sandbox - the JMX1.2 policy-based 
access control should be good enough.

Great that they added those features. Having 2 MBean servers would be 
quite complex, so I think Costin is right, and we should rely on the 
security manager.

Remy


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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteConnector.java

[remm]

remm2003/01/14 13:50:41

  Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteConnector.java
  Log:
  - Add an accessor for the protocol handler.
  
  Revision  ChangesPath
  1.8   +14 -4 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java
  
  Index: CoyoteConnector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteConnector.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- CoyoteConnector.java  23 Dec 2002 01:35:09 -  1.7
  +++ CoyoteConnector.java  14 Jan 2003 21:50:41 -  1.8
  @@ -688,6 +688,16 @@
   
   
   /**
  + * Return the protocol handler associated with the connector.
  + */
  +public ProtocolHandler getProtocolHandler() {
  +
  +return (this.protocolHandler);
  +
  +}
  +
  +
  +/**
* Return the proxy server name for this Connector.
*/
   public String getProxyName() {
  
  
  

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

DO NOT REPLY [Bug 16077] - Invalid error generated when translating a valid JSP document

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

Invalid error generated when translating a valid JSP document





--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 21:51 ---
Woke up a bit and noticed that the line the translator is complaining about in
all my cases is the  element with the jsp namespace declaration.

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

DO NOT REPLY [Bug 16077] - Invalid error generated when translating a valid JSP document

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

Invalid error generated when translating a valid JSP document





--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 21:49 ---
*** Bug 16079 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 16079] - Jasper incorrectly flags nested within an element as an error.

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

Jasper incorrectly flags  nested within an  element as an 
error.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 21:49 ---


*** This bug has been marked as a duplicate of 16077 ***

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

DO NOT REPLY [Bug 16079] New: - Jasper incorrectly flags nested within an element as an error.

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

Jasper incorrectly flags  nested within an  element as an 
error.

   Summary: Jasper incorrectly flags  nested within
an  element as an error.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Given the following JSP 2.0 document:


http://java.sun.com/JSP/Page";>




greetings

Hello World


---

The following error message is generated:
  
"jsp:attribute must be a sublement of a standard or custom action"

The interesting thing about the error message is that the line that it's
complaining about is the  element with the namespace declaration.

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

DO NOT REPLY [Bug 16078] New: - Request parameter aggregation when using is no longer working as expected.

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

Request parameter aggregation when using  is no longer working as expected. 

   Summary: Request parameter aggregation when using  is
no longer working as expected.
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Given the following request line:

GET /test.jsp?param1=value1 HTTP/1.1

test.jsp
---




---

resource.jsp
-
<%@ page contentType="text/plain" %>
<%
String[] param1Values = request.getParameterValues("param1");
String[] param2Values = request.getParameterValues("param2");
for (int i = 0; i < param1Values.length; i++) {
out.println("PARAM1 VALUE: " + param1Values[i]);
}
for (int i = 0; i < param2Values.length; i++) {
out.println("PARAM2 VALUE: " + param2Values[i]);
}

%>


When checking the values of the request parameters in resource.jsp,
param1 has value2,value2,value1 as values instead of value2,value1.
param2 has value2,value2 as values instead of just value2.

This worked properly in previous builds.

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

DO NOT REPLY [Bug 16077] New: - Invalid error generated when translating a valid JSP document

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

Invalid error generated when translating a valid JSP document

   Summary: Invalid error generated when translating a valid JSP
document
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Given the following simple JSP 2.0 Document:

http://java.sun.com/JSP/Page";>




The following error message is now returned with the latest nightly build:

  "jsp:attribute must be the subelement of a standard or custom action"

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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Costin Manolache]

Glenn Nielsen wrote:

> I have one general comment.  For security I would like to see two
> different
> MBeanServers used.  One for config management the other for runtime
> monitoring. This way you could implement diffrent access controls for
> config management
> from runtime  monitoring.

That's one concern I have with JMX - there is some protection using 
the Policy ( in JMX1.2 ), but if you don't run the sandbox you're 
on your own.

All JMX implementations seem to support some "interceptors" and we can
try to implement our own add-on scheme ( not sure if Sun RI extensions are
documented or exist - but MX4J and Jboss provide that ). 

I'm afraid using 2 MBeanServers is not the best solution - if we put the
mbean server in the parent loader, I'm pretty sure user code will be able 
to get it ( if it wants to ). And the code can become very complicated. 

You know my opinion on this - if you don't run the sandbox, user code can 
control the VM without problems ( with some JNI code - or introspection,
or by overriding files ). If you run sandbox - the JMX1.2 policy-based 
access control should be good enough.

Costin


> 
> Glenn
> 
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>> 
>> 
>>>This looks fine. Do I get some sample code before voting, so I can see
>>>the thing in action ?
>> 
>> 
>> I'm working on converting Jk to Listeners.
>> 
>> I want to first check in some changes to enable the "what is each thread
>> doing" feature - but that would add the dependency to JMX.
>> 
>> Time for a branch...
>> 
>> Should I do the changes in a branch, or branch the current stable code
>> and make changes in HEAD ?
>> 
>> 
>> 
I posted some more notes on my weblog ( which I just started few days
ago ), and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).
>>>
>>>Arg, you fell for blogging ! ;-P
>>>I'm not going to (although I do enjoy reading blogs): discussions should
>>>stay on the mailing lists, which do have centralized archives. If lists
>>>get more quiet because of blogging, then it's good (less emails to read
>>>every day :-D ).
>> 
>> 
>> I have a feeling the blogging is already affecting the lists. And it
>> certainly helps organize yourself - that was the main argument for me.
>> 
>> Are other tomcat developers blogging ? Should we keep a list - maybe in
>> wiki ?
>> 
>> It would be nice to be able to take all blogs about tomcat and feed them
>> into the list ( I have a category for tocmat and one for ant - but I
>> don't know too much about blogging yet ).
>> 
>> 
>> Costin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:  
>>  For additional
>> commands, e-mail: 
> 
> 



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

DO NOT REPLY [Bug 16075] New: - CATALINA_BASE defined for Multiple Tomcat 4 Instances causes "admin" to fail

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

CATALINA_BASE defined for Multiple Tomcat 4 Instances causes "admin" to fail

   Summary: CATALINA_BASE defined for Multiple Tomcat 4 Instances
causes "admin" to fail
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using Multiple Tomcat 4 Instances by defining
CATALINA_BASE different than CATALINA_HOME, the
/admin application fails. The reported error involves
loading of WEB-INF/lib/struts.jar. If the jar is
expanded into the WEB-INF/classes directory and deleted
from the lib directory, the /admin application works.

Any jar file in WEB-INF/lib/xxx.jar causes the
application to fail. (e.g. add any jar to the /manager
application, and that application will fail.

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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Glenn Nielsen]

I have one general comment.  For security I would like to see two different
MBeanServers used.  One for config management the other for runtime monitoring.
This way you could implement diffrent access controls for config management
from runtime  monitoring.

Glenn

Costin Manolache wrote:

Remy Maucherat wrote:



This looks fine. Do I get some sample code before voting, so I can see
the thing in action ?



I'm working on converting Jk to Listeners.

I want to first check in some changes to enable the "what is each thread 
doing" feature - but that would add the dependency to JMX.

Time for a branch...

Should I do the changes in a branch, or branch the current stable code and
make changes in HEAD ?



I posted some more notes on my weblog ( which I just started few days ago
), and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).


Arg, you fell for blogging ! ;-P
I'm not going to (although I do enjoy reading blogs): discussions should
stay on the mailing lists, which do have centralized archives. If lists
get more quiet because of blogging, then it's good (less emails to read
every day :-D ).



I have a feeling the blogging is already affecting the lists. And it 
certainly helps organize yourself - that was the main argument for me.

Are other tomcat developers blogging ? Should we keep a list - maybe in
wiki ? 

It would be nice to be able to take all blogs about tomcat and feed them 
into the list ( I have a category for tocmat and one for ant - but I don't
know too much about blogging yet ).


Costin







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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Remy Maucherat]

Costin Manolache wrote:

Remy Maucherat wrote:



This looks fine. Do I get some sample code before voting, so I can see
the thing in action ?



I'm working on converting Jk to Listeners.

I want to first check in some changes to enable the "what is each thread 
doing" feature - but that would add the dependency to JMX.

Time for a branch...

Should I do the changes in a branch, or branch the current stable code and
make changes in HEAD ?

The policy has been to make the changes in HEAD.
Tomcat 4.1.x will of course integrate the stable code in the branch.

I reread that part of the JMX API, and I think I am +1 (it does the same 
as the current action mechanism).

I posted some more notes on my weblog ( which I just started few days ago
), and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).


Arg, you fell for blogging ! ;-P
I'm not going to (although I do enjoy reading blogs): discussions should
stay on the mailing lists, which do have centralized archives. If lists
get more quiet because of blogging, then it's good (less emails to read
every day :-D ).



I have a feeling the blogging is already affecting the lists. And it 
certainly helps organize yourself - that was the main argument for me.

Ah, ok. Well, I *do* have some post its lying around somewhere (like 
some random design ideas for the new mapper, most of which are bad, of 
course ;-) ). Is there any use in making my post its public ?

Are other tomcat developers blogging ? Should we keep a list - maybe in
wiki ? 

It would be nice to be able to take all blogs about tomcat and feed them 
into the list ( I have a category for tocmat and one for ant - but I don't
know too much about blogging yet ).

Nice way to force me to blog ;-)

Remy


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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Costin Manolache]

Remy Maucherat wrote:

> This looks fine. Do I get some sample code before voting, so I can see
> the thing in action ?

I'm working on converting Jk to Listeners.

I want to first check in some changes to enable the "what is each thread 
doing" feature - but that would add the dependency to JMX.

Time for a branch...

Should I do the changes in a branch, or branch the current stable code and
make changes in HEAD ?


>> I posted some more notes on my weblog ( which I just started few days ago
>> ), and I'll update it with more details.
>> See http://www.webweavertech.com/costin/weblog/index.html
>> and http://www.webweavertech.com/costin/archives/000152.html
>> ( I'm just getting started with the blogging :-).
> 
> Arg, you fell for blogging ! ;-P
> I'm not going to (although I do enjoy reading blogs): discussions should
> stay on the mailing lists, which do have centralized archives. If lists
> get more quiet because of blogging, then it's good (less emails to read
> every day :-D ).

I have a feeling the blogging is already affecting the lists. And it 
certainly helps organize yourself - that was the main argument for me.

Are other tomcat developers blogging ? Should we keep a list - maybe in
wiki ? 

It would be nice to be able to take all blogs about tomcat and feed them 
into the list ( I have a category for tocmat and one for ant - but I don't
know too much about blogging yet ).


Costin







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

Re: PROPOSAL/VOTE: JMX hook mechanism

[Remy Maucherat]

Costin Manolache wrote:

I don't know if we can get consensus or not - but IMO this is
the right solution, and I'm not going  to look for another one.
I decided to make this proposal - to get this out of my 
list.

Tomcat is composed of multiple components. We agreed that JMX is
the right way to configure and manage the components. The proposal
is to use JMX notifications to consolidate all callback and extension 
mechanisms.

The only exception will be Valve - where the calling mechanism 
just doesn't fit and the effort and changes will be too big. Valve
will remain unchanged - but for any new modules and as we optimize/enhance
existing modules we should switch to notifications. 

Coyote ActionHook and JkHandler will be deprecated and replaced witht the 
NotificationListener interface. The current parameters will be passed 
in the Notification subclass ( we can reuse the same notification object - 
one per Request object ). Small refactorings will be needed - but I don't
think it'll destabilize the code too much.

I don't expect this to destabilize the code too much - but if we decide to 
do that, a branch may be a good idea.

Please post your opinion - and if you are interested to help doing it.

This looks fine. Do I get some sample code before voting, so I can see 
the thing in action ?

I think this should lead to a branch (where we put the current code in a 
"COYOTE_1" branch) and Coyote 2.0.

I posted some more notes on my weblog ( which I just started few days ago ),
and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).


Arg, you fell for blogging ! ;-P
I'm not going to (although I do enjoy reading blogs): discussions should 
stay on the mailing lists, which do have centralized archives. If lists 
get more quiet because of blogging, then it's good (less emails to read 
every day :-D ).

Remy


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

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

[costin]

costin  2003/01/14 10:47:39

  Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
ThreadPoolMX.java
  Log:
  Pass the domain.
  ThreadPools should be registered in the same domain with all catalina
  mbeans.
  
  Revision  ChangesPath
  1.9   +1 -1  
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.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- ThreadPool.java   12 Jan 2003 19:07:07 -  1.8
  +++ ThreadPool.java   14 Jan 2003 18:47:39 -  1.9
  @@ -171,7 +171,7 @@
   return new ThreadPool();
   }
   
  -public void register( String name ) {
  +public void register( String domain, String name ) {
   // nothing in the base class - it'll register in jmx mode
   // We could use the name to create a ThreadGroup and name threads
   }
  
  
  
  1.3   +2 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoolMX.java
  
  Index: ThreadPoolMX.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPoolMX.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ThreadPoolMX.java 12 Jan 2003 19:07:07 -  1.2
  +++ ThreadPoolMX.java 14 Jan 2003 18:47:39 -  1.3
  @@ -81,8 +81,9 @@
   super();
   }
   
  -public void register(String name) {
  +public void register(String domain, String name) {
   this.name=name;
  +this.domain=domain;
   reg=Registry.getRegistry();
   try {
   reg.registerComponent(this, domain, "ThreadPool",  name);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote BaseHook.java

[costin]

costin  2003/01/14 10:46:25

  Removed: coyote/src/java/org/apache/coyote BaseHook.java
  Log:
  Rollback...
  
  A much better solution is to just use plain NotificationListener, without
  any tomcat/coyote/jk-specific modifications.
  
  All JK and coyote hooks ( "extension points" ) work fine with the Notification
  model - there is no need for the recursive call. In the processing phase
  we can just use the Valves ( eventually plugged in using a ValveNotificationListener 
).

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

PROPOSAL/VOTE: JMX hook mechanism

[Costin Manolache]

I don't know if we can get consensus or not - but IMO this is
the right solution, and I'm not going  to look for another one.
I decided to make this proposal - to get this out of my 
list.

Tomcat is composed of multiple components. We agreed that JMX is
the right way to configure and manage the components. The proposal
is to use JMX notifications to consolidate all callback and extension 
mechanisms.

The only exception will be Valve - where the calling mechanism 
just doesn't fit and the effort and changes will be too big. Valve
will remain unchanged - but for any new modules and as we optimize/enhance
existing modules we should switch to notifications. 

Coyote ActionHook and JkHandler will be deprecated and replaced witht the 
NotificationListener interface. The current parameters will be passed 
in the Notification subclass ( we can reuse the same notification object - 
one per Request object ). Small refactorings will be needed - but I don't
think it'll destabilize the code too much.

I don't expect this to destabilize the code too much - but if we decide to 
do that, a branch may be a good idea.

Please post your opinion - and if you are interested to help doing it.

I posted some more notes on my weblog ( which I just started few days ago ),
and I'll update it with more details.
See http://www.webweavertech.com/costin/weblog/index.html
and http://www.webweavertech.com/costin/archives/000152.html
( I'm just getting started with the blogging :-).

Costin


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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf ByteChunk.java CharChunk.java

[remm]

remm2003/01/14 10:20:02

  Modified:util/java/org/apache/tomcat/util/buf ByteChunk.java
CharChunk.java
  Log:
  - Add alternate substract methods.
  
  Revision  ChangesPath
  1.13  +22 -0 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java
  
  Index: ByteChunk.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- ByteChunk.java5 Jan 2003 11:22:16 -   1.12
  +++ ByteChunk.java14 Jan 2003 18:20:02 -  1.13
  @@ -377,6 +377,8 @@
   throws IOException {
   
   if ((end - start) == 0) {
  +if (in == null)
  +return -1;
   int n = in.realReadBytes( buff, 0, buff.length );
   if (n < 0)
   return -1;
  @@ -386,10 +388,30 @@
   
   }
   
  +public int substract(ByteChunk src)
  +throws IOException {
  +
  +if ((end - start) == 0) {
  +if (in == null)
  +return -1;
  +int n = in.realReadBytes( buff, 0, buff.length );
  +if (n < 0)
  +return -1;
  +}
  +
  +int len = getLength();
  +src.append(buff, start, len);
  +start = end;
  +return len;
  +
  +}
  +
   public int substract( byte src[], int off, int len )
   throws IOException {
   
   if ((end - start) == 0) {
  +if (in == null)
  +return -1;
   int n = in.realReadBytes( buff, 0, buff.length );
   if (n < 0)
   return -1;
  
  
  
  1.6   +22 -0 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java
  
  Index: CharChunk.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CharChunk.java5 Jan 2003 11:22:16 -   1.5
  +++ CharChunk.java14 Jan 2003 18:20:02 -  1.6
  @@ -403,6 +403,8 @@
   throws IOException {
   
   if ((end - start) == 0) {
  +if (in == null)
  +return -1;
   int n = in.realReadChars(buff, 0, buff.length);
   if (n < 0)
   return -1;
  @@ -412,10 +414,30 @@
   
   }
   
  +public int substract(CharChunk src)
  +throws IOException {
  +
  +if ((end - start) == 0) {
  +if (in == null)
  +return -1;
  +int n = in.realReadChars( buff, 0, buff.length );
  +if (n < 0)
  +return -1;
  +}
  +
  +int len = getLength();
  +src.append(buff, start, len);
  +start = end;
  +return len;
  +
  +}
  +
   public int substract( char src[], int off, int len )
   throws IOException {
   
   if ((end - start) == 0) {
  +if (in == null)
  +return -1;
   int n = in.realReadChars( buff, 0, buff.length );
   if (n < 0)
   return -1;
  
  
  

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

DO NOT REPLY [Bug 16044] - problems with gifs and jpegs - HTML are ok

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

problems with gifs and jpegs - HTML are ok





--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 18:15 ---
also am having difficulties with jsps.  However, I can compile them without any 
problems.

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

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

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

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 18:08 ---
*** Bug 16071 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 16071] - release method not called in taglib life-cycle

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

release method not called in taglib life-cycle

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 18:08 ---


*** This bug has been marked as a duplicate of 16001 ***

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

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

[glenn]

glenn   2003/01/14 09:44:47

  Modified:catalina/src/share/org/apache/catalina/startup
ExpandWar.java
  Log:
  Fix zip file closed bug
  
  Revision  ChangesPath
  1.2   +6 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ExpandWar.java
  
  Index: ExpandWar.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ExpandWar.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ExpandWar.java10 Jan 2003 15:52:18 -  1.1
  +++ ExpandWar.java14 Jan 2003 17:44:47 -  1.2
  @@ -227,7 +227,8 @@
   input.close();
   input = null;
   }
  -jarFile.close();
  +// FIXME - Closing the JAR file messes up the class loader???
  +//jarFile.close();
   jarFile = null;
   } finally {
   if (input != null) {
  
  
  

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

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

[glenn]

glenn   2003/01/14 09:43:48

  Modified:catalina/src/share/org/apache/catalina/servlets
ManagerServlet.java
  Log:
  Fix creation of context path for local war
  
  Revision  ChangesPath
  1.31  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- ManagerServlet.java   10 Jan 2003 15:52:18 -  1.30
  +++ ManagerServlet.java   14 Jan 2003 17:43:47 -  1.31
  @@ -669,7 +669,7 @@
   end -= 2;
   }
   if (filename.endsWith(".war")) {
  -filename = filename.substring(0,filename.length()-2);
  +filename = filename.substring(0,filename.length()-4);
   end -= 4;
   }
   if (filename.endsWith("/")) {
  
  
  

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

DO NOT REPLY [Bug 15894] - Access to other sessions possible (session is immediately recycled after invalidation/expiration)

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

Access to other sessions possible (session is immediately recycled after 
invalidation/expiration)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 17:22 ---
Hello William,

Thanks for your fast reaction to my error report. I especially like that you 
use two states now for EXPIRED and INVALID.
You fixed my problem by checking in request.getSession whether the session has 
still the same sessionId. This works if the servlet/JSP uses request.getSession 
before it uses the session.
However, if you remove the line with
  s = request.getSession(true); 
(the one after sleep(5000);
of my the example JSP you still get the same mistake. That why reopened the bug 
again.
This problem is not just theoretical. The problem occurs when the client klicks 
many times without waiting for the server to deliver the page. If a normal 
request and a log-off request is processed simultaneous, the normal request 
will always read and write into the session of somebody else who logged in 
meantime.
I see four solutions to this problem:
1. we delay the state change from EXPIRED to INVALID. With delay I mean to wait 
couple (e.g. 60) seconds. The state change from EXPIRED to INVALID could be 
either done by the Expirer or elsewhere.
2. we check on every access from HttpSessionFacade to ServerSession that we 
still have the right session as you did in request.getSession. We could do it 
in HttpSessionFacade.checkValid() for those methods who call it.
3. we register the HttpSessionFacade as listener for state change of the 
session. When the session gets expired we delete the reference session.
We would have to check on session != null every time we use it.
4. We set session to null in HttpSessionFacade.invalidate. The rest is like (3).
The problem here is that it only works if the session is invalidated through 
HttpSessionFacade.invalidate, but this should be ok.
If you need my help for any solution, please let me know.

Do you know by chance, how soon tomcat 3.3.2 will be released?
Thanks a lot,
Christian

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

DO NOT REPLY [Bug 16071] New: - release method not called in taglib life-cycle

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

release method not called in taglib life-cycle

   Summary: release method not called in taglib life-cycle
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The method release of a custom tag is not called from JSP engine.

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ProtocolHandler.java

[remm]

remm2003/01/14 08:49:45

  Modified:coyote/src/java/org/apache/coyote ProtocolHandler.java
  Log:
  - Remove unneeded imports.
  
  Revision  ChangesPath
  1.4   +0 -4  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ProtocolHandler.java
  
  Index: ProtocolHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ProtocolHandler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ProtocolHandler.java  16 May 2002 18:57:39 -  1.3
  +++ ProtocolHandler.java  14 Jan 2003 16:49:45 -  1.4
  @@ -58,10 +58,6 @@
*/ 
   package org.apache.coyote;
   
  -import java.io.InputStream;
  -import java.io.IOException;
  -import java.io.OutputStream;
  -
   
   /**
* Abstract the protocol implementation, including threading, etc.
  
  
  

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

Re: [4.1.19] New tag

[Glenn Nielsen]

OK.

Please hold off for a bit.  We have found 2 more bugs in the manager from
our testing.  Tracking them down now.

Glenn

Remy Maucherat wrote:

Glenn Nielsen wrote:


One concern I have for Tomcat 4.1 is that the recent changes Costin 
has made
to j-t-c may have made JMX required for Tomcat 4.1, this should be
checked before doing a release.


The file which needs JMX is independent, and won't be compiled for 4.1.x.

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: 

Re: Coyote in memory connector

[Remy Maucherat]

jean-frederic clere wrote:

Remy Maucherat wrote:


jean-frederic clere wrote:


Remy Maucherat wrote:


Hi,

It would be easy to add an in-memory Java connector using the Coyote 
API, which could be used for embedding in IDEs or other embedded 
environments. This avoids the overhead of network I/O and additional 
bloat created by having a HTTP client/server in such an environment.

Comments ?




And mod_jk2 Channel that uses in-memory.




I don't know how it works. Could you give more details about what it 
does ?


I was thinking to the Shm or Shm14 classes.


Here, I was planning to write a barebones memory based protocol 
handler (but for Java only, no JNI invloved). If JK 2 does the job, 
then there's no need for it, obviously.


No exacly... But it is possible to have a big byte[] and read the AJP 
protocol from it (I already have something that does this for a Tomcat 
embedded in a transaction monitor) the response is written to a 
ByteArrayOutputStream.

It's not quite the same, then. Here, you'd have the protocol handler 
which would do nothing until the user calls a process(Request, Response) 
method (and then just call the Adapter's service method), with 
ByteChunks to handle input/output (now that you can actually read from 
them, I'm going to abuse the feature).
So no parsing is involved at all (except for the URI), and the client 
API stays simple, as there's no need to generate an AJP request.

It's likely extremely easy to write (likely a couple hours to actually 
do it), so I'm going to do it, and see where I end up.

Remy


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

Re: [4.1.19] New tag

[Remy Maucherat]

Glenn Nielsen wrote:

One concern I have for Tomcat 4.1 is that the recent changes Costin has 
made
to j-t-c may have made JMX required for Tomcat 4.1, this should be
checked before doing a release.

The file which needs JMX is independent, and won't be compiled for 4.1.x.

Remy


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

Re: [4.1.19] New tag

[Glenn Nielsen]

One concern I have for Tomcat 4.1 is that the recent changes Costin has made
to j-t-c may have made JMX required for Tomcat 4.1, this should be
checked before doing a release.

Other than that, yeah, lets do a release and call it alpha.

Glenn

Remy Maucherat wrote:

Lots of useful changes were made since 4.1.18, so IMO it is time to tag 
4.1.19.
I plan to tag it late today.

Comments ?

Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

Re: Coyote in memory connector

[jean-frederic clere]

Remy Maucherat wrote:

jean-frederic clere wrote:


Remy Maucherat wrote:


Hi,

It would be easy to add an in-memory Java connector using the Coyote 
API, which could be used for embedding in IDEs or other embedded 
environments. This avoids the overhead of network I/O and additional 
bloat created by having a HTTP client/server in such an environment.

Comments ?



And mod_jk2 Channel that uses in-memory.



I don't know how it works. Could you give more details about what it does ?


I was thinking to the Shm or Shm14 classes.


Here, I was planning to write a barebones memory based protocol handler 
(but for Java only, no JNI invloved). If JK 2 does the job, then there's 
no need for it, obviously.

No exacly... But it is possible to have a big byte[] and read the AJP protocol 
from it (I already have something that does this for a Tomcat embedded in a 
transaction monitor) the response is written to a ByteArrayOutputStream.


Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 






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

DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name

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

Resubmit to j_security_check mistakenly fetches a page of that name

[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.0.3 Final |Nightly Build



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 14:58 ---
In the forlorn hope that this fix will get incorporated ;) , this latest patch
makes the forwarding behaviour that fixes the bug optional. You can demonstrate
this by adding this to the examples context in server.xml:


And trying the security sample,
http://localhost:8080/examples/jsp/security/protected

NB This patch doesn't change the default (broken) behaviour of tomcat, so
hopefully that removes previous objections to the use of forwarding for the
login page.

In order to sweeten the pill, the patch also documents this option and Bill
Barker's proxyCaching fix, along with the other authentication valve options.

C'mon guys you know you want it...

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

DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name

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

Resubmit to j_security_check mistakenly fetches a page of that name





--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 14:50 ---
Created an attachment (id=4417)
patch making fix optional plus documentation of Authenticator valves

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

Sharing objects between virtual hosts

[Eugeny N Dzhurinsky]

How can i share object between several virtual hosts?
I have object which represents the categories tree (it implemets Runnable
and rebuilds self in a 1-2 hours). I don't want to duplicate this object
in each vhost i'm using it (these objects will be identical).

Eugeny N. Dzhurinsky  programmer

Inet dept., MARKA Ltd,   Zaporozhye, Ukraine
Tel: +380(612)131123,   Tel/Fax: +380(612)131124
E-mail: [EMAIL PROTECTED] http://www.marka.zp.ua

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

question about the sessions

[Eugeny N Dzhurinsky]

How can i get session object by it's JSESSIONID key?
HttpSessionContext is deprecated as i know, the way of using third page
which gets the session key, sets cookie and redirects user to another page
is unacceptable in my application.

Thanks a lot.

Eugeny N. Dzhurinsky  programmer

Inet dept., MARKA Ltd,   Zaporozhye, Ukraine
Tel: +380(612)131123,   Tel/Fax: +380(612)131124
E-mail: [EMAIL PROTECTED] http://www.marka.zp.ua

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

[4.1.19] New tag

[Remy Maucherat]

Lots of useful changes were made since 4.1.18, so IMO it is time to tag 
4.1.19.
I plan to tag it late today.

Comments ?

Remy


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

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

[remm]

remm2003/01/14 04:59:03

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Status update.
  
  Revision  ChangesPath
  1.48  +6 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.47
  retrieving revision 1.48
  diff -u -r1.47 -r1.48
  --- RELEASE-NOTES-4.1.txt 13 Jan 2003 17:57:56 -  1.47
  +++ RELEASE-NOTES-4.1.txt 14 Jan 2003 12:59:02 -  1.48
  @@ -626,6 +626,11 @@
   [4.1.19] RequestFilterValve:
Catch null pointer property to match on, deny by default if found.
   
  +[4.1.19] #15378
  + ProxyDirContext:
  + Fix cache invalidation problem when creating subcontexts or modifying
  + attributes.
  +
   
   
   Coyote Bug Fixes:
  
  
  

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

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

[remm]

remm2003/01/14 04:37:05

  Modified:catalina/src/share/org/apache/naming/resources
ProxyDirContext.java
  Log:
  - Port patch.
  - Should fix cache invalidation when creating subcontexts and
modify atributes.
  - Fix WebDAV (bug 15378).
  
  Revision  ChangesPath
  1.15  +27 -9 
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java
  
  Index: ProxyDirContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/ProxyDirContext.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- ProxyDirContext.java  14 Oct 2002 14:31:23 -  1.14
  +++ ProxyDirContext.java  14 Jan 2003 12:37:05 -  1.15
  @@ -75,8 +75,8 @@
   import javax.naming.Context;
   import javax.naming.Name;
   import javax.naming.NameParser;
  -import javax.naming.NamingEnumeration;
   import javax.naming.NameNotFoundException;
  +import javax.naming.NamingEnumeration;
   import javax.naming.NamingException;
   import javax.naming.directory.DirContext;
   import javax.naming.directory.Attributes;
  @@ -594,7 +594,9 @@
*/
   public Context createSubcontext(Name name)
   throws NamingException {
  -return dirContext.createSubcontext(parseName(name));
  +Context context = dirContext.createSubcontext(parseName(name));
  +cacheUnload(name.toString());
  +return context;
   }
   
   
  @@ -610,7 +612,9 @@
*/
   public Context createSubcontext(String name)
   throws NamingException {
  -return dirContext.createSubcontext(parseName(name));
  +Context context = dirContext.createSubcontext(parseName(name));
  +cacheUnload(name);
  +return context;
   }
   
   
  @@ -905,6 +909,7 @@
   public void modifyAttributes(Name name, int mod_op, Attributes attrs)
   throws NamingException {
   dirContext.modifyAttributes(parseName(name), mod_op, attrs);
  +cacheUnload(name.toString());
   }
   
   
  @@ -923,6 +928,7 @@
   public void modifyAttributes(String name, int mod_op, Attributes attrs)
   throws NamingException {
   dirContext.modifyAttributes(parseName(name), mod_op, attrs);
  +cacheUnload(name);
   }
   
   
  @@ -943,6 +949,7 @@
   public void modifyAttributes(Name name, ModificationItem[] mods)
   throws NamingException {
   dirContext.modifyAttributes(parseName(name), mods);
  +cacheUnload(name.toString());
   }
   
   
  @@ -960,6 +967,7 @@
   public void modifyAttributes(String name, ModificationItem[] mods)
   throws NamingException {
   dirContext.modifyAttributes(parseName(name), mods);
  +cacheUnload(name);
   }
   
   
  @@ -981,6 +989,7 @@
   public void bind(Name name, Object obj, Attributes attrs)
   throws NamingException {
   dirContext.bind(parseName(name), obj, attrs);
  +cacheUnload(name.toString());
   }
   
   
  @@ -998,6 +1007,7 @@
   public void bind(String name, Object obj, Attributes attrs)
   throws NamingException {
   dirContext.bind(parseName(name), obj, attrs);
  +cacheUnload(name);
   }
   
   
  @@ -1022,6 +1032,7 @@
   public void rebind(Name name, Object obj, Attributes attrs)
   throws NamingException {
   dirContext.rebind(parseName(name), obj, attrs);
  +cacheUnload(name.toString());
   }
   
   
  @@ -1039,6 +1050,7 @@
   public void rebind(String name, Object obj, Attributes attrs)
   throws NamingException {
   dirContext.rebind(parseName(name), obj, attrs);
  +cacheUnload(name);
   }
   
   
  @@ -1061,7 +1073,10 @@
*/
   public DirContext createSubcontext(Name name, Attributes attrs)
   throws NamingException {
  -return dirContext.createSubcontext(parseName(name), attrs);
  +DirContext context = 
  +dirContext.createSubcontext(parseName(name), attrs);
  +cacheUnload(name.toString());
  +return context;
   }
   
   
  @@ -1078,7 +1093,10 @@
*/
   public DirContext createSubcontext(String name, Attributes attrs)
   throws NamingException {
  -return dirContext.createSubcontext(parseName(name), attrs);
  +DirContext context = 
  +dirContext.createSubcontext(parseName(name), attrs);
  +cacheUnload(name);
  +return context;
   }
   
   
  
  
  

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

Re: Coyote in memory connector

[Remy Maucherat]

jean-frederic clere wrote:

Remy Maucherat wrote:


Hi,

It would be easy to add an in-memory Java connector using the Coyote 
API, which could be used for embedding in IDEs or other embedded 
environments. This avoids the overhead of network I/O and additional 
bloat created by having a HTTP client/server in such an environment.

Comments ?


And mod_jk2 Channel that uses in-memory.


I don't know how it works. Could you give more details about what it does ?
Here, I was planning to write a barebones memory based protocol handler 
(but for Java only, no JNI invloved). If JK 2 does the job, then there's 
no need for it, obviously.

Remy


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

[GUMP] tomcat-catalina depends on commons-fileupload

[Stefan Bodewig]

but doesn't declare this dependency, the appended patch fixes this.

May I suggest that you move the Gump descriptors to the jakarta-gump
CVS module where *all* Apache committers have access to it?

Stefan

Index: gump.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/gump.xml,v
retrieving revision 1.13
diff -u -r1.13 gump.xml
--- gump.xml5 Sep 2002 13:39:47 -   1.13
+++ gump.xml14 Jan 2003 08:38:39 -
@@ -30,6 +30,7 @@
 
 
 
+
 
 
 

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

Re: Coyote in memory connector

[jean-frederic clere]

Remy Maucherat wrote:

Hi,

It would be easy to add an in-memory Java connector using the Coyote 
API, which could be used for embedding in IDEs or other embedded 
environments. This avoids the overhead of network I/O and additional 
bloat created by having a HTTP client/server in such an environment.

Comments ?

And mod_jk2 Channel that uses in-memory.



Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 






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

Coyote in memory connector

[Remy Maucherat]

Hi,

It would be easy to add an in-memory Java connector using the Coyote 
API, which could be used for embedding in IDEs or other embedded 
environments. This avoids the overhead of network I/O and additional 
bloat created by having a HTTP client/server in such an environment.

Comments ?

Remy


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

DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.X

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

pushBody()/popBody() error on tomcat 4.1.X

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |
Summary|pushBody()/popBody() error  |pushBody()/popBody() error
   |on tomcat 4.1.12|on tomcat 4.1.X



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 09:29 ---
The problem is that you only control on tomcat 4.1.x when pushBody and popBody
are used on a jsp. But what happens if you use them directly as I do on my code.
You have to take into account that it is a method available to use directly on a
custom tag, then any clean operation should be done on the pushBody popBody methods.

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