date:20031020

Re: New builds ?

2003-10-20 Thread Remy Maucherat

Jeff Tulley wrote:
Nothing yet found on the NetWare side, though we have not yet pounded it
hard.  4.1.28 has been only better than 4.1.27 as far as I'm concerned. 
I'd be desirous to see a vote and (hopefully) have it determined to be
stable.
Well, my vote hasn't been very popular (as usual, but it's been even 
worse this time) ;-)

Also, we may want to expose a few more connector features in a new 
4.1.29 (ex: the REs).

Remy



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

DO NOT REPLY [Bug 21105] - Tomcat RPM: /etc/profile.d

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21105

Tomcat RPM: /etc/profile.d

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-21 06:09 ---
AFAIK, RPM packaging for TC 5 is not done yet.

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

DO NOT REPLY [Bug 23805] - Possible error in response wrapper implementation

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23805

Possible error in response wrapper implementation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-21 06:07 ---
I now agree with Kin-Man's evaluation. Weird Jasper behavior, though.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator AuthenticatorBase.java

2003-10-20 Thread luehe

luehe   2003/10/20 19:58:42

  Modified:catalina/src/share/org/apache/catalina/authenticator
AuthenticatorBase.java
  Log:
  Fixed indentation/removed tabs
  
  Revision  ChangesPath
  1.12  +66 -47
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
  
  Index: AuthenticatorBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- AuthenticatorBase.java2 Sep 2003 21:22:04 -   1.11
  +++ AuthenticatorBase.java21 Oct 2003 02:58:42 -  1.12
  @@ -499,8 +499,8 @@
   
   Realm realm = this.context.getRealm();
   // Is this request URI subject to a security constraint?
  -SecurityConstraint [] constraints = realm.
  -   findSecurityConstraints(hrequest, this.context);
  +SecurityConstraint [] constraints
  += realm.findSecurityConstraints(hrequest, this.context);
  
   if ((constraints == null) /* &&
   (!Constants.FORM_METHOD.equals(config.getAuthMethod())) */ ) {
  @@ -522,54 +522,73 @@
   sresponse.setHeader("Cache-Control", "no-cache");
   sresponse.setHeader("Expires", DATE_ONE);
   }
  - int i;
  - for(i=0; i < constraints.length; i++) {
  - if (log.isDebugEnabled())
  - log.debug(" Subject to constraint " + constraints[i]);
  - // Enforce any user data constraint for this security constraint
  - if (log.isDebugEnabled())
  - log.debug(" Calling hasUserDataPermission()");
  -
  - if (!realm.hasUserDataPermission(hrequest, hresponse, constraints[i])) {
  - if (log.isDebugEnabled())
  - log.debug(" Failed hasUserDataPermission() test");
  - // ASSERT: Authenticator already set the appropriate
  - // HTTP status code, so we do not have to do anything special
  - return;
  - }
  - }
  - for(i=0; i < constraints.length; i++) {
  - // Authenticate based upon the specified login configuration
  - if (constraints[i].getAuthConstraint()) {
  - if (log.isDebugEnabled())
  - log.debug(" Calling authenticate()");
  - if (!authenticate(hrequest, hresponse, config)) {
  - if (log.isDebugEnabled())
  - log.debug(" Failed authenticate() test");
  - // ASSERT: Authenticator already set the appropriate
  - // HTTP status code, so we do not have to do anything special
  - return;
  +
  +int i;
  +for(i=0; i < constraints.length; i++) {
  +if (log.isDebugEnabled()) {
  +log.debug(" Subject to constraint " + constraints[i]);
  +}
  +// Enforce any user data constraint for this security constraint
  +if (log.isDebugEnabled()) {
  +log.debug(" Calling hasUserDataPermission()");
  +}
  +if (!realm.hasUserDataPermission(hrequest, hresponse,
  + constraints[i])) {
  +if (log.isDebugEnabled()) {
  +log.debug(" Failed hasUserDataPermission() test");
  +}
  +/*
  + * ASSERT: Authenticator already set the appropriate
  + * HTTP status code, so we do not have to do anything special
  + */
  +return;
   }
   }
   
  - // Perform access control based on the specified role(s)
  - if (constraints[i].getAuthConstraint()) {
  - if (log.isDebugEnabled())
  - log.debug(" Calling accessControl()");
  -
  - if (!realm.hasResourcePermission(hrequest, hresponse, constraints[i], 
this.context)) {
  - if (log.isDebugEnabled())
  - log.debug(" Failed accessControl() test");
  - // ASSERT: AccessControl method has already set the appropriate
  - // HTTP status code, so we do not have to do anything special
  - return;
  - }
  - }
  +for(i=0; i < constraints.length; i++) {
  +// Authenticate based upon the specified login configuration
  +if (constraints[i].getAuthConstraint()) {
  +if (log.isDebugEnabled()) {
  +log.debug(" Calling authenticate()");
  +}
  +if (!authenticate(hrequest, hresponse, config)) {
  +if (log.isDebugEnabled()) {
  +log.debug(" Failed authenticate() test");
  +

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

2003-10-20 Thread glenn

glenn   2003/10/20 17:22:57

  Modified:webapps/tomcat-docs/config defaultcontext.xml
   catalina/src/share/org/apache/catalina/startup
ContextRuleSet.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java StandardDefaultContext.java
StandardEngine.java StandardHost.java
  Log:
  The DefaultContext docs listed support for a Listener but the
  code to suppor this was not implemented.
  
  Added support for nesting a Context Listener within a
  DefaultContext.
  
  Added support for nesting a Webapp Loader within a
  DefaultContext.
  
  The importDefaultContext() had to be split into two
  methods.  The installDefaultContext() method was added.
  This is due to sequencing issues when instantiating
  a Context.  Some things needed to occur earlier than
  when the importDefaultContext() is called. And some
  things needed to occur during the normal
  importDefaultContext().
  
  No interfaces in org.apache.catalina were changed,
  though they could be in Tomcat 5 since there has
  not been a final release.
  
  Revision  ChangesPath
  1.6   +2 -2  jakarta-tomcat-4.0/webapps/tomcat-docs/config/defaultcontext.xml
  
  Index: defaultcontext.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/defaultcontext.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- defaultcontext.xml12 Jan 2003 17:26:48 -  1.5
  +++ defaultcontext.xml21 Oct 2003 00:22:57 -  1.6
  @@ -113,7 +113,6 @@
   
   
   
  -
 
   
   
  --->
   
   
   
  
  
  
  1.4   +9 -6  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextRuleSet.java
  
  Index: ContextRuleSet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextRuleSet.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ContextRuleSet.java   8 Nov 2001 21:03:15 -   1.3
  +++ ContextRuleSet.java   21 Oct 2003 00:22:57 -  1.4
  @@ -303,8 +303,11 @@
   public void begin(Attributes attributes) throws Exception {
   
   // Look up the required parent class loader
  -Container container = (Container) digester.peek();
  -ClassLoader parentClassLoader = container.getParentClassLoader();
  +ClassLoader parentClassLoader = null;
  +Object ojb = digester.peek();
  +if (ojb instanceof Container) {
  +parentClassLoader = ((Container)ojb).getParentClassLoader();
  +}
   
   // Instantiate a new Loader implementation object
   String className = loaderClass;
  
  
  
  1.121 +18 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.120
  retrieving revision 1.121
  diff -u -r1.120 -r1.121
  --- StandardContext.java  5 Aug 2003 09:32:14 -   1.120
  +++ StandardContext.java  21 Oct 2003 00:22:57 -  1.121
  @@ -106,6 +106,7 @@
   import org.apache.catalina.Container;
   import org.apache.catalina.ContainerListener;
   import org.apache.catalina.Context;
  +import org.apache.catalina.Engine;
   import org.apache.catalina.Host;
   import org.apache.catalina.Globals;
   import org.apache.catalina.HttpRequest;
  @@ -3473,6 +3474,19 @@
   if (!resourcesStart())
   ok = false;
   }
  +
  +// Install DefaultContext configuration
  +if (!getOverride()) {
  +Container host = getParent();
  +if (host instanceof StandardHost) {
  +((StandardHost)host).installDefaultContext(this);
  +Container engine = host.getParent();
  +if( engine instanceof StandardEngine ) {
  +((StandardEngine)engine).installDefaultContext(this);
  +}
  +}
  +}
  +
   if (getLoader() == null) {  // (2) Required by Manager
   if (getPrivileged()) {
   if (debug >= 1)
  
  
  
  1.10  +68 -7 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
  
  Index: StandardDefaultContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- StandardDefaultContext.java   13 Nov 2002 14:16:24 -

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

2003-10-20 Thread glenn

glenn   2003/10/20 17:18:25

  Modified:webapps/docs/config defaultcontext.xml
   catalina/src/share/org/apache/catalina/startup
ContextRuleSet.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java StandardDefaultContext.java
StandardEngine.java StandardHost.java
  Log:
  The DefaultContext docs listed support for a Listener but the
  code to suppor this was not implemented.
  
  Added support for nesting a Context Listener within a
  DefaultContext.
  
  Added support for nesting a Webapp Loader within a
  DefaultContext.
  
  The importDefaultContext() had to be split into two
  methods.  The installDefaultContext() method was added.
  This is due to sequencing issues when instantiating
  a Context.  Some things needed to occur earlier than
  when the importDefaultContext() is called. And some
  things needed to occur during the normal
  importDefaultContext().
  
  No interfaces in org.apache.catalina were changed,
  though they could be in Tomcat 5 since there has
  not been a final release.
  
  Revision  ChangesPath
  1.4   +2 -2  jakarta-tomcat-catalina/webapps/docs/config/defaultcontext.xml
  
  Index: defaultcontext.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/config/defaultcontext.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- defaultcontext.xml15 Jan 2003 03:40:44 -  1.3
  +++ defaultcontext.xml21 Oct 2003 00:18:25 -  1.4
  @@ -115,7 +115,6 @@
   
   
   
  -
 
  --->
   
   
   
  
  
  
  1.4   +9 -6  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextRuleSet.java
  
  Index: ContextRuleSet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextRuleSet.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ContextRuleSet.java   2 Sep 2003 21:22:00 -   1.3
  +++ ContextRuleSet.java   21 Oct 2003 00:18:25 -  1.4
  @@ -302,8 +302,11 @@
   public void begin(Attributes attributes) throws Exception {
   
   // Look up the required parent class loader
  -Container container = (Container) digester.peek();
  -ClassLoader parentClassLoader = container.getParentClassLoader();
  +ClassLoader parentClassLoader = null;
  +Object ojb = digester.peek();
  +if (ojb instanceof Container) {
  +parentClassLoader = ((Container)ojb).getParentClassLoader();
  +}
   
   // Instantiate a new Loader implementation object
   String className = loaderClass;
  
  
  
  1.97  +14 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.96
  retrieving revision 1.97
  diff -u -r1.96 -r1.97
  --- StandardContext.java  15 Oct 2003 17:24:16 -  1.96
  +++ StandardContext.java  21 Oct 2003 00:18:25 -  1.97
  @@ -3965,6 +3965,19 @@
   ok = false;
   }
   }
  +
  +// Install DefaultContext configuration
  +if (!getOverride()) {
  +Container host = getParent();
  +if (host instanceof StandardHost) {
  +((StandardHost)host).installDefaultContext(this);
  +Container engine = host.getParent();
  +if( engine instanceof StandardEngine ) {
  +((StandardEngine)engine).installDefaultContext(this);
  +}
  +}
  +}
  +
   // Look for a realm - that may have been configured earlier. 
   // If the realm is added after context - it'll set itself.
   if( realm == null ) {
  
  
  
  1.7   +70 -8 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java
  
  Index: StandardDefaultContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardDefaultContext.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- StandardDefaultContext.java   2 Sep 2003 21:22:04 -   1.6
  +++ StandardDefaultContext.java   21 Oct 2003 00:18:25 -  1.7
  @@ -66,9 +66,12 @@
   
   import java.beans.PropertyChangeListener;
   import java.beans.PropertyChangeSupport;
  +import java.lang.reflect.Constructor;
   import java.util.ArrayList;
  +import java.util.Enumera

DO NOT REPLY [Bug 23502] - Incorrect path in generated SMAP file entries

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23502

Incorrect path in generated SMAP file entries

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 21:37 ---
I tried a couple of examples and SMAP looks correct.  You'll need to show me a
test case that gives you the wrong SMAP.

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

DO NOT REPLY [Bug 23691] - Incorrect custom tag SMAPping

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23691

Incorrect custom tag SMAPping

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 21:13 ---
This is now fixed.  Boy, the SMAP tracking code can get complicated, especially
if you mix fragments with classic custom tags!

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

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

2003-10-20 Thread kinman

kinman  2003/10/20 14:07:46

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  - Tweak the SMAP tracking code so that it works for classic custom tag and
JSP fragments.  This also fixes bug 23691.
  
  Revision  ChangesPath
  1.214 +48 -28
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.213
  retrieving revision 1.214
  diff -u -r1.213 -r1.214
  --- Generator.java10 Oct 2003 17:40:38 -  1.213
  +++ Generator.java20 Oct 2003 21:07:46 -  1.214
  @@ -1629,8 +1629,13 @@
   
   // Set up new buffer for the method
   outSave = out;
  +/* For fragments, their bodies will be generated in fragment
  +   helper classes, and the Java line adjustments will be done
  +   there, hence they are set to null here to avoid double
  +   adjustments.
  +*/
   GenBuffer genBuffer =
  -new GenBuffer(n.implementsSimpleTag() ? null : n);
  +new GenBuffer(n, n.implementsSimpleTag()? null: n.getBody());
   methodsBuffered.add(genBuffer);
   out = genBuffer.getOut();
   
  @@ -1883,7 +1888,7 @@
  // Generate Strings as char arrays, for performance
   ServletWriter caOut;
   if (charArrayBuffer == null) {
  -charArrayBuffer = new GenBuffer(null);
  +charArrayBuffer = new GenBuffer();
   caOut = charArrayBuffer.getOut();
   caOut.pushIndent();
   textMap = new HashMap();
  @@ -3694,21 +3699,31 @@
   }
   
   /**
  - * A class for generating codes to a buffer.
  + * A class for generating codes to a buffer.  Included here are some
  + * support for tracking source to Java lines mapping.
*/
   private static class GenBuffer {
   
  +/*
  + * For a CustomTag, the codes that are generated at the beginning of
  + * the tag may not be in the same buffer as those for the body of the
  + * tag.  Two fields are used here to keep this straight.  For codes
  + * that do not corresponds to any JSP lines, they should be null.  
  + */
   private Node node;
  +private Node.Nodes body;
   private java.io.CharArrayWriter charWriter;
   protected ServletWriter out;
   
  -GenBuffer(Node n) {
  +GenBuffer() {
  +this(null, null);
  +}
  +
  +GenBuffer(Node n, Node.Nodes b) {
   node = n;
  -if (n != null) {
  -Node.Nodes body = n.getBody();
  -if (body != null) {
  -body.setGeneratedInBuffer(true);
  -}
  +body = b;
  +if (body != null) {
  +body.setGeneratedInBuffer(true);
   }
   charWriter = new java.io.CharArrayWriter();
   out = new ServletWriter(new java.io.PrintWriter(charWriter));
  @@ -3731,27 +3746,25 @@
   public void adjustJavaLines(final int offset) {
   
   if (node != null) {
  +adjustJavaLine(node, offset);
  +}
  +
  +if (body != null) {
   try {
  -node.accept(new Node.Visitor() {
  +body.visit(new Node.Visitor() {
   
   public void doVisit(Node n) {
  -if (n.getBeginJavaLine() > 0) {
  -n.setBeginJavaLine(
  -n.getBeginJavaLine() + offset);
  -n.setEndJavaLine(n.getEndJavaLine() + offset);
  -}
  +adjustJavaLine(n, offset);
   }
   
   public void visit(Node.CustomTag n)
   throws JasperException {
  -doVisit(n);
  -Node.Nodes body = n.getBody();
  -if (body != null &&
  -((node == n) || !body.isGeneratedInBuffer())) {
  -// We want to adjust the Java lines only for
  -// top level Custom tags, unless its body is
  -// not generated in a buffer.
  -body.visit(this);
  +Node.Nodes b = n.getBody();
  +if (b != null && !b.isGeneratedInBuffer()) {
  +

DO NOT REPLY [Bug 23948] - HTTP upload slow when Solaris and Internet Explorer

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23948

HTTP upload slow when Solaris and Internet Explorer





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 20:23 ---
Thanks. That did speed it up significantly. It increased the speed to about 7% 
of a 100 Mbs connection from about 1%. However, Mozilla is around 30% and IE 
against Linux is 45%, so, it still seems a bit slow. I'm going to try it on a 
Solaris 9 box and see if that makes a difference.

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

DO NOT REPLY [Bug 23948] - HTTP upload slow when Solaris and Internet Explorer

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23948

HTTP upload slow when Solaris and Internet Explorer





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 19:57 ---
It is a solaris tuning problem that the microsoft stack brings out.

ndd -set /dev/tcp tcp_deferred_ack_interval 5 

and I suspect you will see a marked improvement.

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

DO NOT REPLY [Bug 23948] - HTTP upload slow when Solaris and Internet Explorer

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23948

HTTP upload slow when Solaris and Internet Explorer





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 19:45 ---
OK, I'll test it on another Solaris box to make sure that it isn't a problem 
specific to that computer. Note, I'm using the default Tomcat configuration 
file, so, I don't think it's a misconfiguration problem. Also, as I mentioned, 
it works fine with Mozilla and I tested it with IE from multiple different 
clients to make sure that it wasn't a client configuration problem. If it was 
a configuration problem, why would it work fine with Mozilla?

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

DO NOT REPLY [Bug 23948] - HTTP upload slow when Solaris and Internet Explorer

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23948

HTTP upload slow when Solaris and Internet Explorer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 19:09 ---
Maybe you are having a problem, but you have to point out there's a bug with the
Tomcat network handling, rather than a bug in your setup. Discussing this kind
of issue on tomcat-user is much better than using BZ.

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

DO NOT REPLY [Bug 23953] - JAVA_HOME defined incorrectly breaks startup.bat

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23953

JAVA_HOME defined incorrectly breaks startup.bat





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 19:05 ---
Unfortunatelly, I make a mistake :-(

The script - setclasspath.bat - should have every 'goto end' changed to 'goto 
exit', and the last entries of setclasspath.bat should look as follows:

:exit
exit

:end

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

DO NOT REPLY [Bug 23953] New: - JAVA_HOME defined incorrectly breaks startup.bat

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23953

JAVA_HOME defined incorrectly breaks startup.bat

   Summary: JAVA_HOME defined incorrectly breaks startup.bat
   Product: Tomcat 5
   Version: 5.0.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When JAVA_HOME is defined incorrectly startup.bat doesn't start up Catalina 
even though setclasspath.bat (invoked from within the batch) warns about the 
wrong variable and ends. That's where the problem is. The setclasspath.bat ends 
nor exits. The last line of setclasspath.bat should look like the following:

   :end
   exit

With the change, when JAVA_HOME is wrong, the startup.bat returns quietly (it 
really should print out a message about it).

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

Re: New builds ?

2003-10-20 Thread Jeff Tulley

Nothing yet found on the NetWare side, though we have not yet pounded it
hard.  4.1.28 has been only better than 4.1.27 as far as I'm concerned. 
I'd be desirous to see a vote and (hopefully) have it determined to be
stable.

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

>>> [EMAIL PROTECTED] 10/20/03 10:33:55 AM >>>
So, what do we do with 4.1.28 ? AFAIK, no significant issue has been 
found with this build, with minor tweaks being made since then in the 
connectors.
Is a 4.1.29 needed, or is it simply people forgot about that build ?

OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the

5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13

builds are all cursed :-D).

Comments ?

Remy



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

DO NOT REPLY [Bug 23950] New: - [PATCH] Context.listBindings(...) broken?

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23950

[PATCH] Context.listBindings(...) broken?

   Summary: [PATCH] Context.listBindings(...) broken?
   Product: Tomcat 4
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I believe that the Context.listBindings(...) methods should return an
Enumeration that returns resolved Objects, not references.  The current
implementation does not make an effort to resolve References to Objects prior to
returning the Binding.  It also should hold Exceptions until the enumeration has
been fully traversed.  A possible patch is noted below (verified against 1.4,
spot-checked for pre-1.4).


Index: NamingContextBindingsEnumeration.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/NamingContextBindingsEnumeration.java,v
retrieving revision 1.1
diff -u -r1.1 NamingContextBindingsEnumeration.java
--- NamingContextBindingsEnumeration.java   2 Nov 2000 06:14:16 -   1.1
+++ NamingContextBindingsEnumeration.java   20 Oct 2003 14:58:28 -
@@ -67,9 +67,12 @@
 import java.util.Hashtable;
 import java.util.Vector;
 import java.util.Enumeration;
+import javax.naming.CompositeName;
+import javax.naming.Context;
 import javax.naming.NamingException;
 import javax.naming.NamingEnumeration;
 import javax.naming.Binding;
+import javax.naming.spi.NamingManager;
 
 /**
  * Naming enumeration implementation.
@@ -85,13 +88,17 @@
 // --- Constructors
 
 
-public NamingContextBindingsEnumeration(Vector entries) {
+public NamingContextBindingsEnumeration(Vector entries, Context ctx,
Hashtable env) {
 enum = entries.elements();
+   this.ctx = ctx;
+   this.env = env;
 }
 
 
-public NamingContextBindingsEnumeration(Enumeration enum) {
+public NamingContextBindingsEnumeration(Enumeration enum, Context ctx,
Hashtable env) {
 this.enum = enum;
+   this.ctx = ctx;
+   this.env = env;
 }
 
 
@@ -103,6 +110,11 @@
  */
 protected Enumeration enum;
 
+private Hashtable env;
+private Context ctx;
+private Binding next;
+private Exception trouble;
+private boolean runtimeExc;
 
 // - Public Methods
 
@@ -110,9 +122,10 @@
 /**
  * Retrieves the next element in the enumeration.
  */
-public Object next()
-throws NamingException {
-return nextElement();
+public Object next() {
+   Object ret = next;
+   next = null;
+   return ret;
 }
 
 
@@ -121,7 +134,35 @@
  */
 public boolean hasMore()
 throws NamingException {
-return enum.hasMoreElements();
+   if (next != null) {
+   return true;
+   }
+   if (enum.hasMoreElements()) {
+   try {
+   NamingEntry entry = (NamingEntry)enum.nextElement();
+   String name = entry.name;
+   Object obj = 
NamingManager.getObjectInstance(entry.value, new
CompositeName(name), ctx, env);
+   next = new Binding(name, 
entry.value.getClass().getName(), obj, true);
+   return true;
+   } catch (NamingException e) {
+   trouble = e;
+   } catch (RuntimeException e) {
+   trouble = e;
+   runtimeExc = true;
+   } catch (Exception e) {
+   NamingException ne = new NamingException();
+   ne.setRootCause(e);
+   trouble = ne;
+   }
+   }
+   if (trouble != null) {
+   if (runtimeExc) {
+   throw (RuntimeException)trouble;
+   } else {
+   throw (NamingException)trouble;
+   }
+   }
+   return false;
 }
 
 
@@ -133,16 +174,17 @@
 }
 
 
-public boolean hasMoreElements() {
-return enum.hasMoreElements();
-}
-
-
-public Object nextElement() {
-NamingEntry entry = (NamingEntry) enum.nextElement();
-r

Mavenized Tomcat

2003-10-20 Thread Ted Weatherly

Does anyone out there currently build Tomcat using maven (as opposed to 
building it using Ant)?  If so, would you mind sharing your project.xml 
and maven.xml files?

Thanks.

-Ted

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

DO NOT REPLY [Bug 23948] New: - HTTP upload slow when Solaris and Internet Explorer

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23948

HTTP upload slow when Solaris and Internet Explorer

   Summary: HTTP upload slow when Solaris and Internet Explorer
   Product: Tomcat 5
   Version: 5.0.12
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Connector:HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I found that HTTP uploads are very slow when using Tomcat on Solaris and 
Internet Explorer on Windows. I tested with Tomcat 5.0.12, J2SE 1.4.2_01, 
Solaris 8 with a recent patch cluster installed, Internet Explorer 6 on 
Windows XP and Windows 2000 with Windows updates applied. The test was 
performed using a 100 Mbs Ethernet network. Internet Explorer consistently 
only uploads at about 80 KBs. The problem seems to be specific to Internet 
Explorer. Mozilla 1.5 can upload at about 3 MBs. The problem also seems to be 
specific to Solaris. I tested with the same version of Tomcat and J2SE on 
Linux and the problem didn't occur. Internet Explorer was able to upload at 
over 4 MBs to my Linux computer. I also tested with a local copy of Tomcat on 
my Windows computer and the problem didn't occur there either. I also tested 
with Tomcat 4.1.24 and the problem occurred there as well.

Also, I have a Perl application on another Solaris computer which is able to 
perform HTTP uploads without a problem. So, the problem seems to be a 
combination of Solaris, Tomcat, and Internet Explorer.

The following is the application that I used to test the problem. The 
application doesn't actually decode the HTTP upload, only reads from the 
stream, so, the problem seems to be with the network code. Could it be a 
buffer size issue?

I've noticed other odd things as well. For example I found that Mozilla 
actually gets better data transfer rates using HTTPS rather than HTTP.

import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class FileUpload3 extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp) 
throws IOException {
try {
resp.setContentType("text/html");
PrintWriter pw = resp.getWriter();
pw.println("http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd\">");
pw.println("File 
Upload");
pw.println("");
pw.println("File: ");
pw.println("");
pw.println("");
pw.println("");
pw.close();
}
catch(Exception e) {
e.printStackTrace();
}
}

public void doPost(HttpServletRequest req, HttpServletResponse resp) 
throws IOException {
try {
Date d = new Date();
ServletInputStream sis = req.getInputStream();
while(sis.read() != -1);
sis.close();
Date d2 = new Date();
TimeSpan ts = new TimeSpan(d, d2);
resp.setContentType("text/html");
PrintWriter pw = resp.getWriter();
pw.println("http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd\">");
pw.println("File 
Upload");
pw.println("");
pw.println("" + ts + "");
pw.println("");
pw.println("");
pw.close();
}
catch(Exception e) {
e.printStackTrace();
}
}
}

import java.text.*;
import java.util.*;

public class TimeSpan {
public TimeSpan(Date startDate, Date endDate) {
long l = (endDate.getTime() - startDate.getTime()) / 1000;
hours = l / 60 / 60;
minutes = l / 60 - (hours * 60);
seconds = l - (hours * 60 * 60) - (minutes * 60);
}

public String toString() {
Object[] o = {new Long(hours), new Long(minutes), new Long
(seconds)};
return new MessageFormat("{0,number,00}:{1,number,00}:
{2,number,00}").format(o);
}

public long hours;
public long minutes;
public long seconds;
}

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

New builds ?

2003-10-20 Thread Remy Maucherat

So, what do we do with 4.1.28 ? AFAIK, no significant issue has been 
found with this build, with minor tweaks being made since then in the 
connectors.
Is a 4.1.29 needed, or is it simply people forgot about that build ?

OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the 
5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13 
builds are all cursed :-D).

Comments ?

Remy



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

I don't know why apache don't load module mod_jk.

2003-10-20 Thread chy

Good morning.
(BPlease teach me.
(B
(BI am using Apache Server2.0.47  and Tomcat4.1.27 on Redhat9.0.
(BI install only necessary packages of redhat9.0.
(BThere contains libtool, libtool-libs, and so on.
(BBut it can't load jk_module.
(B
(BI want to teach the required  package list at least.

DO NOT REPLY [Bug 15680] - Wellcome file redirect looses session

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15680

Wellcome file redirect looses session

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 13:06 ---
*** Bug 22230 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 22230] - welcome-page redirections don't preserve sessionid

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=22230

welcome-page redirections don't preserve sessionid

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 13:06 ---


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

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

DO NOT REPLY [Bug 22230] - welcome-page redirections don't preserve sessionid

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=22230

welcome-page redirections don't preserve sessionid

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 13:02 ---
*** Bug 23936 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 23936] - DefaultServlet loses session ID when sending redirect

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23936

DefaultServlet loses session ID when sending redirect

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 13:02 ---


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

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

DO NOT REPLY [Bug 23936] New: - DefaultServlet loses session ID when sending redirect

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23936

DefaultServlet loses session ID when sending redirect

   Summary: DefaultServlet loses session ID when sending redirect
   Product: Tomcat 4
   Version: 4.1.27
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When cookies can not be used (for whatever reason) session tracking is done by 
using suffix ";jsessionid=..." appended to URLs. However, when DefaultServlet 
sends redirect response for default welcome file (like from "<...>/somedir/" 
to "<...>/somedir/index.jsp") the "jsessionid" suffix is lost.

Suggested resolution: in DefaultServlet.java all (2) occurences of
response.sendRedirect(redirectPath);
should be replaced with:
response.sendRedirect(response.encodeRedirectURL(redirectPath));

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

RE: jk2 evolution plan

2003-10-20 Thread Mladen Turk



> From: Henri Gomez 
> 
> 
> Mladen Turk wrote:
> 
> > 
> >>From: Bill Barker
> >>
> >>I could get on-board with this, after Mladen's suggestion to
> >>change the return-type of most methods to jk_status_t.  
> >>Without this, mod_jk2 is hopelessly broken (and I'll contunue 
> >>to ignore it :).
> >>
> > 
> > 
> > 
> > It's to apr_status_t ;-).
> > Sill, takes a bit more time then I thought It would.
> > Not just to return APR_SUCCESS, but to return the meaningful error 
> > codes that can be logged.
> > 
> > So day or two...
> 
> So it will be apr_status_t ?
> 

Yes, It is IMO the most straighforward.
If the APR API call fails the calee will return the same error code,
without the need to reinvent our own error codes.
The jk2 specific error codes will beging from
APR_OS_START_USERERR + 1.

MT.


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

DO NOT REPLY [Bug 22677] - JNDI not working in Default Context

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=22677

JNDI not working in Default Context





--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 11:10 ---
I have been dealing with the same problem for a few days and managed to find 
one solution for it.
I'm using Tomcat 4.1.27 and Sybase database running on Win2K(also tried in XP 
and same assembly worked fine).

In my server.xml I have Context under  as follows:

   
 
  

  factory
  org.apache.commons.dbcp.BasicDataSourceFactory


  maxActive
  10


  maxIdle
  2


  maxWait
  1


 username
 report


 password
 report


   driverClassName
   com.sybase.jdbc2.jdbc.SybConnectionPoolDataSource


  url
  jdbc:sybase:Tds:xxx:5000/dbname


  removeAbandoned
  true
  
  
  removeAbandonedTimeout
  60

  
  

In my web.xml I have:


   Sybase Datasource
   jdbc/dbref
   javax.sql.DataSource
   Container


,and in Java:
Context initContext = new InitialContext();
Context envContext  = (Context)initContext.lookup("java:/comp/env");
dataSource = (javax.sql.DataSource)envContext.lookup(dataSourceName);
Connection con = dataSource.getConnection();

I installed Java 2 Runtime Environment 1.4.2_01 and modified system variables:
JAVA_HOME = "j2re 1.4.2_01 install dir"
CLASSPATH = "3rd party database driver jar directory"
CATALINA_HOME = "Tomcat install dir"

Although Jakarta Tomcat 4.1 "JNDI Datasource HOW-TO" docs adviced not to 
install 3rd party database drivers anywhere else than in 
$CATALINA_HOME/common/lib I tried adding jar into CLASSPATH and it worked fine.
Make sure you have jre installed and JAVA_HOME set into that dir and it should 
work fine.

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

DO NOT REPLY [Bug 22677] - JNDI not working in Default Context

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=22677

JNDI not working in Default Context

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

DO NOT REPLY [Bug 23860] - flag unmatched ending tags(was Struts: warn if logic tags are prematurely terminated)

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860

flag unmatched ending tags(was Struts: warn if logic tags are prematurely terminated)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|struts- |tomcat-
   |[EMAIL PROTECTED]  |[EMAIL PROTECTED]
 Status|REOPENED|NEW

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

DO NOT REPLY [Bug 23908] - Occasional Access Violation Exception in the VM when sockets don't bind

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23908

Occasional Access Violation Exception in the VM when sockets don't bind

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 10:38 ---
VM crashes are VM bugs, not Tomcat issues.

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

DO NOT REPLY [Bug 23929] - request.setCharacterEncoding(String) doesn't work

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929

request.setCharacterEncoding(String) doesn't work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 10:37 ---
Sorry, there's no bug. BZ is not there to discuss design decisions. If you want
to do so, post on tomcat-dev. The only standard for URL encoding is to use
UTF-8, but nobody follows the standard. You can also now configure the URI
encoding in the connector. If you insist on using i18n with URL parameters, the
result is that it won't work reliably, but of course, you're free to do what you
want ;-)
Please do not reopen the report.

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

DO NOT REPLY [Bug 23929] - request.setCharacterEncoding(String) doesn't work

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929

request.setCharacterEncoding(String) doesn't work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 10:30 ---
Sorry, but I don't understand. Is there a bug in this or not? If it is, why did
you mark this report as invalid? If not, what I have to do to make it work in my
configuration?

I don't want to use POST, because HTTP RFC says when to use GET and when POST
and I'm convinced that in my situation GET is better option and should be used.

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

DO NOT REPLY [Bug 23929] - request.setCharacterEncoding(String) doesn't work

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929

request.setCharacterEncoding(String) doesn't work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-20 09:58 ---
I doubt there's actually a bug with this functionality. The query string
character encoding handling did change, but it was previously broken.
If you want i18n in a portable fashion, use a POST.

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

Re: jk2 evolution plan

2003-10-20 Thread Henri Gomez

Mladen Turk wrote:


From: Bill Barker

I could get on-board with this, after Mladen's suggestion to 
change the return-type of most methods to jk_status_t.  
Without this, mod_jk2 is hopelessly broken (and I'll contunue 
to ignore it :).



It's to apr_status_t ;-).
Sill, takes a bit more time then I thought It would.
Not just to return APR_SUCCESS, but to return the meaningful
error codes that can be logged.
So day or two...
So it will be apr_status_t ?

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

DO NOT REPLY [Bug 23929] New: - request.setCharacterEncoding(String) doesn't work

2003-10-20 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23929

request.setCharacterEncoding(String) doesn't work

   Summary: request.setCharacterEncoding(String) doesn't work
   Product: Tomcat 5
   Version: 5.0.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I use following construction to set request character encoding:

if (request.getCharacterEncoding() == null) {
request.setCharacterEncoding("ISO8859-2");
}

In older versions of Tomcat (5.0.7 tested) everything works fine but in version
5.0.12 this construction changes nothing - ISO8859-2 characters in parameter
values are replaced with "?".

$ java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

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

RE: jk2 evolution plan

2003-10-20 Thread Mladen Turk



> From: Bill Barker
> 
> I could get on-board with this, after Mladen's suggestion to 
> change the return-type of most methods to jk_status_t.  
> Without this, mod_jk2 is hopelessly broken (and I'll contunue 
> to ignore it :).
> 


It's to apr_status_t ;-).
Sill, takes a bit more time then I thought It would.
Not just to return APR_SUCCESS, but to return the meaningful
error codes that can be logged.

So day or two...

MT.



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

Re: jk2 evolution plan

2003-10-20 Thread Bill Barker

- Original Message - 
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 20, 2003 12:53 AM
Subject: Re: jk2 evolution plan

> Glenn Nielsen wrote:
>
> > +1
> >
> > I can help out.
> >
> > This is a significant change for a minor revision to 2.0.4,
> > perhaps we should bump it to 2.1 or even 3.0?
>
> Since it's an 'internal rewrite', it should stay 2.x, may be
> 2.1 could be the right name
>
> But first we should cleanup all jk2 from #iddef APR defines and
> custom OS includes.
>

I could get on-board with this, after Mladen's suggestion to change the
return-type of most methods to jk_status_t.  Without this, mod_jk2 is
hopelessly broken (and I'll contunue to ignore it :).

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

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: Tomcat 5/4 DefaultContext Listener/Loader

2003-10-20 Thread Remy Maucherat

Glenn Nielsen wrote:

The docs for both Tomcat 4 and 5 imply that you can nest a Context 
Listener inside
the DefaultContext.  But this had not been implemented.

I had a need to implement a custom Context Listener and Custom Loader 
(WebappLoader)
which needed to be configurable using the DefaultContext.

I have patches for both Tomcat 4 and Tomcat 5 which implement the ability
to configure a nested Context Listener and a nested Webapp Loader inside
the DefaultContext.
Why not ?

When developing that patches I did not change any published interfaces, 
though
the internal catalina implementation had to be slightly modified.

I can commit this to Tomcat 5 first, then if everyone is ok with it,
commit the Tomcat 4 version of the patches.
If you are certain it is not going to cause any regression ;-)

Remy



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

Re: jk2 evolution plan

2003-10-20 Thread Henri Gomez

Glenn Nielsen wrote:

+1

I can help out.

This is a significant change for a minor revision to 2.0.4,
perhaps we should bump it to 2.1 or even 3.0?
Since it's an 'internal rewrite', it should stay 2.x, may be
2.1 could be the right name
But first we should cleanup all jk2 from #iddef APR defines and
custom OS includes.


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

40 matches

Mail list logo