svn commit: r545095 - /tomcat/build/tc5.5.x/build.properties.default

2007-06-07 Thread fhanik
Author: fhanik
Date: Thu Jun  7 00:56:39 2007
New Revision: 545095

URL: http://svn.apache.org/viewvc?view=rev&rev=545095
Log:
prep for new release

Modified:
tomcat/build/tc5.5.x/build.properties.default

Modified: tomcat/build/tc5.5.x/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/build/tc5.5.x/build.properties.default?view=diff&rev=545095&r1=545094&r2=545095
==
--- tomcat/build/tc5.5.x/build.properties.default (original)
+++ tomcat/build/tc5.5.x/build.properties.default Thu Jun  7 00:56:39 2007
@@ -15,7 +15,7 @@
 version.build=0
 version.patch=0
 #Set the pretty version name
-version=5.5.x-snapshot
+version=5.5.24
 
 # - Compile Control Flags -
 compile.debug=on



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



svn commit: r545101 - /tomcat/container/tc5.5.x/webapps/docs/config/host.xml

2007-06-07 Thread pero
Author: pero
Date: Thu Jun  7 01:34:40 2007
New Revision: 545101

URL: http://svn.apache.org/viewvc?view=rev&rev=545101
Log:
correct small typos.
fix that RequestValveFilter used standard java regex.

Modified:
tomcat/container/tc5.5.x/webapps/docs/config/host.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/config/host.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/config/host.xml?view=diff&rev=545101&r1=545100&r2=545101
==
--- tomcat/container/tc5.5.x/webapps/docs/config/host.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/config/host.xml Thu Jun  7 01:34:40 
2007
@@ -390,9 +390,8 @@
 Context element.  The remote address or name
 will be checked against a configured list of "accept" and/or "deny"
 filters, which are defined using the Regular Expression syntax supported
-by the http://jakarta.apache.org/regexp/";>Jakarta Regexp
-regular expression library.  Requests that come from locations that are
-not accepted will be rejected with an HTTP "Forbidden" error.
+by the standard Java java.util.regex regular expression 
library.  Requests 
+that come from locations that are not accepted will be rejected with an 
HTTP "Forbidden" error.
 Example filter declarations:
 
 
@@ -424,8 +423,7 @@
 
 
   ...
-  
+  
   ...
 
 
@@ -494,7 +492,7 @@
   ...
   
   ...
 



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



svn commit: r545102 - /tomcat/container/tc5.5.x/webapps/docs/config/valve.xml

2007-06-07 Thread pero
Author: pero
Date: Thu Jun  7 01:35:13 2007
New Revision: 545102

URL: http://svn.apache.org/viewvc?view=rev&rev=545102
Log:
add host cookieDomain attribute doc

Modified:
tomcat/container/tc5.5.x/webapps/docs/config/valve.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/config/valve.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/config/valve.xml?view=diff&rev=545102&r1=545101&r2=545102
==
--- tomcat/container/tc5.5.x/webapps/docs/config/valve.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/config/valve.xml Thu Jun  7 01:35:13 
2007
@@ -378,8 +378,11 @@
 requests based on the presence of a valid SSO cookie, without 
 rechecking with the Realm.
   
+  
+  
+Sets the host domain to be used for sso cookies.
+  
  
-
 
 
   



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



svn commit: r545103 - /tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml

2007-06-07 Thread pero
Author: pero
Date: Thu Jun  7 01:37:01 2007
New Revision: 545103

URL: http://svn.apache.org/viewvc?view=rev&rev=545103
Log:
Better explain how fastasyncqueue optional recovery work.

Modified:
tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml?view=diff&rev=545103&r1=545102&r2=545103
==
--- tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/cluster-howto.xml Thu Jun  7 01:37:01 
2007
@@ -687,7 +687,9 @@
 
 
 Example to get a lot of statistic information, wait for ACK and
-recover after connection failure (wait 5 secs and 6 trails (==30 secs Mcast 
Timeout) 
+recover after connection failure. Wait 5 secs with attribute 
recoverTimeout, make 6 trails
+with attribute recoverCounter and use 30 secs 
(mcastDropTime="3") timeout
+at Service element 
 
 

svn commit: r545109 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/session/mbeans-descriptors.xml modules/cluster/src/share/org/apache/catalina/cluster/session/mbeans-descripto

2007-06-07 Thread pero
Author: pero
Date: Thu Jun  7 01:45:39 2007
New Revision: 545109

URL: http://svn.apache.org/viewvc?view=rev&rev=545109
Log:
Add getSession() operation to StandardManager and DeltaManager JMX Interface

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/mbeans-descriptors.xml

tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/mbeans-descriptors.xml
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/mbeans-descriptors.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/mbeans-descriptors.xml?view=diff&rev=545109&r1=545108&r2=545109
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/mbeans-descriptors.xml
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/session/mbeans-descriptors.xml
 Thu Jun  7 01:45:39 2007
@@ -117,6 +117,15 @@
  type="java.lang.String"/>
 
 
+
+  
+
+
 http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/mbeans-descriptors.xml?view=diff&rev=545109&r1=545108&r2=545109
==
--- 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/mbeans-descriptors.xml
 (original)
+++ 
tomcat/container/tc5.5.x/modules/cluster/src/share/org/apache/catalina/cluster/session/mbeans-descriptors.xml
 Thu Jun  7 01:45:39 2007
@@ -282,6 +282,15 @@
  type="java.lang.String"/>
 
 
+
+  
+
+
 http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=545109&r1=545108&r2=545109
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Thu Jun  7 01:45:39 2007
@@ -100,6 +100,9 @@
 This feature is needed to have stable remote access as your local 
firewall is activ. The adaptor read all
 standard JMX system properties (-Dcom.sun.management.jmxremote). 
Feature provided by George Lindholm and Juergen Herrman (pero)
   
+  
+And getSession() operation to StandardManager and DeltaManager JMX 
Interface (pero)
+   
 
   
   



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



Commons modeller not include ant.properties

2007-06-07 Thread Peter Rossbach

Hi,

I detect a problem with current commons-modeller 2.0 release. The  
ant.properties file is not included at binary release . Arrg!

This means that currently tomcat embedded release not working.

How we can add this file at next tomcat 5.5.24?

Peter





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



svn commit: r545126 - in /tomcat/connectors/trunk: jk/native/common/jk_global.h jni/java/org/apache/tomcat/Apr.java

2007-06-07 Thread mturk
Author: mturk
Date: Thu Jun  7 02:32:08 2007
New Revision: 545126

URL: http://svn.apache.org/viewvc?view=rev&rev=545126
Log:
Use JK_OPT_FWDURICOMPAT again as default

Modified:
tomcat/connectors/trunk/jk/native/common/jk_global.h
tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java

Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?view=diff&rev=545126&r1=545125&r2=545126
==
--- tomcat/connectors/trunk/jk/native/common/jk_global.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_global.h Thu Jun  7 02:32:08 
2007
@@ -234,7 +234,7 @@
 #define JK_OPT_FWDURICOMPATUNPARSED 0x0002
 #define JK_OPT_FWDURIESCAPED0x0003
 
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPAT
 
 #define JK_OPT_FWDKEYSIZE   0x0004
 

Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java?view=diff&rev=545126&r1=545125&r2=545126
==
--- tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java (original)
+++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java Thu Jun  7 
02:32:08 2007
@@ -22,9 +22,51 @@
 import java.util.Properties;
 
 public class Apr {
-private static String aprInfo = null;
+public  static String Platform = null;
+public  static String Cpu  = null;
+public  static String[] Libraries = null;
 
 static {
+String prop = System.getProperty("os.name");
+String platform = "unknown";
+
+if (name.startsWith("Windows"))
+Platform = "windows";
+else if (name.equals("Linux"))
+Platform = "linux2";
+else if (name.equals("SunOS"))
+Platform = "solaris";
+else if (name.equals("HP-UX"))
+Platform = "hpux";
+else
+Platform = "unknown";
+   prop = System.getProperty("os.arch");
+
+if (Platform.equals("windows")) {
+if (prop.equals("x86"))
+Cpu = "i686";
+else
+Cpu = prop;
+}
+else if (Platform.equals("linux2")) {
+if (prop.equals("x86"))
+Cpu = "i686";
+else
+Cpu = prop;
+}
+else if (Platform.equals("solaris")) {
+Cpu = prop;
+}
+else if (Platform.equals("hpux")) {
+if (prop.startsWith("PA_RISC"))
+Cpu = "parisc2";
+else if (prop.startsWith("IA64"))
+Cpu = "ia64";
+else
+Cpu = prop;
+}
+else
+Cpu = "unknown";
 
 try {
 InputStream is = Apr.class.getResourceAsStream
@@ -32,7 +74,11 @@
 Properties props = new Properties();
 props.load(is);
 is.close();
-aprInfo = props.getProperty("tcn.info");
+int count = Integer.parseInt(props.getProperty(Platform + 
".count"));
+Libraries = new String[count];
+for (int i = 0; i < count; i++) {
+Libraries[i] = props.getProperty(Platfrom + "." + i);
+}
 }
 catch (Throwable t) {
 ; // Nothing



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



svn commit: r545127 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

2007-06-07 Thread pero
Author: pero
Date: Thu Jun  7 02:33:59 2007
New Revision: 545127

URL: http://svn.apache.org/viewvc?view=rev&rev=545127
Log:
Fix correct ApplicationDispatcher forward/include handling after an exception 
is thrown. This patch fix a memory leak
as STRICT_SERVLET_COMPLIANCE system property is enabled and that 
cluster  crossContext session replication
working correct after an exception is thrown at a 
RequestDispatcher.forward/include call.
But I don't really like this double try/catch implementation ;-(


Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java?view=diff&rev=545127&r1=545126&r2=545127
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
 Thu Jun  7 02:33:59 2007
@@ -336,7 +336,11 @@
 HttpServletResponse hresponse = null;
 if (response instanceof HttpServletResponse)
 hresponse = (HttpServletResponse) response;
-
+
+IOException ioException = null;
+ServletException servletException = null;
+RuntimeException runtimeException = null;
+
 // Handle a non-HTTP forward by passing the existing request/response
 if ((hrequest == null) || (hresponse == null)) {
 
@@ -361,11 +365,19 @@
 wrequest.setPathInfo(hrequest.getPathInfo());
 wrequest.setQueryString(hrequest.getQueryString());
 
-processRequest(request,response,state);
-
-wrequest.recycle();
-unwrapRequest(state);
-
+try {
+processRequest(request,response,state);
+} catch ( ServletException sexp) {
+servletException = sexp ;
+} catch ( IOException iexp) {
+ioException = iexp ;
+} catch ( RuntimeException rexp) {
+runtimeException = rexp ;
+} finally {
+wrequest.recycle();
+// is called at invoke
+// unwrapRequest(state);
+}
 }
 
 // Handle an HTTP path-based forward
@@ -399,11 +411,19 @@
 wrequest.setQueryString(queryString);
 wrequest.setQueryParams(queryString);
 }
-
-processRequest(request,response,state);
-
-wrequest.recycle();
-unwrapRequest(state);
+try { 
+processRequest(request,response,state);
+} catch ( ServletException sexp) {
+servletException = sexp ;
+} catch ( IOException iexp) {
+ioException = iexp ;
+} catch ( RuntimeException rexp) {
+runtimeException = rexp ;
+} finally {
+wrequest.recycle();
+// is called at invoke
+// unwrapRequest(state);
+}
 
 }
 
@@ -439,6 +459,14 @@
 }
 }
 
+// Rethrow an exception if one was thrown by the invoked servlet
+if (ioException != null)
+throw ioException;
+if (servletException != null)
+throw servletException;
+if (runtimeException != null)
+throw runtimeException;
+
 }
 
 
@@ -553,9 +581,12 @@
 wrequest.setAttribute(
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
-invoke(state.outerRequest, state.outerResponse, state);
-
-wrequest.recycle();
+try {
+invoke(state.outerRequest, state.outerResponse, state);
+} finally {
+wrequest.recycle();
+}
+
 }
 
 // Handle an HTTP path based include
@@ -591,9 +622,11 @@
 wrequest.setAttribute(
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
-invoke(state.outerRequest, state.outerResponse, state);
-
-wrequest.recycle();
+try {
+invoke(state.outerRequest, state.outerResponse, state);
+} finally {
+wrequest.recycle();
+}
 }
 
 }

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=545127&r1=545126&r2=545127
==
--- tomcat/container/

DO NOT REPLY [Bug 30949] - After Failed Include, Request and Response not Unwrapped

2007-06-07 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=30949


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2007-06-07 02:36 ---
I detect a similar problem with wrapped request at 
ApplicationDispatcher.forward und include.
The wrapped request are not recylced after an exceptions. Arrg!

- With STRICT_SERVLET_COMPLAINS this means we have still a HTTPSession memory 
leak
- and at cluster crossContext session replication are not triggered.

Currently the only chance I see, is a double try/catch implementation. Look at 
my checkin at tomcat 
5.5.24 revision  545127.

But I don't really like the double try/catch for wrapped request!

Peter

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



svn commit: r545128 - /tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java

2007-06-07 Thread mturk
Author: mturk
Date: Thu Jun  7 02:37:54 2007
New Revision: 545128

URL: http://svn.apache.org/viewvc?view=rev&rev=545128
Log:
Oops. Made an unwanted commit. Revert the changes to Apr.java

Modified:
tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java

Modified: tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java?view=diff&rev=545128&r1=545127&r2=545128
==
--- tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java (original)
+++ tomcat/connectors/trunk/jni/java/org/apache/tomcat/Apr.java Thu Jun  7 
02:37:54 2007
@@ -22,51 +22,9 @@
 import java.util.Properties;
 
 public class Apr {
-public  static String Platform = null;
-public  static String Cpu  = null;
-public  static String[] Libraries = null;
+private static String aprInfo = null;
 
 static {
-String prop = System.getProperty("os.name");
-String platform = "unknown";
-
-if (name.startsWith("Windows"))
-Platform = "windows";
-else if (name.equals("Linux"))
-Platform = "linux2";
-else if (name.equals("SunOS"))
-Platform = "solaris";
-else if (name.equals("HP-UX"))
-Platform = "hpux";
-else
-Platform = "unknown";
-   prop = System.getProperty("os.arch");
-
-if (Platform.equals("windows")) {
-if (prop.equals("x86"))
-Cpu = "i686";
-else
-Cpu = prop;
-}
-else if (Platform.equals("linux2")) {
-if (prop.equals("x86"))
-Cpu = "i686";
-else
-Cpu = prop;
-}
-else if (Platform.equals("solaris")) {
-Cpu = prop;
-}
-else if (Platform.equals("hpux")) {
-if (prop.startsWith("PA_RISC"))
-Cpu = "parisc2";
-else if (prop.startsWith("IA64"))
-Cpu = "ia64";
-else
-Cpu = prop;
-}
-else
-Cpu = "unknown";
 
 try {
 InputStream is = Apr.class.getResourceAsStream
@@ -74,11 +32,7 @@
 Properties props = new Properties();
 props.load(is);
 is.close();
-int count = Integer.parseInt(props.getProperty(Platform + 
".count"));
-Libraries = new String[count];
-for (int i = 0; i < count; i++) {
-Libraries[i] = props.getProperty(Platfrom + "." + i);
-}
+aprInfo = props.getProperty("tcn.info");
 }
 catch (Throwable t) {
 ; // Nothing



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



Re: Commons modeller not include ant.properties

2007-06-07 Thread Filip Hanik - Dev Lists

Peter Rossbach wrote:

Hi,

I detect a problem with current commons-modeller 2.0 release. The 
ant.properties file is not included at binary release . Arrg!

This means that currently tomcat embedded release not working.

How we can add this file at next tomcat 5.5.24?

do we need it? it wasn't in 5.5.23 was it, and no one complained
Filip

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



Re: Developing Tomcat in NB

2007-06-07 Thread Johnny Kewl

Excellent... thank you.
Just wanted to ask you if you think its at all possible to do this in 
Netbeans 5.5
It seems to me that NB 6 has the ability to pick up on the ant scripts as 
part of the project menu's, and thats what you doing, but I was wondering if 
your ant scripts can be incorporated into NB5.5 in some other way?


I've done a very manual port and a restructuring of Tomcat6 on netbeans 5.5.
In other words, I literally moved the code by hand, and rebuilt the 
dependency files the way I wanted it. I moved Tomcat to a semi embedded, but 
still server environment, for want of a better description 
http://coolese.100free.com/ and would like to add some ant script that moves 
as easily as yours does, from Tomcat src, to the desired structure, but 
still keep it at NB5.5


Thanks... very very nice... will grab NB6 as soon as its officially 
released.


- Original Message - 
From: "Daria" <[EMAIL PROTECTED]>

To: 
Sent: Wednesday, June 06, 2007 4:24 PM
Subject: Developing Tomcat in NB




Dear Tomcat developers,

I would like to let you now that we have recently ported Tomcat 6.0.13
environment into NetBeans IDE.
You may wish to check it out:
http://wiki.netbeans.org/wiki/view/NetbeansedTomcat

If you are new to NB please go to netbeans.org for all information,
tutorials and fun stuff.

Now you can completely build, debug, profile Tomcat inside NB IDE and have
access to all nifty features NB IDE provides to make developer's more
productive and happy.
You productivity may get a serious boost and you will learn a new stuff as
well :-)

I would greatly appreciate any feedback you may have about my project and
any ideas on how to make it more useful for Tomcat community.

Daria Titova
NB Engineer.
--
View this message in context: 
http://www.nabble.com/Developing-Tomcat-in-NB-tf3878243.html#a10989703

Sent from the Tomcat - Dev mailing list archive at Nabble.com.


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





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



Re: svn commit: r545127 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

2007-06-07 Thread Remy Maucherat

[EMAIL PROTECTED] wrote:

Author: pero
Date: Thu Jun  7 02:33:59 2007
New Revision: 545127

URL: http://svn.apache.org/viewvc?view=rev&rev=545127
Log:
Fix correct ApplicationDispatcher forward/include handling after an exception 
is thrown. This patch fix a memory leak
as STRICT_SERVLET_COMPLIANCE system property is enabled and that 
cluster  crossContext session replication
working correct after an exception is thrown at a 
RequestDispatcher.forward/include call.
But I don't really like this double try/catch implementation ;-(


Yes, whatever you are trying to fix, this sort of last minute patch is 
not reasonable to me. -1.


Rémy

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



Re: svn commit: r545127 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

2007-06-07 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: pero
Date: Thu Jun  7 02:33:59 2007
New Revision: 545127

URL: http://svn.apache.org/viewvc?view=rev&rev=545127
Log:
Fix correct ApplicationDispatcher forward/include handling after an 
exception is thrown. This patch fix a memory leak
as STRICT_SERVLET_COMPLIANCE system property is enabled 
and that cluster  crossContext session replication
working correct after an exception is thrown at a 
RequestDispatcher.forward/include call.

But I don't really like this double try/catch implementation ;-(


Yes, whatever you are trying to fix, this sort of last minute patch is 
not reasonable to me. -1.
Peter, I need a response/action from you, as I am supposed to tag and 
generate our candidate binaries today

Filip

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



svn commit: r545151 - in /tomcat/trunk: java/org/apache/catalina/CometEvent.java java/org/apache/catalina/CometProcessor.java java/org/apache/catalina/connector/CometEventImpl.java webapps/docs/aio.xm

2007-06-07 Thread fhanik
Author: fhanik
Date: Thu Jun  7 05:15:22 2007
New Revision: 545151

URL: http://svn.apache.org/viewvc?view=rev&rev=545151
Log:
Simplified the API, no need for the IOExceptions
Updated documentation, added in some notes about life cycle, more source code 
examples to come

Modified:
tomcat/trunk/java/org/apache/catalina/CometEvent.java
tomcat/trunk/java/org/apache/catalina/CometProcessor.java
tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
tomcat/trunk/webapps/docs/aio.xml

Modified: tomcat/trunk/java/org/apache/catalina/CometEvent.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/CometEvent.java?view=diff&rev=545151&r1=545150&r2=545151
==
--- tomcat/trunk/java/org/apache/catalina/CometEvent.java (original)
+++ tomcat/trunk/java/org/apache/catalina/CometEvent.java Thu Jun  7 05:15:22 
2007
@@ -26,7 +26,9 @@
 
 /**
  * The CometEvent interface.
+ * A comet event is the contract between the servlet container and the servlet 
implementation(CometProcessor) for handling comet connections.
  * 
+ * @see CometProcessor
  * @author Filip Hanik
  * @author Remy Maucherat
  */
@@ -174,14 +176,14 @@
  * Tomcat Comet allows you to configure for additional options:
  * the COMET_NON_BLOCKING bit signals whether writing and 
reading from the request 
  * or writing to the response will be non blocking.
- * the COMET_NO_IO bit signals the container that you are not 
interested in 
- * receiving any IO events from the container.
- * @param cometOptions int - the option bit set, see #COMET_NON_BLOCKING 
and #COMET_NO_IO
- * @throws IOException -
+ * the COMET_BLOCKING bit signals the container you wish for 
read and write to be done in a blocking fashion
+ * @param cometOptions int - the option bit set
  * @throws IllegalStateException - if this method is invoked outside of 
the BEGIN event
+ * @see #CometConfiguration
+ * @see #isReadable()
+ * @see #isWriteable()
  */
-public void configure(CometConfiguration... options)
-throws IOException, IllegalStateException;
+public void configure(CometConfiguration... options) throws 
IllegalStateException;
 
 /**
  * Returns the configuration for this Comet connection
@@ -202,21 +204,17 @@
  * Registers the Comet connection with the container for IO notifications.
  * These could be notifications 
  * @param operations
- * @throws IOException
  * @throws IllegalStateException - if you are trying to register with a 
socket that already is registered
  * or if the operation you are trying to register is invalid.
  */
-public void register(CometOperation... operations)
-throws IOException, IllegalStateException;
+public void register(CometOperation... operations) throws 
IllegalStateException;
 
 /**
  * Unregisters Comet operations for this CometConnection
  * @param operations CometOperation[]
- * @throws IOException
  * @throws IllegalStateException
  */
-public void unregister(CometOperation... operations)
-throws IOException, IllegalStateException;
+public void unregister(CometOperation... operations) throws 
IllegalStateException;
 
 /**
  * Returns what the current IO notifications that the Comet

Modified: tomcat/trunk/java/org/apache/catalina/CometProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/CometProcessor.java?view=diff&rev=545151&r1=545150&r2=545151
==
--- tomcat/trunk/java/org/apache/catalina/CometProcessor.java (original)
+++ tomcat/trunk/java/org/apache/catalina/CometProcessor.java Thu Jun  7 
05:15:22 2007
@@ -28,7 +28,17 @@
  * asynchronous IO, recieving events when data is available for reading, and
  * being able to output data without the need for being invoked by the 
container.
  * Note: When this interface is implemented, the service method of the servlet 
will
- * never be called, and will be replaced with a begin event.
+ * never be called, and will be replaced with a begin event. Should the 
connector you 
+ * have configured not support Comet, the service method will be called, and 
the 
+ * request/response will not be marked as comet, but instead behave like a 
regular 
+ * Servlet
+ * 
+ * A Comet request, aka Comet connection, referenced through the #CometEvent 
and the request/response pair
+ * and has a lifecycle somewhat different to a regular servlet.
+ * 
+ * Read more about it in the Tomcat documentation about Advanced IO, 
+ * 
+ * 
  */
 public interface CometProcessor extends Servlet 
 {

Modified: tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java?view=diff&rev=545151&r1=545150&r2=545151
===

Re: svn commit: r545127 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

2007-06-07 Thread Remy Maucherat

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: pero
Date: Thu Jun  7 02:33:59 2007
New Revision: 545127

URL: http://svn.apache.org/viewvc?view=rev&rev=545127
Log:
Fix correct ApplicationDispatcher forward/include handling after an 
exception is thrown. This patch fix a memory leak
as STRICT_SERVLET_COMPLIANCE system property is enabled 
and that cluster  crossContext session replication
working correct after an exception is thrown at a 
RequestDispatcher.forward/include call.

But I don't really like this double try/catch implementation ;-(


Yes, whatever you are trying to fix, this sort of last minute patch is 
not reasonable to me. -1.
Peter, I need a response/action from you, as I am supposed to tag and 
generate our candidate binaries today


I see this particular patch is meant to call endAccess when there's an 
exception invoking the request dispatcher, which could cause problem in 
cross context. Well, maybe, because I don't see why a single try/finally 
wouldn't do the same thing, and it does some funky stuff like move some 
method calls.


This sort of last minute patch is bad practice :( I did it in the past, 
and you usually have "good" reasons for it, but it should be explicitly 
forbidden in favor of proposing delaying the release (which may be 
accepted or not).


Rémy

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



Bayeux implementation

2007-06-07 Thread Filip Hanik - Dev Lists

yo,
I was gonna create a Bayeux implementation for Tomcat,
I am thinking it might be good for us to work with the Jetty and 
Glassfish folks to use the same org.dojox interfaces.


Question: Where should I do this, sandbox or trunk?

Why Bayeux? Cause there is a good client support through the Dojo toolkit.

Thoughts?

Filip

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



Re: Bayeux implementation

2007-06-07 Thread Yoav Shapira

Hey,

On 6/7/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:

yo,
I was gonna create a Bayeux implementation for Tomcat,
I am thinking it might be good for us to work with the Jetty and
Glassfish folks to use the same org.dojox interfaces.


I like the idea!


Question: Where should I do this, sandbox or trunk?


For something this experimental, probably the sandbox, but I could see
it going either way.

Yoav

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



Re: Bayeux implementation

2007-06-07 Thread Remy Maucherat

Filip Hanik - Dev Lists wrote:

yo,
I was gonna create a Bayeux implementation for Tomcat,
I am thinking it might be good for us to work with the Jetty and 
Glassfish folks to use the same org.dojox interfaces.


I don't like dependencies ;) I am not interested in working with these 
two projects, which had relationships with Tomcat in the past, but chose 
to end them.



Question: Where should I do this, sandbox or trunk?


Sandbox, I think.


Why Bayeux? Cause there is a good client support through the Dojo toolkit.


I was wondering if it was a standard, so I guess client support is a 
benefit. However, the spec itself looks bad at the moment (unless I 
missed something).


Rémy


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



svn commit: r545175 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

2007-06-07 Thread fhanik
Author: fhanik
Date: Thu Jun  7 06:31:16 2007
New Revision: 545175

URL: http://svn.apache.org/viewvc?view=rev&rev=545175
Log:
Undoing check in from pero 545127 
http://svn.apache.org/viewvc?view=rev&rev=545127
Too close to release and no correspondence on tomcat-dev

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java?view=diff&rev=545175&r1=545174&r2=545175
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
 Thu Jun  7 06:31:16 2007
@@ -336,11 +336,7 @@
 HttpServletResponse hresponse = null;
 if (response instanceof HttpServletResponse)
 hresponse = (HttpServletResponse) response;
-
-IOException ioException = null;
-ServletException servletException = null;
-RuntimeException runtimeException = null;
-
+
 // Handle a non-HTTP forward by passing the existing request/response
 if ((hrequest == null) || (hresponse == null)) {
 
@@ -365,19 +361,11 @@
 wrequest.setPathInfo(hrequest.getPathInfo());
 wrequest.setQueryString(hrequest.getQueryString());
 
-try {
-processRequest(request,response,state);
-} catch ( ServletException sexp) {
-servletException = sexp ;
-} catch ( IOException iexp) {
-ioException = iexp ;
-} catch ( RuntimeException rexp) {
-runtimeException = rexp ;
-} finally {
-wrequest.recycle();
-// is called at invoke
-// unwrapRequest(state);
-}
+processRequest(request,response,state);
+
+wrequest.recycle();
+unwrapRequest(state);
+
 }
 
 // Handle an HTTP path-based forward
@@ -411,19 +399,11 @@
 wrequest.setQueryString(queryString);
 wrequest.setQueryParams(queryString);
 }
-try { 
-processRequest(request,response,state);
-} catch ( ServletException sexp) {
-servletException = sexp ;
-} catch ( IOException iexp) {
-ioException = iexp ;
-} catch ( RuntimeException rexp) {
-runtimeException = rexp ;
-} finally {
-wrequest.recycle();
-// is called at invoke
-// unwrapRequest(state);
-}
+
+processRequest(request,response,state);
+
+wrequest.recycle();
+unwrapRequest(state);
 
 }
 
@@ -459,14 +439,6 @@
 }
 }
 
-// Rethrow an exception if one was thrown by the invoked servlet
-if (ioException != null)
-throw ioException;
-if (servletException != null)
-throw servletException;
-if (runtimeException != null)
-throw runtimeException;
-
 }
 
 
@@ -581,12 +553,9 @@
 wrequest.setAttribute(
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
-try {
-invoke(state.outerRequest, state.outerResponse, state);
-} finally {
-wrequest.recycle();
-}
-
+invoke(state.outerRequest, state.outerResponse, state);
+
+wrequest.recycle();
 }
 
 // Handle an HTTP path based include
@@ -622,11 +591,9 @@
 wrequest.setAttribute(
 ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
 servletPath);
-try {
-invoke(state.outerRequest, state.outerResponse, state);
-} finally {
-wrequest.recycle();
-}
+invoke(state.outerRequest, state.outerResponse, state);
+
+wrequest.recycle();
 }
 
 }

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?view=diff&rev=545175&r1=545174&r2=545175
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Thu Jun  7 06:31:16 2007
@@ -102,12 +102,7 @@
   
   
 And getSession() operation to StandardManager and DeltaManager JMX 

svn commit: r545180 - in /tomcat/trunk: java/org/apache/coyote/http11/InternalNioOutputBuffer.java webapps/docs/aio.xml

2007-06-07 Thread fhanik
Author: fhanik
Date: Thu Jun  7 06:48:07 2007
New Revision: 545180

URL: http://svn.apache.org/viewvc?view=rev&rev=545180
Log:
notes, still need some work on the write to socket

Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
tomcat/trunk/webapps/docs/aio.xml

Modified: 
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?view=diff&rev=545180&r1=545179&r2=545180
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java 
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java Thu 
Jun  7 06:48:07 2007
@@ -417,6 +417,7 @@
  * @param flip boolean
  * @return int
  * @throws IOException
+ * @todo Fix non blocking write properly
  */
 private synchronized int writeToSocket(ByteBuffer bytebuffer, boolean 
flip, boolean block) throws IOException {
 //int limit = bytebuffer.position();
@@ -440,7 +441,7 @@
 }finally { 
 if ( selector != null ) getSelectorPool().put(selector);
 }
-socket.getBufHandler().getWriteBuffer().clear();
+if ( block ) socket.getBufHandler().getWriteBuffer().clear(); //only 
clear
 this.total = 0;
 return written;
 } 

Modified: tomcat/trunk/webapps/docs/aio.xml
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/aio.xml?view=diff&rev=545180&r1=545179&r2=545180
==
--- tomcat/trunk/webapps/docs/aio.xml (original)
+++ tomcat/trunk/webapps/docs/aio.xml Thu Jun  7 06:48:07 2007
@@ -409,7 +409,7 @@
   
 If you are using the NIO connector, you can set individual timeouts for 
your different comet connections.
To set a timeout, simple set a request attribute like the following 
code shows:
-   CometEvent event event.setTimeout(30*1000); 
+   event.setTimeout(30*1000); 
You can set the timeout on the comet connection at any point in 
time, even asynchronously.
Setting a timeout to 1 (one milliseconds) doesn't guarantee that it 
will timeout at that time.
Setting the timeout gurantees that Tomcat wont timeout the connection 
before the connection has been idle



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



Re: Bayeux implementation

2007-06-07 Thread Filip Hanik - Dev Lists

Yoav Shapira wrote:

Hey,

On 6/7/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:

yo,
I was gonna create a Bayeux implementation for Tomcat,
I am thinking it might be good for us to work with the Jetty and
Glassfish folks to use the same org.dojox interfaces.


I like the idea!


Question: Where should I do this, sandbox or trunk?


For something this experimental, probably the sandbox, but I could see
it going either way.

so is trunk until we agree or agree to disagree :)

Filip

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



Re: Bayeux implementation

2007-06-07 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

yo,
I was gonna create a Bayeux implementation for Tomcat,
I am thinking it might be good for us to work with the Jetty and 
Glassfish folks to use the same org.dojox interfaces.


I don't like dependencies ;) I am not interested in working with these 
two projects, which had relationships with Tomcat in the past, but 
chose to end them.
not working with the projects is your personal prerogative, the rest of 
the community might not be against it. I am not and one more post 
thought it was a good idea.
I think the relationships especially around bayeux can be very 
beneficial for all of us, as we can be part of it dictating the 
direction of it instead of just having to respond to it due to user demand.
I'd like to know if anyone else is strongly against it, since I don't 
think past events should dictate if we join this initiative or not.

Question: Where should I do this, sandbox or trunk?


Sandbox, I think.

Sandbox it is.


Why Bayeux? Cause there is a good client support through the Dojo 
toolkit.


I was wondering if it was a standard, so I guess client support is a 
benefit. However, the spec itself looks bad at the moment (unless I 
missed something).
If the spec is bad, then its another reason for us to join in, but the 
fact that there is a client support, speaks for itself.
Comet is very popular but the skillset to create a client that works in 
a browser is hard to find. This was very much the feedback we got during 
Apachecon EU in Amsterdam.


Whether we use it or not, we can decide on later. In the meantime I'll 
touch base with the folks and get the ball rolling.


Filip

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



Proposed simplification of CometEvent

2007-06-07 Thread Remy Maucherat

Hi,

I've been working on additions to CometEvent to implement the additional 
Comet functionality that was agreed upon before creating the "trunk" 
branch. Although not functional at the moment, I consider it to be 
developed enough from an algorithmic standpoint to be proposed and 
reviewed (it is also important to not continue an API fork for too long, 
since otherwise it would be harder to merge, so some resolution is 
needed). I went through a few revisions of the API, as more tweaks 
appeared possible. The idea was to allow the extra functionality without 
adding complexity or incompatible changes, since this is most likely 
going to be an interim API.


The repository is at:
https://svn.apache.org/repos/asf/tomcat/sandbox/comet

It has the following changes over the 6.0.x branch:
- additions of four methods in CometEvent (sleep and callback, and the 
two flags isRead(Write)able)
- sleep delays request processing until either callback is called, or a 
timeout occurs
- callback allows waking up requests which are "asleep" or waiting for 
an IO event
- non blocking IO exclusively in Comet mode, since it now seems to me it 
is algorithmically equivalent to blocking IO; for read, it has been 
demonstrated previously; for write, it seems there should always be 
write events after a properly handled congestion (where the servlet uses 
isWriteable), since if the servlet does not, it will be best to simply 
fail-fast the connection using an IOException (the servlet would 
effectively only handle clients which are "fast enough" if using the 
Comet API like in Tomcat 6.0, which avoids a lot of issues)
- isRead(Write)able indicate if data may be read or written (since this 
is non blocking IO, reading or writing would read or write 0 bytes); if 
it is false and reading or writing is done, an IO exception will be thrown

- no additional data structures
- new ActionCode: ACTION_COMET_TIMEOUT (which is cleanup), 
ACTION_COMET_CALLBACK (called by the callback() method), 
ACTION_COMET_SLEEP (called by the sleep() method), ACTION_COMET_WRITE 
(called by the CometEvent.isWriteable method without the need for an 
explicit callback from the servlet - isWriteable knows the result of the 
last write, and the servlet is supposed to not attempt any further 
writing if isWriteable returns false)
- no additional features, like verification of caller threads (which I 
consider useless)


I hope I did not forget anything.

Comments ? / Votes ?

Rémy


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



Re: Bayeux implementation

2007-06-07 Thread Remy Maucherat

Filip Hanik - Dev Lists wrote:
If the spec is bad, then its another reason for us to join in, but the 
fact that there is a client support, speaks for itself.


Specifically, the syntax looks funny to me, and the spec document is bad 
(that's what I meant with "the spec is bad"). Implementing it doesn't hurt.


Rémy

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



Re: Proposed simplification of CometEvent

2007-06-07 Thread Yoav Shapira

Hi,

On 6/7/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:

fail-fast the connection using an IOException (the servlet would
effectively only handle clients which are "fast enough" if using the
Comet API like in Tomcat 6.0, which avoids a lot of issues)


This is an interesting assumption, but I think it's valid for this type of API.


Comments ? / Votes ?


I like the callback approach especially, and otherwise I see no major
problems.  Cool improvements.

Yoav

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



DO NOT REPLY [Bug 42409] - Extra response headers not sent when using custom error page

2007-06-07 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=42409





--- Additional Comments From [EMAIL PROTECTED]  2007-06-07 08:27 ---
I guess this workaround should work, unfortunately I'll have to rip through all
my source to replace setHeader with setAttribute and then add a scriptlet to my
error jsp page.  However, I still don't understand why this won't be fixed,
seems like a legitimate bug.  Anyhow, thanks for the help.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



Re: Proposed simplification of CometEvent

2007-06-07 Thread Remy Maucherat

Yoav Shapira wrote:

Hi,

On 6/7/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:

fail-fast the connection using an IOException (the servlet would
effectively only handle clients which are "fast enough" if using the
Comet API like in Tomcat 6.0, which avoids a lot of issues)


This is an interesting assumption, but I think it's valid for this type 
of API.


Yes, it's a bit an assumption. Since there's no "blocking or non 
blocking ?" question mark, it simplifies significantly the documentation 
of the API.


The main issue is how to handle a write which would block, and would 
most probably cause problems when doing async writes (as others pointed 
out - Filip, I think), so in that case, if the Servlet chooses not to 
handle it using isWriteable - which makes sense in many cases -, I think 
the exception throwing is fine.


The only situation where it could cause real problems is if the write is 
done inside another event (like in the common "reply later" pattern), 
and I think it would most likely work well enough due to the existence 
of buffers at the servlet layer. It's quite easy to add back blocking 
mode if needed, and tricks could be used rather than rely on direct 
configuration. For example, while I think adding code to detect what is 
called asynchronously for error checking purposes is useless, it could 
be possible to detect if the problematic write is sync or async, and 
adjust blocking mode accordingly at the connector level rather than 
throwing the exception.


The idea is to make the API simpler overall than what it is in 6.0 
(despite the addition of 3 methods and 2 event types, I think it would 
be simpler to work with due to the sleep/callback methods which allow 
doing common things very easily), and avoid introducing heavier 
constructs and method calls.


Rémy

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



DO NOT REPLY [Bug 29936] - XML parser loading problems by container

2007-06-07 Thread 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://issues.apache.org/bugzilla/show_bug.cgi?id=29936


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 Status|RESOLVED|REOPENED
  Component|Unknown |Catalina
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-06-07 12:15 ---
This issue is also prevalent in 5.5.x.  To reproduce, do the following:

1) Remove all stock webapps that come with the standard installation.  This
includes the ones in server/webapps.  Remember to remove the configurations in
conf/Catalina.
2) Add a webapp that has a saxon parser located in WEB-INF/lib.  For instance,
one from sourceforge.
3) Start Tomcat.  You should a stack trace similar to this:

Jun 7, 2007 11:33:29 AM org.apache.commons.digester.Digester getParser
SEVERE: Digester.getParser: 
javax.xml.parsers.ParserConfigurationException: AElfred parser is 
namespace-aware
at
com.icl.saxon.aelfred.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:37)
at org.apache.commons.digester.Digester.getParser(Digester.java:686)
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:902)
at org.apache.commons.digester.Digester.parse(Digester.java:1548)
at 
org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:515)
at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:623)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:216)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4290)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:277)
at org.apache.catalina.core.StandardHost.install(StandardHost.java:832)
at 
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:625)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:431)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:983)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:349)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1091)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:789)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1083)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:478)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:480)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:2313)
at org.apache.catalina.startup.Catalina.start(Catalina.java:556)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425)
Jun 7, 2007 11:33:29 AM org.apache.catalina.startup.ContextConfig defaultConfig
SEVERE: Parse error in default web.xml
java.lang.NullPointerException
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:902)
at org.apache.commons.digester.Digester.parse(Digester.java:1548)
at 
org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:515)
at 
org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:623)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:216)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4290)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
at