DO NOT REPLY [Bug 11798] New: - use of response.flushBuffer in .jsp script results in unterminated HTTP response/ browser hangs

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

use of response.flushBuffer in .jsp script results in unterminated HTTP response/ 
browser hangs

   Summary: use of response.flushBuffer in .jsp script results in
unterminated HTTP response/ browser hangs
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


With the default tomcat configuration from the download, executing the script
shown below (e.g. by dropping it into webapps/examples) will send back the
proper HTML to the browser, but the browser will hang (I tired Mox 1.0 and IE6),
seemingly because the connection is not properly terminated. The script works
fine if the response.flushBuffer() call is removed. 

I tried this with both 4.0.4 and 4.1.9. On the bright side, it does flush just
fine ...




Begin 

<%
   response.flushBuffer ();
%>

End 




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

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler CharDataGenerator.java MappedCharDataGenerator.java

[keith]

keith   2002/08/17 18:53:38

  Modified:src/share/org/apache/jasper/compiler CharDataGenerator.java
MappedCharDataGenerator.java
  Log:
  Jasper fix for high byte chars (xlate to unicode)
  Submitted by: Thibault Frey
  
  Revision  ChangesPath
  1.6   +17 -5 
jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java
  
  Index: CharDataGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CharDataGenerator.java4 Dec 2001 02:21:04 -   1.5
  +++ CharDataGenerator.java18 Aug 2002 01:53:38 -  1.6
  @@ -123,7 +123,7 @@
sb.append("\\t");
break;
default:
  - sb.append((char) ch);
  + this.writeChar((char) ch, sb);
}
}
writer.print(sb.toString());
  @@ -131,6 +131,18 @@
writer.println();
   }
   
  -
  +protected void writeChar( char c, StringBuffer buf ) {
  +if ( c < 128 )
  + // if char is pure ASCII -> write it
  +buf.append( c );
  +else {
  +// if char isn't pure ASCII -> write it's unicode
  +buf.append( "\\u" );
  +String hexa = Integer.toHexString( c );
  +for( int i = hexa.length() ; i < 4 ; i++ )
  +buf.append( '0' );
  +buf.append( hexa );
  +}
  +}
   
   }
  
  
  
  1.5   +4 -4  
jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java
  
  Index: MappedCharDataGenerator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/MappedCharDataGenerator.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- MappedCharDataGenerator.java  4 Dec 2001 02:21:04 -   1.4
  +++ MappedCharDataGenerator.java  18 Aug 2002 01:53:38 -  1.5
  @@ -113,7 +113,7 @@
sb.append("\\t");
break;
default:
  - sb.append((char) ch);
  + this.writeChar((char) ch, sb);
}
}
writer.print(sb.toString());
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/conf catalina.policy

[glenn]

glenn   2002/08/17 17:56:09

  Modified:catalina/src/conf catalina.policy
  Log:
  Cleanup policy for release
  
  Revision  ChangesPath
  1.25  +56 -56jakarta-tomcat-4.0/catalina/src/conf/catalina.policy
  
  Index: catalina.policy
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/catalina.policy,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- catalina.policy   19 Jul 2002 12:38:34 -  1.24
  +++ catalina.policy   18 Aug 2002 00:56:09 -  1.25
  @@ -17,23 +17,23 @@
   
   // These permissions apply to javac
   grant codeBase "file:${java.home}/lib/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to all shared system extensions
   grant codeBase "file:${java.home}/jre/lib/ext/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
   grant codeBase "file:${java.home}/../lib/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to all shared system extensions when
   // ${java.home} points at $JAVA_HOME/jre
   grant codeBase "file:${java.home}/lib/ext/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   
  @@ -42,39 +42,39 @@
   
   // These permissions apply to the server startup code
   grant codeBase "file:${catalina.home}/bin/bootstrap.jar" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the servlet API classes
   // and those that are shared across all class loaders
   // located in the "common" directory
   grant codeBase "file:${catalina.home}/common/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the container's core code, plus any additional
   // libraries installed in the "server" directory
   grant codeBase "file:${catalina.home}/server/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the jasper page compiler.
   grant codeBase "file:${catalina.home}/shared/lib/jasper-compiler.jar" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the jasper JSP runtime
   grant codeBase "file:${catalina.home}/shared/lib/jasper-runtime.jar" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the privileged admin and manager web applications
   grant codeBase "file:${catalina.home}/server/webapps/admin/WEB-INF/classes/-" {
  -permission java.security.AllPermission;  
  +  permission java.security.AllPermission;  
   };
   
   grant codeBase "file:${catalina.home}/server/webapps/admin/WEB-INF/lib/struts.jar" {
  -permission java.security.AllPermission;  
  +  permission java.security.AllPermission;  
   };
   
   // == WEB APPLICATION PERMISSIONS =
  @@ -84,47 +84,47 @@
   // In addition, a web application will be given a read FilePermission
   // and JndiPermission for all files and directories in its document root.
   grant { 
  -// Required for JNDI lookup of named JDBC DataSource's and
  -// javamail named MimePart DataSource used to send mail
  -permission java.util.PropertyPermission "java.home", "read";
  -permission java.util.PropertyPermission "java.naming.*", "read";
  -permission java.util.PropertyPermission "javax.sql.*", "read";
  -
  -// OS Specific properties to allow read access
  - permission java.util.PropertyPermission "os.name", "read";
  - permission java.util.PropertyPermission "os.version", "read";
  - permission java.util.PropertyPermission "os.arch", "read";
  - permission java.util.PropertyPermission "file.separator", "read";
  - permission java.util.PropertyPermission "path.separator", "read";
  - permission java.util.PropertyPermission "line.separator", "read";
  -
  -// JVM properties to allow read access
  -permission java.util.PropertyPermission "java.version", "read";
  -permission java.util.PropertyPermission "java.vendor", "read";
  -permission java.util.PropertyPermission "java.vendor.url", "read";
  -permission java.util.PropertyPermission "java.class.version", "read";
  - permission java.util.PropertyPermission "java.specification.version", "read";
  - permission java.util.PropertyPermiss

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-datasource-examples-howto.xml

[glenn]

glenn   2002/08/17 17:55:25

  Modified:webapps/tomcat-docs jndi-datasource-examples-howto.xml
  Log:
  Update docs for DBCP 1.0 release, cleanup, and add more info
  
  Revision  ChangesPath
  1.4   +312 -150  
jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-datasource-examples-howto.xml
  
  Index: jndi-datasource-examples-howto.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-datasource-examples-howto.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jndi-datasource-examples-howto.xml5 Jul 2002 13:17:46 -   1.3
  +++ jndi-datasource-examples-howto.xml18 Aug 2002 00:55:25 -  1.4
  @@ -9,66 +9,162 @@
   
   Les Hughes
   David Haraburda
  -JNDI Datasource Examples HOW-TO
  +Glenn Nielsen
  +JNDI Datasource HOW-TO
   
   
   
   
  +
  +
  +Introduction
  +
  +Database Connection Pool (DBCP) Configurations
  +Tyrex Connection Pool
  +Non DBCP Solutions
  +Oracle 8i with OCI client
  +Common Problems
  +
  +
   
   
  -JNDI Datasource configuration is covered extensively in the JNDI-Resources-HOWTO 
  -however, feedback from tomcat-user has shown that specifics for 
individual 
  -configurations can be rather tricky.
   
  -Here then are some example configurations that have posted to tomcat-user
  -for popular databases.
  +JNDI Datasource configuration is covered extensively in the
  +JNDI-Resources-HOWTO however, feedback from tomcat-user has
  +shown that specifics for individual configurations can be rather tricky.
  +
  +Here then are some example configurations that have been posted to
  +tomcat-user for popular databases and some general tips for db useage.
  +
  +You should be aware that since these notes are derived from configuration
  +and/or feedback posted to tomcat-user YMMV :-). Please let us
  +know if you have any other tested configurations that you feel may be of use
  +to the wider audience, or if you feel we can improve this section in anyway.
  +
   
  -
  -For each of these configurations you will need the following Jakarta Commons 
projects
  -Note that currently, these all employ connection pooling
  -via the Jakarta-commons connection pool. Also, you should be aware that since these 
  -notes are derived from the mysql configuration and/or feedback from 
tomcat-user. 
  -YMMV :-). Please let us know if you have any other tested configurations
  -that you feel may be of use to the wider audience, or if you feel we can 
  -improve this section
  -in anyway.
  +
  +
  +
  +DBCP provides support for JDBC 2.0.  On systems using a 1.4 JVM DBCP
  +will support JDBC 3.0. Please let us know if you have used DBCP and its
  +JDBC 3.0 features with a 1.4 JVM.
  +
  +
  +See the http://jakarta.apache.org/commons/dbcp/api/index.html";>
  +DBCP Javadocs BasicDataSource class for a complete list
  +of configuration parameters.
  +
  +
  +
  +DBCP uses the Jakarta-Commons Database Connection Pool. It relies on
  +number of Jakarta-Commons componenets:
   
  -DBCP Nightly build > 20020523
  -collections 2.0
  -pool 1.0
  +Jakarta-Commons DBCP 1.0
  +Jakarta-Commons Collections 2.0
  +Jakarta-Commons Pool 1.0
   
  -
  -Here are some common gotchas to consider
  +These jar files along with your the jar file for your JDBC driver should
  +be installed in $CATALINA_HOME/common/lib.
  +
  +NOTE:Third Party drivers should be in jarfiles, not zipfiles.
  +Tomcat only adds $CATALINA_HOME/common/lib/*.jar to the classpath.
  +
  +
  +NOTE:
  +Do not install these jarfiles in your /WEB-INF/lib, or
  +$JAVA_HOME/jre/lib/ext, or anywhere else.  You will
  +experience problems if you install them anyplace other than
  +$CATALINA_HOME/common/lib.
  +
  +
  +
  +
  +
  +
  +
  +
  +A database connection pool creates and manages a pool of connections
  +to a database. Recycling and reusing already existing connections
  +to a dB is more efficient than opening a new connection.
  +
  +
  +
  +There is one problem with connection pooling.  A web application has
  +to explicetely close ResultSet's, Statement's, and Connection's.
  +Failure of a web application to close these resources can result in
  +them never being available again for reuse, a db connection pool "leak".
  +This can eventually result in your web application db connections failing
  +if there are no more available connections.
  +
  +
  +There is a solution to this problem.  The Jakarta-Commons DBCP can be
  +configured to track and recover these abandoned dB connections.  Not
  +only can it recover them, but also generate a stack trace for the code
  +which opened these resources and never closed them.
  +
  +
  +To configure a DBCP DataSource so that abandoned dB connections are
  +removed and recycled add the following paramater to the
  +ResourceParams configuration for your DBCP DataSource
  +Resource:
  +
  +

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

[glenn]

glenn   2002/08/17 17:54:48

  Modified:webapps/tomcat-docs security-manager-howto.xml
  Log:
  Update security docs for pending release
  
  Revision  ChangesPath
  1.3   +68 -63
jakarta-tomcat-4.0/webapps/tomcat-docs/security-manager-howto.xml
  
  Index: security-manager-howto.xml
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/security-manager-howto.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- security-manager-howto.xml13 May 2002 14:29:36 -  1.2
  +++ security-manager-howto.xml18 Aug 2002 00:54:48 -  1.3
  @@ -154,7 +154,6 @@
   //
   // * Read access to the document root directory
   //
  -// $Id$
   // 
   
   
  @@ -163,23 +162,23 @@
   
   // These permissions apply to javac
   grant codeBase "file:${java.home}/lib/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to all shared system extensions
   grant codeBase "file:${java.home}/jre/lib/ext/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
   grant codeBase "file:${java.home}/../lib/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to all shared system extensions when
   // ${java.home} points at $JAVA_HOME/jre
   grant codeBase "file:${java.home}/lib/ext/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   
  @@ -188,38 +187,39 @@
   
   // These permissions apply to the server startup code
   grant codeBase "file:${catalina.home}/bin/bootstrap.jar" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the servlet API classes
   // and those that are shared across all class loaders
   // located in the "common" directory
   grant codeBase "file:${catalina.home}/common/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
   // These permissions apply to the container's core code, plus any additional
   // libraries installed in the "server" directory
   grant codeBase "file:${catalina.home}/server/-" {
  -permission java.security.AllPermission;
  +  permission java.security.AllPermission;
   };
   
  -// These permissions apply to the jasper page compiler
  -// located in the "jasper" directory.
  -grant codeBase "file:${catalina.home}/jasper/-" {
  -permission java.security.AllPermission;
  +// These permissions apply to the jasper page compiler.
  +grant codeBase "file:${catalina.home}/shared/lib/jasper-compiler.jar" {
  +  permission java.security.AllPermission;
   };
   
  -// These permissions apply to shared web application libraries
  -// including the Jasper runtime library installed in the "lib" directory
  -grant codeBase "file:${catalina.home}/lib/-" {
  -permission java.security.AllPermission;
  +// These permissions apply to the jasper JSP runtime
  +grant codeBase "file:${catalina.home}/shared/lib/jasper-runtime.jar" {
  +  permission java.security.AllPermission;
   };
   
  -// These permissions apply to shared web application classes
  -// located in the "classes" directory
  -grant codeBase "file:${catalina.home}/classes/-" {
  -permission java.security.AllPermission;
  +// These permissions apply to the privileged admin and manager web applications
  +grant codeBase "file:${catalina.home}/server/webapps/admin/WEB-INF/classes/-" {
  +  permission java.security.AllPermission;  
  +};
  +
  +grant codeBase "file:${catalina.home}/server/webapps/admin/WEB-INF/lib/struts.jar" {
  +  permission java.security.AllPermission;  
   };
   
   // == WEB APPLICATION PERMISSIONS =
  @@ -229,41 +229,47 @@
   // In addition, a web application will be given a read FilePermission
   // and JndiPermission for all files and directories in its document root.
   grant { 
  -// Required for JNDI lookup of named JDBC DataSource's and
  -// javamail named MimePart DataSource used to send mail
  -permission java.util.PropertyPermission "java.home", "read";
  -permission java.util.PropertyPermission "java.naming.*", "read";
  -permission java.util.PropertyPermission "javax.sql.*", "read";
  -
  -// OS Specific properties to allow read access
  - permission java.util.PropertyPermission "os.name", "read";
  - permission java.util.PropertyPermission "os.version", "read";
  - permission java.util.PropertyPermission "os.arch", "read";
 

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

[glenn]

glenn   2002/08/17 17:54:26

  Modified:webapps/tomcat-docs index.xml
  Log:
  Add JNDI Datasource HOW-TO to application section
  
  Revision  ChangesPath
  1.14  +4 -0  jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- index.xml 9 Sep 2001 22:43:48 -   1.13
  +++ index.xml 18 Aug 2002 00:54:26 -  1.14
  @@ -65,6 +65,10 @@
   Class Loader HOW-TO
   - Information about class loading in Tomcat 4, including where to place
   your application classes so that they are visible.
  +
  +JNDI DataSource HOW-TO
  +- Configuring a JNDI DataSoure with a dB connection pool.
  +Examples for many popular databases.
   JNDI Resources HOW-TO
   - Configuring standard and custom resources in the JNDI naming context
   that is provided to each web application.
  
  
  

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

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

[glenn]

glenn   2002/08/17 17:53:54

  Modified:webapps/tomcat-docs project.xml
  Log:
  Alphabetize application links
  
  Revision  ChangesPath
  1.15  +2 -2  jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- project.xml   3 Jul 2002 17:42:53 -   1.14
  +++ project.xml   18 Aug 2002 00:53:54 -  1.15
  @@ -25,9 +25,9 @@
   
   
   
  -
  -
  +
   
   
   
  
  
  

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

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
> Steve Downey wrote:

> >
> > The real problem, for the servlet spec implementation, is that not just
> > getHeaders() is affected. getHeader() must be also. getHeader, if there
> > are multiple values, needs to return the same thing as the first value
> > returned by getHeaders(), not the whole header from the first of multiple
> > headers.
>
> Sorry, but no. The opposite statement doesn't work.
> getHeader MUST return the first header line, unless in the case there
> are multiple headers with the same name in the client message, in which
> case you would know that they can be parsed/combined at will.
>
> Since it is too complex and inefficient to implement that, I'd leave it
> at that, and let the application handle the cases where the client is
> having some fun.
>
> Remy
Given:
H:A,B
H:C

getHeader() should either return ``A'' or ``A,B,C''. Returning ``A,B'', as it 
does now, can't be right. It introduces semantic differences between multiple 
headers and comma-separated lists where their must be none. 

The problem is that the client has no way of telling if it's supposed to use 
getHeader or getHeaders. Other than saying that if it's possible for there to 
be multiple values, you have to use getHeaders.

IAC, why must getHeader return the first header line? It's documented to 
return 'the first head  in the request', or 'a String containing the 
value of the requested header'.  If getHeaders() returns 'all the values of 
the specified request header', and returns ``A'' rather than ``A,B'', then 
it's inconsistent for getHeader to return ``A, B''.

If a servlet really wants to do the parsing itself, then getHeader only gets 
it part of the headers, and it has no way of getting all of the header lines, 
since getHeaders() doesn't do that, according to the interpretation of the 
spec embodied in Watchdog, the basis for the TCK. 

Complex and inefficient might be a reason for _changing_ the spec. It's a bad 
reason for not implementing the spec. Also, I don't think it's that bad. The 
cases where multiple values are allowed is denumerable. So it comes down to 
creating an enumerator that can run seamlessly over the values in distinct 
header lines. 

Now, I'll admit this is all a bit on the language-lawyerish 
angels-dancing-on-pins side. But this is the reference implementation, and it 
is currently failing the servlet test suite.  

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

Re: Watchdog aggregation of headers may be incorrect

[Remy Maucherat]

Steve Downey wrote:
> On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote:
> 
>>Steve Downey wrote:
>>
>>>On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
>>>
Patrick Luby wrote:

>Steve,
>
>Your assessment is correct: an aggregate header like:
>
> header1: val1, val2
>
>should be converted to this for the HttpRequest:
>
> header1: val1
> header1: val2

No, this is not correct.

You are allowed to do that only if the application knows it makes sense
to do so (ie, only when it call getHeaders).
>>>
>>>If it is to be done, it should be done based on what the HTTP/1.1 spec
>>>defines. The application needs to expect the possibility of multiple
>>>values for all of the headers that allow them. Or just ask for the first
>>>one. Parsing the header line into values probably shouldn't be left to
>>>the application, although it is at the moment.
>>
>>I gave you the HTTP/1.1 answer.
>>
>>For Header H: A,B
>>If A,B
>>is semantically equivalent to:
>>H: A
>>H: B
>>then you can parse for the comma.
>>
>>So since you can't know what the application considers to be
>>semantically equivalent, the fact that it calls getHeaders is a big
>>hint, and you can do the comma parsing.
>>
>>Please read the HTTP specification.
>>
> 
> 
> I keep a copy handy, for just such an occasion. However, my reading is someone 
> different from yours. I think this is the relevant section  [RFC 2616, 
> section 4.2], that describes what happens when multiple headers are sent:
> 
>Multiple message-header fields with the same field-name MAY be
>present in a message if and only if the entire field-value for that
>header field is defined as a comma-separated list [i.e., #(values)].
>It MUST be possible to combine the multiple header fields into one
>"field-name: field-value" pair, without changing the semantics of the
>message, by appending each subsequent field-value to the first, each
>separated by a comma. The order in which header fields with the same
>field-name are received is therefore significant to the
>interpretation of the combined field value, and thus a proxy MUST NOT
>change the order of these field values when a message is forwarded.
> 
> So it's saying the opposite:
> H:A
> H:B
> 
> MUST be semantically equivalent to
> H:A,B
> 
> as long as H is defined to have be a comma separated list. If it doesn't, it 
> seems the result is undefined.

I agree up until now.

> Now, the spec refers to not changing the semantics, but the MUST means that it 
> is a requirement for the implementation. In other words, if combining the two 
> headers into one comma separated list, for headers with a #(values) content 
> model, changes the semantics, the implementation is non-conformant. The 
> specification does not require that the implementation guess at the semantics 
> an application believes apply, the specification defines the semantics that 
> will apply.
> 
> The real problem, for the servlet spec implementation, is that not just 
> getHeaders() is affected. getHeader() must be also. getHeader, if there are 
> multiple values, needs to return the same thing as the first value returned 
> by getHeaders(), not the whole header from the first of multiple headers.

Sorry, but no. The opposite statement doesn't work.
getHeader MUST return the first header line, unless in the case there 
are multiple headers with the same name in the client message, in which 
case you would know that they can be parsed/combined at will.

Since it is too complex and inefficient to implement that, I'd leave it 
at that, and let the application handle the cases where the client is 
having some fun.

Remy


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

Re: [5] [TODO] Config first task

[Costin Manolache]

Remy Maucherat wrote:

> I don't understand why you think it's the same.
> 
> For the ENC, you do something like:
> (new InitialContext()).lookup("java:/comp/env/maxExemptions");
> 
> So you need the thread or CL binding to retrive the JNDI Context where
> maxExemptions is.
> 
> For the config, you can for example give StandardContext a reference to
> the DirContext which contains the webapp configuration data. So no
> thread binding needed.

I think we're talking about different things.

Say I want to read WEB-INF/web.xml for application /examples. 
Right now it seems what I have to do requires the use of the thread
or cl binding to locate the jndi context representing the war/files.

What I would like to do from inside tomcat is:
 globalContext.lookup("host=localhost:8080, path=/examples, 
file=/WEB-INF/web.xml") 

( or some / based name: FILES:/localhost:8080/examples/WEB-INF/web.xml ).

I couldn't find any way to do that. 

For the java:/comp/env - yes, the Context must be bound so that
the app can locate it using the InitialContext(). But it can 
also be bound in the 'globalContext' - so that an admin app or 
some listeners can see/alter the webapp bindings.  

What I'm trying to say is that thread/classloader binding is 
required in some cases, but it can be avoided in many other cases. And
in general there are a lot of 'tricky' things about it ( like if you 
create a new thread and the binding no longer works ).


>> Sure. Just trying to get feedback and maybe get other people interested.
>> So far only 2 people seem interested in 'common-discovery'.
> 
> I didn't look at it at all, sorry :-(

It's about using META-INF/services, and in general about supporting a 
pattern where each .jar includes some resource with a fixed name 
and you want to manipulate it.

Examples:
- locate Listeners/Valves/Interceptors that are installed, so that the
admin can display all available modules
- locate and automatically load any META-INF/mbeans.xml so that each module
can register his own description transparently
- possibly META-INF/ant.tasks ( or just 
META-INF/services/org.apache.tools.ant.ProjectComponent ) - and have the 
tasks automatically declared
- declare some interface for tomcat configurator ( like ant's ProjectHelper)
and have it loaded automatically. ( or different configurators that are 
available, each getting a chance to configure )
- declare the JNDI providers or JDBC drivers so you don't need to 
explicitely declare them
- support multiple parsers - and have a way to choose which one to use
( instead of 'select first' )

And so on.

Costin





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

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote:
> Steve Downey wrote:
> > On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> >>Patrick Luby wrote:
> >>>Steve,
> >>>
> >>>Your assessment is correct: an aggregate header like:
> >>>
> >>>  header1: val1, val2
> >>>
> >>>should be converted to this for the HttpRequest:
> >>>
> >>>  header1: val1
> >>>  header1: val2
> >>
> >>No, this is not correct.
> >>
> >>You are allowed to do that only if the application knows it makes sense
> >>to do so (ie, only when it call getHeaders).
> >
> > If it is to be done, it should be done based on what the HTTP/1.1 spec
> > defines. The application needs to expect the possibility of multiple
> > values for all of the headers that allow them. Or just ask for the first
> > one. Parsing the header line into values probably shouldn't be left to
> > the application, although it is at the moment.
>
> I gave you the HTTP/1.1 answer.
>
> For Header H: A,B
> If A,B
> is semantically equivalent to:
> H: A
> H: B
> then you can parse for the comma.
>
> So since you can't know what the application considers to be
> semantically equivalent, the fact that it calls getHeaders is a big
> hint, and you can do the comma parsing.
>
> Please read the HTTP specification.
>

I keep a copy handy, for just such an occasion. However, my reading is someone 
different from yours. I think this is the relevant section  [RFC 2616, 
section 4.2], that describes what happens when multiple headers are sent:

   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

So it's saying the opposite:
H:A
H:B

MUST be semantically equivalent to
H:A,B

as long as H is defined to have be a comma separated list. If it doesn't, it 
seems the result is undefined.

Now, the spec refers to not changing the semantics, but the MUST means that it 
is a requirement for the implementation. In other words, if combining the two 
headers into one comma separated list, for headers with a #(values) content 
model, changes the semantics, the implementation is non-conformant. The 
specification does not require that the implementation guess at the semantics 
an application believes apply, the specification defines the semantics that 
will apply.

The real problem, for the servlet spec implementation, is that not just 
getHeaders() is affected. getHeader() must be also. getHeader, if there are 
multiple values, needs to return the same thing as the first value returned 
by getHeaders(), not the whole header from the first of multiple headers.

 
 

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

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 12:13 pm, Patrick Luby wrote:
> Remy,
>
> Remy Maucherat wrote:
> > No, this is not correct.
> >
> > You are allowed to do that only if the application knows it makes sense
> > to do so (ie, only when it call getHeaders).
> >
> > Some code to do that should be added in the adapter.
>
> This makes more sense than my original thoughts since the Watchdog
> failures are only happening in tests that invoke the getHeaders() method.
>

I suspect that the tests are not strong enough. There are other cases that 
aren't handled correctly, but aren't being tested for. Let's take the 'worst' 
case:

AcceptLanguage: en-us, ga-us;q=0.7
AcceptLanguage: x-redneck:q=0.01

getHeader("AcceptLanguage") ought to return "en-us", and three values ought to 
be returned through the enumerator getHeaders("AcceptLanguage"), {"en-us, 
"ga-us;q=0.7", "x-redneck:q=0.01"}.

This is sort of an oddball corner case, as any real client would likely send 
either one header or three. But it is an allowable case.




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

Re: Watchdog aggregation of headers may be incorrect

[Remy Maucherat]

Steve Downey wrote:
> On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> 
>>Patrick Luby wrote:
>>
>>>Steve,
>>>
>>>Your assessment is correct: an aggregate header like:
>>>
>>>  header1: val1, val2
>>>
>>>should be converted to this for the HttpRequest:
>>>
>>>  header1: val1
>>>  header1: val2
>>
>>No, this is not correct.
>>
>>You are allowed to do that only if the application knows it makes sense
>>to do so (ie, only when it call getHeaders).
>>
> 
> 
> If it is to be done, it should be done based on what the HTTP/1.1 spec 
> defines. The application needs to expect the possibility of multiple values 
> for all of the headers that allow them. Or just ask for the first one. 
> Parsing the header line into values probably shouldn't be left to the 
> application, although it is at the moment.

I gave you the HTTP/1.1 answer.

For Header H: A,B
If A,B
is semantically equivalent to:
H: A
H: B
then you can parse for the comma.

So since you can't know what the application considers to be 
semantically equivalent, the fact that it calls getHeaders is a big 
hint, and you can do the comma parsing.

Please read the HTTP specification.

>>Some code to do that should be added in the adapter.
>>
> 
> 
> Do you mean in the implementation of HttpServletRequest? I was thinking of 
> doing the work in MimeHeaders. Perhaps subclassing MimeHeaders into 
> Http11Headers, in order to allow other RFCHeaders? Certainly 
> Http11Protocol knows what kind of headers it's parsing. 

You can also do it in MimeHeaders.values if you want to.

Remy


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

Re: Watchdog aggregation of headers may be incorrect

[Steve Downey]

On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> Patrick Luby wrote:
> > Steve,
> >
> > Your assessment is correct: an aggregate header like:
> >
> >   header1: val1, val2
> >
> > should be converted to this for the HttpRequest:
> >
> >   header1: val1
> >   header1: val2
>
> No, this is not correct.
>
> You are allowed to do that only if the application knows it makes sense
> to do so (ie, only when it call getHeaders).
>

If it is to be done, it should be done based on what the HTTP/1.1 spec 
defines. The application needs to expect the possibility of multiple values 
for all of the headers that allow them. Or just ask for the first one. 
Parsing the header line into values probably shouldn't be left to the 
application, although it is at the moment.

> Some code to do that should be added in the adapter.
>

Do you mean in the implementation of HttpServletRequest? I was thinking of 
doing the work in MimeHeaders. Perhaps subclassing MimeHeaders into 
Http11Headers, in order to allow other RFCHeaders? Certainly 
Http11Protocol knows what kind of headers it's parsing. 

> > Tomcat 4 used to do this conversion correctly but then it stopped doing
> > the conversion a few months ago.
> >
> > This should be fixed as it is Servlet spec non-compliance. However, I am
> > not sure where the parsing of headers is now performed in Tomcat?
> >
> > Can anyone point Steve to where this header parsing of the ServerSocket
> > input stream is being done?
>
> No, this musn't be done there, as it would screw up many headers. Please
> read the chapter on multivalued headers in the HTTP/1.1 spec.
>

Right, at the lowest level, headers are being handled generically. Something 
needs to be aware of the semantics of HTTP/1.1 headers.

> Remy


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

Re: Watchdog aggregation of headers may be incorrect

[Remy Maucherat]

Patrick Luby wrote:
> Remy,
> 
> Remy Maucherat wrote:
> 
>>
>> No, this is not correct.
>>
>> You are allowed to do that only if the application knows it makes 
>> sense to do so (ie, only when it call getHeaders).
>>
>> Some code to do that should be added in the adapter.
> 
> 
> This makes more sense than my original thoughts since the Watchdog 
> failures are only happening in tests that invoke the getHeaders() method.
> 
>>
>> No, this musn't be done there, as it would screw up many headers. 
>> Please read the chapter on multivalued headers in the HTTP/1.1 spec.
>>
> 
> Which class do you suggest that this conversion be done? I agree that 
> putting where I suggested is not the right place.

You have to do it in the adapter, so that means CoyoteRequest. I'm not 
sure it can be made to be efficient on the GC side, but I guess it's ok, 
as it's not a method which is used too often.

Remy


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

Re: Watchdog aggregation of headers may be incorrect

[Patrick Luby]

Remy,

Remy Maucherat wrote:
> 
> No, this is not correct.
> 
> You are allowed to do that only if the application knows it makes sense 
> to do so (ie, only when it call getHeaders).
> 
> Some code to do that should be added in the adapter.

This makes more sense than my original thoughts since the Watchdog 
failures are only happening in tests that invoke the getHeaders() method.

> 
> No, this musn't be done there, as it would screw up many headers. Please 
> read the chapter on multivalued headers in the HTTP/1.1 spec.
> 

Which class do you suggest that this conversion be done? I agree that 
putting where I suggested is not the right place.

Thanks,

Patrick

-- 

Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900



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

Re: [5] [TODO] Config first task

[Remy Maucherat]

Costin Manolache wrote:
> Remy Maucherat wrote:
> 
> 
>>>And internals and 'priviledged' application will get access to the
>>>root of this tree, and look up anything configurable or runtime
>>>using the 'normal' API - with no tricks with classloader/thread binding.
>>
>>That's different from the ENC, since here, you can give the component a
>>reference to the right context.
> 
> 
> That's something I don't understand. 
> 
> Each app is supposed to get it's own DirContext, using the same name.
> And that's done by binding it per thread or class loader.
> 
> However this DirContext may also be binded in the 'big tree' - and
> internal code could access all those 'enc' contexts. 

I don't understand why you think it's the same.

For the ENC, you do something like:
(new InitialContext()).lookup("java:/comp/env/maxExemptions");

So you need the thread or CL binding to retrive the JNDI Context where 
maxExemptions is.

For the config, you can for example give StandardContext a reference to 
the DirContext which contains the webapp configuration data. So no 
thread binding needed.

Did I get it right ? (maybe not)

>>>I am thinking to propose use of commons-discovery and a
>>>META-INF/mbeans.xml in modeler - so a jar containing tomcat modules will
>>>include it's onw description, and an easy mechanism to find it.
>>
>>Ok, since you have ideas, feel free to experiment ;-)
> 
> 
> Sure. Just trying to get feedback and maybe get other people interested.
> So far only 2 people seem interested in 'common-discovery'.

I didn't look at it at all, sorry :-(

Remy


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

Re: [5] [TODO] Config first task

[Nicola Ken Barozzi]

Costin Manolache wrote:
...
> Sure. Just trying to get feedback and maybe get other people interested.
> So far only 2 people seem interested in 'common-discovery'.
> I want to use it for an antlib 'experiment', but it would also help
> for tomcat. Something like ant's ProjectHelper hook to plug in 
> different jndi config drivers ? 

OT: I am. I may use it to make Morphers available to apps. *And* if you 
tell me about your Antlib 'experiment', I'd be more than happy :-)
-> switching conversation to private or ant-dev

-- 
Nicola Ken Barozzi   [EMAIL PROTECTED]
 - verba volant, scripta manent -
(discussions get forgotten, just code remains)
-


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

Re: [5] [TODO] Config first task

[Costin Manolache]

Remy Maucherat wrote:

>> And internals and 'priviledged' application will get access to the
>> root of this tree, and look up anything configurable or runtime
>> using the 'normal' API - with no tricks with classloader/thread binding.
> 
> That's different from the ENC, since here, you can give the component a
> reference to the right context.

That's something I don't understand. 

Each app is supposed to get it's own DirContext, using the same name.
And that's done by binding it per thread or class loader.

However this DirContext may also be binded in the 'big tree' - and
internal code could access all those 'enc' contexts. 

>> I am thinking to propose use of commons-discovery and a
>> META-INF/mbeans.xml in modeler - so a jar containing tomcat modules will
>> include it's onw description, and an easy mechanism to find it.
> 
> Ok, since you have ideas, feel free to experiment ;-)

Sure. Just trying to get feedback and maybe get other people interested.
So far only 2 people seem interested in 'common-discovery'.
I want to use it for an antlib 'experiment', but it would also help
for tomcat. Something like ant's ProjectHelper hook to plug in 
different jndi config drivers ? 

Costin



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

Re: [5] [TODO] Config first task

[Remy Maucherat]

Costin Manolache wrote:
> Remy Maucherat wrote:
> 
> 
>>>The way I see it, we'll have 2 JNDI 'trees':
>>> - one for 'config data' ( the new one ).
>>> - one for 'runtime data' - including the VFS, various java:env, etc.
>>
>>Yes.
>>
>>I suppose you can take advantage of federation to make a giant big tree.
> 
> 
> And internals and 'priviledged' application will get access to the 
> root of this tree, and look up anything configurable or runtime
> using the 'normal' API - with no tricks with classloader/thread binding.

That's different from the ENC, since here, you can give the component a 
reference to the right context.

> One way or another, we need each internal object to be aware of its
> name - and it can cache the DirContexts it needs ( to avoid duplicating
> lookups, etc ).

Obvioulsy. Each component should keep local values also (you can't do a 
lookup on each variable access).

>>As I see it, we'll have the JNDI config which will be used by the
>>Catalina objects (like StandardContext) to store their config. The
>>question is do we make those objects the MBeans. I think we can use the
>>modeler to do that easily, instead of having the MBeans be another set
>>of separate objects.
> 
> 
> I don't think they need to be registered by default, but it is indeed very
> easy to turn them into MBeans via modeler. Probably the same listener 
> mechanism can be used ( jndi also has some events to notify of new objects
> and attribute changes - similar with the Lifecyecle and catalina-specific 
> events used to registrate the mbeans in the current code ).
> 
> We need to have each configurable object into the mbean.xml descriptor, 
> which may eventually turn with some magic into an ldap schema. 
> 
> I am thinking to propose use of commons-discovery and a META-INF/mbeans.xml
> in modeler - so a jar containing tomcat modules will include it's onw
> description, and an easy mechanism to find it.

Ok, since you have ideas, feel free to experiment ;-)

>>>We still need to 'bind' the initial context for each webapp so that
>>>webapps can see their separated envs. But internal code
>>>should have access to the root of the tree, for example stored in
>>>some top-level objects - and be able to access anything with a simple
>>>lookup.
>>
>>For the J2EE ENC, you have to do the binding:
>>- for security reasons, otherwise the webapp could find a way to access
>>another context
>>- because the lookup call is "static" (it's not, but it would be exactly
>>the same if it was), you have no way otherwise to do the lookup in the
>>right context
> 
> 
> I know ( for webapps ). I was talking about internal and 'priviledged' 
> apps, who don't need that. They should be able to access the 'root', 
> and shouldn't use the thread binding ( which sometimes is confusing 
> and even dangerous ) 

For the ENC, you still need to return the right context.
Or were you talking about the configuration context (in which case, it's 
probably not needed).

> BTW, another idea: what about trying to create a jndi context
> for web.xml ? Then same kind of code that manages server.xml will be able
> to manage web.xml for apps. 

Yes, we can also try to reuse it. One thing at a time, please ;-)

Remy


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

DO NOT REPLY [Bug 8611] - Sealed .jar files in WEB-INF/lib always fail to load second class

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

Sealed .jar files in WEB-INF/lib always fail to load second class

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Priority|Other   |High
 Resolution|FIXED   |
Version|4.0.3 Final |4.1.9



--- Additional Comments From [EMAIL PROTECTED]  2002-08-17 14:31 ---
on Tomcat 4.1.9 I have the same troubles

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

Re: [5] [TODO] Config first task

[Costin Manolache]

Remy Maucherat wrote:

>> The way I see it, we'll have 2 JNDI 'trees':
>>  - one for 'config data' ( the new one ).
>>  - one for 'runtime data' - including the VFS, various java:env, etc.
> 
> Yes.
> 
> I suppose you can take advantage of federation to make a giant big tree.

And internals and 'priviledged' application will get access to the 
root of this tree, and look up anything configurable or runtime
using the 'normal' API - with no tricks with classloader/thread binding.

One way or another, we need each internal object to be aware of its
name - and it can cache the DirContexts it needs ( to avoid duplicating
lookups, etc ).

 
> As I see it, we'll have the JNDI config which will be used by the
> Catalina objects (like StandardContext) to store their config. The
> question is do we make those objects the MBeans. I think we can use the
> modeler to do that easily, instead of having the MBeans be another set
> of separate objects.

I don't think they need to be registered by default, but it is indeed very
easy to turn them into MBeans via modeler. Probably the same listener 
mechanism can be used ( jndi also has some events to notify of new objects
and attribute changes - similar with the Lifecyecle and catalina-specific 
events used to registrate the mbeans in the current code ).

We need to have each configurable object into the mbean.xml descriptor, 
which may eventually turn with some magic into an ldap schema. 

I am thinking to propose use of commons-discovery and a META-INF/mbeans.xml
in modeler - so a jar containing tomcat modules will include it's onw
description, and an easy mechanism to find it.


>> We still need to 'bind' the initial context for each webapp so that
>> webapps can see their separated envs. But internal code
>> should have access to the root of the tree, for example stored in
>> some top-level objects - and be able to access anything with a simple
>> lookup.
> 
> For the J2EE ENC, you have to do the binding:
> - for security reasons, otherwise the webapp could find a way to access
> another context
> - because the lookup call is "static" (it's not, but it would be exactly
> the same if it was), you have no way otherwise to do the lookup in the
> right context

I know ( for webapps ). I was talking about internal and 'priviledged' 
apps, who don't need that. They should be able to access the 'root', 
and shouldn't use the thread binding ( which sometimes is confusing 
and even dangerous ) 

BTW, another idea: what about trying to create a jndi context
for web.xml ? Then same kind of code that manages server.xml will be able
to manage web.xml for apps. 
 
Costin



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

Re: Watchdog aggregation of headers may be incorrect

[Remy Maucherat]

Patrick Luby wrote:
> Steve,
> 
> Your assessment is correct: an aggregate header like:
> 
>   header1: val1, val2
> 
> should be converted to this for the HttpRequest:
> 
>   header1: val1
>   header1: val2

No, this is not correct.

You are allowed to do that only if the application knows it makes sense 
to do so (ie, only when it call getHeaders).

Some code to do that should be added in the adapter.

> Tomcat 4 used to do this conversion correctly but then it stopped doing 
> the conversion a few months ago.
> 
> This should be fixed as it is Servlet spec non-compliance. However, I am 
> not sure where the parsing of headers is now performed in Tomcat?
> 
> Can anyone point Steve to where this header parsing of the ServerSocket 
> input stream is being done?

No, this musn't be done there, as it would screw up many headers. Please 
read the chapter on multivalued headers in the HTTP/1.1 spec.

Remy


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

Re: [5] [TODO] Config first task

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> On second tought, it would be excelent if you can map server.xml. The 
> only issue I have is the naming hierarcy - but we can address that later.

Ok, I'll do it.

> One thing I hate in the current JNDI code is the binding on thread/class 
> loader, etc. I understand what it is supposed to do, but we shouldn't
> have to do that internally. 
> 
> The way I see it, we'll have 2 JNDI 'trees':
>  - one for 'config data' ( the new one ).
>  - one for 'runtime data' - including the VFS, various java:env, etc.

Yes.

I suppose you can take advantage of federation to make a giant big tree.

As I see it, we'll have the JNDI config which will be used by the 
Catalina objects (like StandardContext) to store their config. The 
question is do we make those objects the MBeans. I think we can use the 
modeler to do that easily, instead of having the MBeans be another set 
of separate objects.

> We still need to 'bind' the initial context for each webapp so that
> webapps can see their separated envs. But internal code
> should have access to the root of the tree, for example stored in 
> some top-level objects - and be able to access anything with a simple
> lookup. 

For the J2EE ENC, you have to do the binding:
- for security reasons, otherwise the webapp could find a way to access 
another context
- because the lookup call is "static" (it's not, but it would be exactly 
the same if it was), you have no way otherwise to do the lookup in the 
right context

> If we are going to go with the JNDI-based config, than I think it may 
> be worth to first clean up and add some more docs to the jndi code
> we have. I know you knows the code very well - but for those with 
> less JNDI experience it would help a lot. The binding seems the 
> trickiest part, and I can't understand why it is actually needed from
> inside.

Ok.

Remy


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

Re: DBCP multiple pools for multiple contexts under 4.0.4?

[Asar . Khan]

Only it doesn't work in 4.1.x!!

See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11662


On 17/08/2002 03:20:17 Glenn Nielsen wrote:
> No, I don't.
>
> The Host DefaultContext only defines the default context configuration.
> Any resources defined are instantiated for each individual context.
>
> GlobalNamingResource does indeed instantiate a resource which can
> be shared.
>
> So no, you can't do what you want to do with Tomcat 4.0.x.
>
> You would have to upgrade to 4.1.x.
>
> Regards,
>
> Glenn
>
> Isaac Arias wrote:
> > Hi All,
> >
> > A couple of weeks ago I wrote about a Poolman
> > DataSource factory for Tomcat, but the latest version
> > of Poolman ended up being too buggy for production
> > work. We've since moved to DBCP from Commons.
> >
> > I'm trying to configure a global DB pool for multiple
> > contexts and I'm having trouble using the
> > BasicDataSourceFactory with Tomcat 4.0.4.
> >
> > Since Tomcat 4.0.x doesn't support the
> >  structure (like 4.1.x) which
> > sounds like the right thing to use, I'm placing the
> > DBCP  in a . However, it
> > appears that every time a context tries to access the
> > pool, DBCP creates a brand new pool for that context
> > instead of sharing a global one.
> >
> > Any ideas on how to configure this on 4.0.4? I guess
> > one option would be to modify the
> > BasicDataSourceFactory, but maybe there's a way to do
> > it in the config files in 4.0.4. Is anybody using DBCP
> > as a global pooler for multiple contexts?
> >
> > Thanks a lot!
> >
> > Ike
> > _
> > Isaac Arias
> > Tokenzone, Inc.
> >
> > __
> > Do You Yahoo!?
> > HotJobs - Search Thousands of New Jobs
> > http://www.hotjobs.com
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
>
>
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>



- ---
Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

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

Re: mod_jk2.so needed

[Bill Barker]

I'm hoping that you don't really want mod_jk2.so for W2K ;-).

The Jk2 binaries for Windows are at:

http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/nightly/win32
/

However, I believe that these are built against 2.0.38.  If you have MSVC
installed, it shouldn't be too much of a problem to build from source
against 2.0.40.


- Original Message -
From: "Niket Anand" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 17, 2002 1:50 AM
Subject: mod_jk2.so needed


> Hi all,
> Can anybody send me a link from where I can download mod_jk2.so? I am
unable
> to
> build this file.
> I am using Apache2.0.4, Tomcat4.0.3 in windows2000
> Or please send it with attachment.
>
> I am following the instructions given in this link to run apache with
Tomcat
> http://www.pubbitch.org/jboss/mod_jk2.html
> but unable to build .so file
>
> I am getting following compilation error
> 
> apache20:
>[so] Compiling 19 out of 19
> Compiling
> F:\jakarta-tomcat-connectors-4.0.4-src\jk\native\apache-2.0\mod_jk.c
>
> BUILD FAILED
>
> F:\jakarta-tomcat-connectors-4.0.4-src\jk\native\build.xml:134:
> java.io.IOExcept
> ion: CreateProcess: libtool --mode=compile cc -c -o
> F:\jakarta-tomcat-connectors
> -4.0.4-src\jk\build\jk\apache2\apache-2.0\mod_jk.o -IF:\jakarta-tomcat-con
ne
> ctor
> s-4.0.4-src\jk\native/common "-IF:\Program Files\Apache
> Group\Apache2\include" -
>
IF:\jdk1.3.1\jre/../include -g -W -D_REENTRANT -DCHUNK_SIZE=4096 -DREUSE_WOR
> KER
> -DUSE_APACHE_MD5
> F:\jakarta-tomcat-connectors-4.0.4-src\jk\native\apache-2.0\mod
> _jk.c error=2
>
###
> Thanks in advance
> Niket
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


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

mod_jk2.so needed

[Niket Anand]

Hi all,
Can anybody send me a link from where I can download mod_jk2.so? I am unable
to
build this file.
I am using Apache2.0.4, Tomcat4.0.3 in windows2000
Or please send it with attachment.

I am following the instructions given in this link to run apache with Tomcat
http://www.pubbitch.org/jboss/mod_jk2.html
but unable to build .so file

I am getting following compilation error

apache20:
   [so] Compiling 19 out of 19
Compiling
F:\jakarta-tomcat-connectors-4.0.4-src\jk\native\apache-2.0\mod_jk.c

BUILD FAILED

F:\jakarta-tomcat-connectors-4.0.4-src\jk\native\build.xml:134:
java.io.IOExcept
ion: CreateProcess: libtool --mode=compile cc -c -o
F:\jakarta-tomcat-connectors
-4.0.4-src\jk\build\jk\apache2\apache-2.0\mod_jk.o -IF:\jakarta-tomcat-conne
ctor
s-4.0.4-src\jk\native/common "-IF:\Program Files\Apache
Group\Apache2\include" -
IF:\jdk1.3.1\jre/../include -g -W -D_REENTRANT -DCHUNK_SIZE=4096 -DREUSE_WOR
KER
-DUSE_APACHE_MD5
F:\jakarta-tomcat-connectors-4.0.4-src\jk\native\apache-2.0\mod
_jk.c error=2
###
Thanks in advance
Niket




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

test

[Niket Anand]

niket


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