DO NOT REPLY [Bug 10126] - NullPointerException when no uri defined in taglib directive

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

NullPointerException when no uri defined in taglib directive

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 23:48 ---
Fixed.

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

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

[luehe]

luehe   2002/07/08 16:47:55

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  Fixed Bug# 10126: NullPointerException when no uri defined in taglib directive
  
  Revision  ChangesPath
  1.7   +5 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Parser.java   20 Jun 2002 20:12:26 -  1.6
  +++ Parser.java   8 Jul 2002 23:47:55 -   1.7
  @@ -348,11 +348,11 @@
Attributes attrs = parseAttributes();
String uri = attrs.getValue("uri");
String prefix = attrs.getValue("prefix");
  - if (uri != null || prefix != null) {
  + if (uri != null && prefix != null) {
// Errors to be checked in Validator
String[] location = ctxt.getTldLocation(uri);
TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, prefix, uri,
  -location, err);
  +location, err);
taglibs.put(prefix, tl);
}
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/conf tomcat-jk2.manifest

[costin]

costin  2002/07/08 16:37:47

  Modified:jk/conf  tomcat-jk2.manifest
  Log:
  Add coyote to the manifest.
  
  Revision  ChangesPath
  1.2   +1 -1  jakarta-tomcat-connectors/jk/conf/tomcat-jk2.manifest
  
  Index: tomcat-jk2.manifest
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/tomcat-jk2.manifest,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- tomcat-jk2.manifest   2 Jul 2002 19:45:50 -   1.1
  +++ tomcat-jk2.manifest   8 Jul 2002 23:37:47 -   1.2
  @@ -1,2 +1,2 @@
   Main-Class: org.apache.jk.server.JkMain
  -Class-Path: tomcat-util.jar workers.jar ../classes/ commons-logging.jar log4j.jar
  +Class-Path: tomcat-util.jar workers.jar ../classes/ commons-logging.jar log4j.jar 
tomcat-coyote.jar
  
  
  

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

DO NOT REPLY [Bug 9935] - Odd port 32769 left in BOUND state

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

Odd port 32769 left in BOUND state





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 23:31 ---
Oddly enough, on Solaris I was able to reproduce the problem when a more than a socket
gets bound... Like

ServerSocket s1=new ServerSocket(1233);
ServerSocket s2=new ServerSocket(1234);

It appears to be a bug in the VM, but I'm not quite confident on that... It still 
looks odd (it 
happens once every N time, while with tomcat it happens ALL the times).

As I posted on Tomcat-DEV, trussing the VM, it shows that actually the sucker does 
create
the two sockets, and does make the odd connections, plus, leaves one of the sockets in
"bound" state...

But ATM not much time to debug the VM...

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

Last (?) Gump failure

[Remy Maucherat]

It seems there's a last problem with Gump and the definition of the MX4J 
project, or something like it.
The JARs names are mx4j-jmx.jar and mx4j-tools.jar now, AFAIK.

Everything else looks good now (and we should finally have a Gump 
generated nightly) :)

Remy


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

DO NOT REPLY [Bug 9935] - Odd port 32769 left in BOUND state

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

Odd port 32769 left in BOUND state





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 21:51 ---

FYI, weird port connections present on both Solaris and Linux.  Looked into
it a bit more (by adding debugging println's to java.net.Socket and
java.net.ServerSocket) and didnt find anything in the VM that is creating
the sockets.  Weird.

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

DO NOT REPLY [Bug 10568] New: - org.apache.jasper.servlet.JspServlet: bug creating output directory URL

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

org.apache.jasper.servlet.JspServlet: bug creating output directory URL

   Summary: org.apache.jasper.servlet.JspServlet: bug creating
output directory URL
   Product: Tomcat 4
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This bug is in org.apache.jasper.servlet.JspServlet revision 1.28 from CVS
(current as of July 8, 2002).  It's also in tomcat 4.0.3, which is what I'm running.

The loadJSP() method has the following code:

 URL [] urls = new URL[1];
 File outputDir = new File(normalize(ctxt.getOutputDir()));
 urls[0] = outputDir.toURL();
 jsw.loader = new JasperLoader(urls,ctxt.getServletClassName(),
  parentClassLoader,
  permissionCollection,
  codeSource);

The problem is with the outputDir object, which is a java.io.File.  This object
does not know that it represents a directory, and if you convert it to a string,
it will not have a trailing separator character.  When a URL is created from
this file, it will not have a trailing separator character in its external form.

If you look at the documentation for URLClassLoader (which JasperLoader is a
subclass of), it says that 

"Any URL that ends with a '/' is assumed to refer to a directory.  Otherwise,
the URL is assumed to refer to a JAR file which will be downloaded and opened as
needed."

(This is a direct quote from the Sun JDK 1.4 API documentation.)

So, when outputDir is converted to a URL, it is reasonable to assume that it
will be treated as a jar file rather than a filesystem directory, which is
obviously not what is intended.

I assume that this bug has not manifested before because the Sun JDKs do not
appear to implement the behavior that is described in the API documentation;
presumably, if the base URL does not appear to be a jar file, the Sun
implementation will try to treat it as a directory.  However, from what I can
tell from reading the API documentation, this extra behavior is not required.

In case you're wondering why I'm reporting this as a bug, I'm using a virtual
machine which does not use the Sun libraries.  The JasperLoader fails to load a
compiled JSP because it thinks the directory it's in is a jar file.

To fix this problem, I think the use of the File object should be eliminated. 
It would be sufficient to create the URL as follows:

  urls[0] = new URL("file:" + normalize(ctxt.getOutputDir()));

This will preserve the trailing slash in the output directory path.

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

DO NOT REPLY [Bug 10565] - shutdown hook problem: java.lang.NoClassDefFoundError: java/util/Iterator

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

shutdown hook problem:  java.lang.NoClassDefFoundError: java/util/Iterator

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 21:25 ---
Using a shutdown hook is not supported in a container environment. Please use
the container lifecycle events instead.

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

DO NOT REPLY [Bug 10565] New: - shutdown hook problem: java.lang.NoClassDefFoundError: java/util/Iterator

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

shutdown hook problem:  java.lang.NoClassDefFoundError: java/util/Iterator

   Summary: shutdown hook problem:  java.lang.NoClassDefFoundError:
java/util/Iterator
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a class that sets up a shutdown hook to close resources when the JVM is 
shutting down.  It works fine when I run the class outside of Tomcat.  But when 
it runs from within Tomcat, I get a "java.lang.NoClassDefFoundError: 
java/util/Iterator" from the shutdown hook thread.  Javadoc for this error 
states "... The searched-for class definition existed when the currently 
executing class was compiled, but the definition can no longer be found."  I 
have no idea why the java.util package would be unavailable.

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

[ANNOUNCEMENT] Tomcat 4.1.7 Beta

[Remy Maucherat]

Tomcat 4.1.7 Beta has been released. It includes major bugfixes and 
improvements over the previous Tomcat 4.1.3 Beta (please refer to the 
release notes for the complete list).

Relese notes:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.7-beta/RELEASE-NOTES

Downloads (source and binaries):
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.7-beta/

Remy


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

j_security_check question: RequestDispatcher .forward!!

[Kevin Andryc]

 I apologize for mailing this to the development list, but I have
scoured the web and e-mailed the user list numerous times with no answers. I
don't know if this is a bug, or how to resolve this issue. Please read my
question below:

So I found that I can access my servlet if I don't use the
RequestDispatcher .forward method. In other words, when I try and access my
page (e.g.: http://localhost:8080/dev/servlet/ProtectedPage) I get a login
JSP form that I specified. When I login successfully,the login page
reappears when, in my ProtectedPage servlet, I use the RequestDispatcher
.forward method instead of using a PrintWriter to send back the response.
Why can I not use the RequestDispatcher, if I can, how???

I am using Tomcat 4.0.4 on Windows connecting to an Oracle 8i database for
usernames, passwords and roles.

Below is some code.

Web.xml

  Example Security Constraint
  
 Protected Area
 
 /servlet/*
 /jsp/security/*
 
 DELETE
 GET
 POST
 PUT
  
  
 
 user
 tomcat
  


   

  FORM
  Example Form-Based Authentication Area
  
/jsp/security/login.jsp
/jsp/security/error.jsp
  


ProtectedPage.java
public class ProtectedPage extends HttpServlet  {

// Default constructor
public ProtectedPage() {
super();
}

public void doGet(HttpServletRequest request, HttpServletResponse response)
{
performTask(request, response);
}

public void doPost(HttpServletRequest request, HttpServletResponse
response) {
performTask(request, response);
}

public void performTask(HttpServletRequest request, HttpServletResponse
response) {

try {
String jspPage = "index.jsp";
RequestDispatcher rd =
getServletContext().getRequestDispatcher("/jsp/security/" + jspPage);
rd.forward(request, response);
}
catch(Exception e) {
e.printStackTrace();
}
}
}

index.jsp


Protected Page for Examples



You are logged in as remote user <%= request.getRemoteUser() %>
in session <%= session.getId() %>

<%
  if (request.getUserPrincipal() != null) {
%>
Your user principal name is
<%= request.getUserPrincipal().getName() %>
<%
  } else {
%>
No user principal could be identified.
<%
  }
%>

<%
  String role = request.getParameter("role");
  if (role == null)
role = "";
  if (role.length() > 0) {
if (request.isUserInRole(role)) {
%>
  You have been granted role <%= role %>
<%
} else {
%>
  You have not been granted role <%= role %>
<%
}
  }
%>




Kevin Andryc
Web Systems Engineer
MISER
http://www.umass.edu/miser/
Phone: (413)-545-3460
[EMAIL PROTECTED]





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

Re: [PROPOSAL] Single signon and loadbalancer

[Denis Benoit]

Sure, the idea is to apply the same logic for the "Single Signon" than
for regular session.  Currently, a distinct cookie (or parameter) is
created for this.  The discussion is wether it should reuse in some
way the "regular session" cookie (or parameter) or continue to use
the distinct cookie (or parameter).

The problem I see with using the "JSESSIONID" cookie (or parameter) for
the "single signon" is that there would be a clash between the SSO
identifier and the identifier for the "ROOT" webapp.  If you look at it
from the "cookie side".  Both cookie would have the "JSESSIONID" name
and apply to the "/" path.  So if somebody hits a webapp accessible from
the "/foo" URL, we would need to create two cookies (if the SingleSignon
valve is activated of course).  We would need to create a "JSESSIONID"
cookie for the "/foo" URL and a "JSESSIONID" for "/" URL for the single
signon purpose.  Now, after that, if the user hits the "ROOT" webapp,
Tomcat would look for a session whose ID was the "JSESSIONID" given
for the "single signgon" and it would not find the session, or worse,
find another session.  At that point, all hell break loose...

On Mon, 8 Jul 2002, Tim Funk wrote:

> Would this new solution be compatible with URL rewriting? (No cookies 
> being used)
> 
> [EMAIL PROTECTED] wrote:
> > On Mon, 8 Jul 2002, Denis Benoit wrote:
> > 
> > 
> >>I think it would be difficult, since JSESSIONID is distinct for each
> >>webapp on a Tomcat, only JSESSIONIDSSO (if the SingleSignon valve
> >>is activated) is common to all webapps.
> >>
> >>I'll try to think of something, but if you think of something first,
> >>let me know :)
> > 
> > 
> > Well, my thinking is that in order to have 'single signon' you need 
> > a way to have a single cookie ( or path param if cookies are disabled )
> > across all webapps. Whatever mean to get that as JSESSIONIDSSO, 
> > it can be used for JSESSIONID as well.
> > 
> > So I would add a hook into the session id generator - and have
> > the single signon use the hook to push session ids.
> > 
> > If we want to have distinct sessions in each webapp - the session
> > id would consist of the 'common' part and a per-webapp part.
> > 
> > In general, my view of single signon is that each app must 
> > redirect to an auth application ( similar with kerberos for example)
> > and use the certificate as session id for all webapps.
> > 
> > Costin

-- 
Denis Benoit



**
Financiere Banque Nationale et NBCN n'assument
aucune responsabilite quant a la confidentialite et l'integrite du
present courriel en raison des risques d'interception inherents 
a l'Internet. Pour cette raison, toute opinion exprimee au terme 
des presentes ne reflete pas necessairement celle de 
Financiere Banque Nationale et de NBCN.
**
Due to the security risks involved in sending information over the
Internet, National Bank Financial  and NBCN cannot be held responsible 
for ensuring the confidentiality and integrity of the present e-mail. For this 
reason, the opinions expressed herein do not necessarily reflect those of 
National Bank Financial and NBCN.
**


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

DO NOT REPLY [Bug 10539] - Active lock discovery returns invalid lock tokens ("dummytoken")

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

Active lock discovery returns invalid lock tokens ("dummytoken")

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 19:39 ---
The lock token is only returned when setting the token. It is legal to obsfucate
the token for security reasons. The client should hang on to the token it got
when locking.

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

Re: [PROPOSAL] Single signon and loadbalancer

[Tim Funk]

Would this new solution be compatible with URL rewriting? (No cookies 
being used)

[EMAIL PROTECTED] wrote:
> On Mon, 8 Jul 2002, Denis Benoit wrote:
> 
> 
>>I think it would be difficult, since JSESSIONID is distinct for each
>>webapp on a Tomcat, only JSESSIONIDSSO (if the SingleSignon valve
>>is activated) is common to all webapps.
>>
>>I'll try to think of something, but if you think of something first,
>>let me know :)
> 
> 
> Well, my thinking is that in order to have 'single signon' you need 
> a way to have a single cookie ( or path param if cookies are disabled )
> across all webapps. Whatever mean to get that as JSESSIONIDSSO, 
> it can be used for JSESSIONID as well.
> 
> So I would add a hook into the session id generator - and have
> the single signon use the hook to push session ids.
> 
> If we want to have distinct sessions in each webapp - the session
> id would consist of the 'common' part and a per-webapp part.
> 
> In general, my view of single signon is that each app must 
> redirect to an auth application ( similar with kerberos for example)
> and use the certificate as session id for all webapps.
> 
> Costin
> 
> 
> 
>>On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:
>>
>>
>>>+1
>>>
>>>But before doing that - would it be possible to replace JSESSIONIDSSO 
>>>with a mechanism relying only on JSESSIONID ? 
>>>
>>>Even if we patch mod_jk, there are other load balancing solutions
>>>( hardware, etc ) - it would be much simpler if from 'outside'
>>>we would only use the standard JSESSIONID cookie / path param.
>>>
>>>Costin
>>>
>>>On Thu, 4 Jul 2002, Denis Benoit wrote:
>>>
>>>
Hi,

With the current code (TC 4.1.6), the single signon does not work with the
loadbalancer connector.

If a user was logged in a given webapp, the loadbalancer looks at the
JSESSIONID cookie (or URL parameter) to dispatch the request properly to the
tomcat where the user was logged on.  But if the user hits another webapp,
the JSESSIONID is not present anymore and the dispatcher applies its
round-robin logic to dispatch the request to any tomcat.  It nullifies the
effect of the single signon.  There is two problem that prevent it to work.

1. On the Tomcat side, the generateSessionId() method of
   org.apache.catalina.authenticator.AuthenticatorBase does not append
   the jvmRoute of the Engine if one is specified.  So when a user changes
   webapp, the web connector dispatcher does not have any information to
   properly route the request;

2. The current loadbalancer code specifically look for the JSESSIONID cookie
   and does not look for a JSESSIONIDSSO cookie.

I could provide a patch to org.apache.catalina.authenticator.AuthenticatorBase
to add the jvmRoute to the session id; in fact it is a copy of the code from
org.apache.catalina.session.ManagerBase.

The change in:

./jk/native/common/jk_lb_worker.c
./jk/native2/common/jk_requtil.c

is also trivial, first the connector must look for the JSESSIONID cookie (or
param), and if not found it should look for the JSESSIONIDSSO cookie (or
param).  Then the same logic should be applied if either one is found.

Comments?




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

Re: [PROPOSAL] Single signon and loadbalancer

[costinm]

On Mon, 8 Jul 2002, Denis Benoit wrote:

> I think it would be difficult, since JSESSIONID is distinct for each
> webapp on a Tomcat, only JSESSIONIDSSO (if the SingleSignon valve
> is activated) is common to all webapps.
> 
> I'll try to think of something, but if you think of something first,
> let me know :)

Well, my thinking is that in order to have 'single signon' you need 
a way to have a single cookie ( or path param if cookies are disabled )
across all webapps. Whatever mean to get that as JSESSIONIDSSO, 
it can be used for JSESSIONID as well.

So I would add a hook into the session id generator - and have
the single signon use the hook to push session ids.

If we want to have distinct sessions in each webapp - the session
id would consist of the 'common' part and a per-webapp part.

In general, my view of single signon is that each app must 
redirect to an auth application ( similar with kerberos for example)
and use the certificate as session id for all webapps.

Costin


> 
> On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:
> 
> > +1
> > 
> > But before doing that - would it be possible to replace JSESSIONIDSSO 
> > with a mechanism relying only on JSESSIONID ? 
> > 
> > Even if we patch mod_jk, there are other load balancing solutions
> > ( hardware, etc ) - it would be much simpler if from 'outside'
> > we would only use the standard JSESSIONID cookie / path param.
> > 
> > Costin
> > 
> > On Thu, 4 Jul 2002, Denis Benoit wrote:
> > 
> > > Hi,
> > > 
> > > With the current code (TC 4.1.6), the single signon does not work with the
> > > loadbalancer connector.
> > > 
> > > If a user was logged in a given webapp, the loadbalancer looks at the
> > > JSESSIONID cookie (or URL parameter) to dispatch the request properly to the
> > > tomcat where the user was logged on.  But if the user hits another webapp,
> > > the JSESSIONID is not present anymore and the dispatcher applies its
> > > round-robin logic to dispatch the request to any tomcat.  It nullifies the
> > > effect of the single signon.  There is two problem that prevent it to work.
> > > 
> > > 1. On the Tomcat side, the generateSessionId() method of
> > >org.apache.catalina.authenticator.AuthenticatorBase does not append
> > >the jvmRoute of the Engine if one is specified.  So when a user changes
> > >webapp, the web connector dispatcher does not have any information to
> > >properly route the request;
> > > 
> > > 2. The current loadbalancer code specifically look for the JSESSIONID cookie
> > >and does not look for a JSESSIONIDSSO cookie.
> > > 
> > > I could provide a patch to org.apache.catalina.authenticator.AuthenticatorBase
> > > to add the jvmRoute to the session id; in fact it is a copy of the code from
> > > org.apache.catalina.session.ManagerBase.
> > > 
> > > The change in:
> > > 
> > >   ./jk/native/common/jk_lb_worker.c
> > >   ./jk/native2/common/jk_requtil.c
> > > 
> > > is also trivial, first the connector must look for the JSESSIONID cookie (or
> > > param), and if not found it should look for the JSESSIONIDSSO cookie (or
> > > param).  Then the same logic should be applied if either one is found.
> > > 
> > > Comments?
> > > 
> > > 
> > 
> 
> 


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

RE: mod_jk2 jvm thread issues

[Mladen Turk]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: 8. srpanj 2002 19:40
> To: Tomcat Developers List
> Subject: Re: mod_jk2 jvm thread issues
> 
> > 
> > IMO we are needing something like a TLS to fix that, or make the 
> > behavior similar to the apache's request rec, creating a 
> pool for each 
> > request. Does anyone has some other ideas about that.
> 
> +1 on TLS, I think that would also give a bit of extra performance.
> 
> Note that you can't attach in one thread and use it in 
> another - so either attach/detach before/after requests or 
> use a TLS plus 
> a cleanup mechanism, the pool won't work.
> 

The thread pool and its manager will solve that for the iis on the c
side, and the request rec cleanup on the apache. But I still need some
sort of mechanism that will allow to shutdown and cleanup and
dereference everything, (for sure) on the Java side. Running TC shutdown
leaves the jvm attached to the process with the redirected stdout/stderr
locked.
Any idea how to track that down?

MT.



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

DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs

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

Content-length header should be automatically set for buffered Servlets/JSPs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 18:48 ---
As I said, this won't be fixed in the old HTTP connector.

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

Re: [VOTE] Apache Tomcat 5.0 Proposal

[Kin-Man Chung]

+1.

I'll populate jasper2 and servlet-api with initial changes for JSP2.0
support.


> Date: Tue, 02 Jul 2002 16:57:20 -0700
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Subject: [VOTE] Apache Tomcat 5.0 Proposal
> To: Tomcat Developers List <[EMAIL PROTECTED]>
>
> After trying to address the concerns raised by the proposal draft, I 
> would like to call for a vote on it, now that the discussions have died 
> down.
> 
> 
> [ ] +1 I support the proposal, and will help implement it
> [ ] +0 I support the proposal
> [ ] -0 I do not support the proposal
> [ ] -1 I am against the proposal being implemented, because:
> 
> 
> 
> 
> The vote will run for one full week until July 9th. Users and other 
> contributors may vote, but only committers have binding votes.
> 
> Remy


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

DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs

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

Content-length header should be automatically set for buffered Servlets/JSPs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 18:40 ---
Please read the following comments - if you choose to set the bug
back to "resolved wontfix" I won't continue to reopen, but please
do consider the following first: (thanks)

1) The spec is not specifying how the transport layer behaves.
The spec is saying that asking a buffer to be used (even if used
by default as with JSP's) also includes
asking the container to set the content length for the servlet/jsp.
In other words, you can think if it in a similar manner to the actual
servlet saying "please call setContentLength()" for me.

2) HTTP 1.1 clearly does strongly encourage the use of the
Content-length header (or chunked transfer encoding instead)
whenever possible -- see sections 4.4, 10.4.12, and 14.14 in RFC 2616.

3) I don't see why you would need to change connectors to support this.
Normally, if a servlet programatically sets the content length,
the AJP connector passes this header along fine.
If the servlet sets a buffer size, this is in fact asking the servlet
container to set the content length for it -- at this point nothing
has yet been passed to the connector, so there is no reason for the
connector to know the difference between the two situations.
(let me know if I'm not explaining this clearly).

4) Recent versions of Commercial servlet containers (e.g. BEA Weblogic)
DO take care
of the content length in the buffered situation, as the spec says.
While this doesn't prove that what the spec says is the right thing to do,
I think it makes a great deal of sense.
I do hope you might re-consider adding this feature to Tomcat.

At any rate, thanks for all the great work you guys do!

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

DO NOT REPLY [Bug 10563] New: - Multiple compiles for multiple requests

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

Multiple compiles for multiple requests

   Summary: Multiple compiles for multiple requests
   Product: Tomcat 4
   Version: 4.1.6
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If multiple requests are presented for the same JSP at the same time, then
multiple instances of org.apache.jasper.compiler.JspCompiler are created and
multiple javac compilations are started at the same time.

While this eventually gives the correct results, it can make start up of a
JSP site very slow in the presences of live traffic (and the user is JspC
resistant for some unknown reason?)

I have tested a simple fix of synchronizing on a static in
org.apache.jasper.compiler.Compiler.compile:

if (!isOutDated())
return false;
synchronized(Compiler.class)
{
if (!isOutDated())
return false;


and it appears to work OK - but may not be optimal?

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

Re: [PROPOSAL] Single signon and loadbalancer

[Denis Benoit]

I think it would be difficult, since JSESSIONID is distinct for each
webapp on a Tomcat, only JSESSIONIDSSO (if the SingleSignon valve
is activated) is common to all webapps.

I'll try to think of something, but if you think of something first,
let me know :)

On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:

> +1
> 
> But before doing that - would it be possible to replace JSESSIONIDSSO 
> with a mechanism relying only on JSESSIONID ? 
> 
> Even if we patch mod_jk, there are other load balancing solutions
> ( hardware, etc ) - it would be much simpler if from 'outside'
> we would only use the standard JSESSIONID cookie / path param.
> 
> Costin
> 
> On Thu, 4 Jul 2002, Denis Benoit wrote:
> 
> > Hi,
> > 
> > With the current code (TC 4.1.6), the single signon does not work with the
> > loadbalancer connector.
> > 
> > If a user was logged in a given webapp, the loadbalancer looks at the
> > JSESSIONID cookie (or URL parameter) to dispatch the request properly to the
> > tomcat where the user was logged on.  But if the user hits another webapp,
> > the JSESSIONID is not present anymore and the dispatcher applies its
> > round-robin logic to dispatch the request to any tomcat.  It nullifies the
> > effect of the single signon.  There is two problem that prevent it to work.
> > 
> > 1. On the Tomcat side, the generateSessionId() method of
> >org.apache.catalina.authenticator.AuthenticatorBase does not append
> >the jvmRoute of the Engine if one is specified.  So when a user changes
> >webapp, the web connector dispatcher does not have any information to
> >properly route the request;
> > 
> > 2. The current loadbalancer code specifically look for the JSESSIONID cookie
> >and does not look for a JSESSIONIDSSO cookie.
> > 
> > I could provide a patch to org.apache.catalina.authenticator.AuthenticatorBase
> > to add the jvmRoute to the session id; in fact it is a copy of the code from
> > org.apache.catalina.session.ManagerBase.
> > 
> > The change in:
> > 
> > ./jk/native/common/jk_lb_worker.c
> > ./jk/native2/common/jk_requtil.c
> > 
> > is also trivial, first the connector must look for the JSESSIONID cookie (or
> > param), and if not found it should look for the JSESSIONIDSSO cookie (or
> > param).  Then the same logic should be applied if either one is found.
> > 
> > Comments?
> > 
> > 
> 

-- 
Denis Benoit



**
Financiere Banque Nationale et NBCN n'assument
aucune responsabilite quant a la confidentialite et l'integrite du
present courriel en raison des risques d'interception inherents 
a l'Internet. Pour cette raison, toute opinion exprimee au terme 
des presentes ne reflete pas necessairement celle de 
Financiere Banque Nationale et de NBCN.
**
Due to the security risks involved in sending information over the
Internet, National Bank Financial  and NBCN cannot be held responsible 
for ensuring the confidentiality and integrity of the present e-mail. For this 
reason, the opinions expressed herein do not necessarily reflect those of 
National Bank Financial and NBCN.
**


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

Re: [PROPOSAL] Single signon and loadbalancer

[Craig R. McClanahan]

On Mon, 8 Jul 2002 [EMAIL PROTECTED] wrote:

> Date: Mon, 8 Jul 2002 10:43:26 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Single signon and loadbalancer
>
> +1
>
> But before doing that - would it be possible to replace JSESSIONIDSSO
> with a mechanism relying only on JSESSIONID ?
>

When designing the way SSO worked in the first place, I couldn't think of
a solution with just JSESSIONID that supported single sign on when you
weren't using sessions in one or more of the applications.  It seems to me
that this is an important functional requirement, and is at least
implicitly required by the spec (Servlet 2.3, section 12.6).

> Even if we patch mod_jk, there are other load balancing solutions
> ( hardware, etc ) - it would be much simpler if from 'outside'
> we would only use the standard JSESSIONID cookie / path param.
>
> Costin
>

Craig


> On Thu, 4 Jul 2002, Denis Benoit wrote:
>
> > Hi,
> >
> > With the current code (TC 4.1.6), the single signon does not work with the
> > loadbalancer connector.
> >
> > If a user was logged in a given webapp, the loadbalancer looks at the
> > JSESSIONID cookie (or URL parameter) to dispatch the request properly to the
> > tomcat where the user was logged on.  But if the user hits another webapp,
> > the JSESSIONID is not present anymore and the dispatcher applies its
> > round-robin logic to dispatch the request to any tomcat.  It nullifies the
> > effect of the single signon.  There is two problem that prevent it to work.
> >
> > 1. On the Tomcat side, the generateSessionId() method of
> >org.apache.catalina.authenticator.AuthenticatorBase does not append
> >the jvmRoute of the Engine if one is specified.  So when a user changes
> >webapp, the web connector dispatcher does not have any information to
> >properly route the request;
> >
> > 2. The current loadbalancer code specifically look for the JSESSIONID cookie
> >and does not look for a JSESSIONIDSSO cookie.
> >
> > I could provide a patch to org.apache.catalina.authenticator.AuthenticatorBase
> > to add the jvmRoute to the session id; in fact it is a copy of the code from
> > org.apache.catalina.session.ManagerBase.
> >
> > The change in:
> >
> > ./jk/native/common/jk_lb_worker.c
> > ./jk/native2/common/jk_requtil.c
> >
> > is also trivial, first the connector must look for the JSESSIONID cookie (or
> > param), and if not found it should look for the JSESSIONIDSSO cookie (or
> > param).  Then the same logic should be applied if either one is found.
> >
> > Comments?
> >
> >
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


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

Re: [PROPOSAL] Single signon and loadbalancer

[costinm]

+1

But before doing that - would it be possible to replace JSESSIONIDSSO 
with a mechanism relying only on JSESSIONID ? 

Even if we patch mod_jk, there are other load balancing solutions
( hardware, etc ) - it would be much simpler if from 'outside'
we would only use the standard JSESSIONID cookie / path param.

Costin

On Thu, 4 Jul 2002, Denis Benoit wrote:

> Hi,
> 
> With the current code (TC 4.1.6), the single signon does not work with the
> loadbalancer connector.
> 
> If a user was logged in a given webapp, the loadbalancer looks at the
> JSESSIONID cookie (or URL parameter) to dispatch the request properly to the
> tomcat where the user was logged on.  But if the user hits another webapp,
> the JSESSIONID is not present anymore and the dispatcher applies its
> round-robin logic to dispatch the request to any tomcat.  It nullifies the
> effect of the single signon.  There is two problem that prevent it to work.
> 
> 1. On the Tomcat side, the generateSessionId() method of
>org.apache.catalina.authenticator.AuthenticatorBase does not append
>the jvmRoute of the Engine if one is specified.  So when a user changes
>webapp, the web connector dispatcher does not have any information to
>properly route the request;
> 
> 2. The current loadbalancer code specifically look for the JSESSIONID cookie
>and does not look for a JSESSIONIDSSO cookie.
> 
> I could provide a patch to org.apache.catalina.authenticator.AuthenticatorBase
> to add the jvmRoute to the session id; in fact it is a copy of the code from
> org.apache.catalina.session.ManagerBase.
> 
> The change in:
> 
>   ./jk/native/common/jk_lb_worker.c
>   ./jk/native2/common/jk_requtil.c
> 
> is also trivial, first the connector must look for the JSESSIONID cookie (or
> param), and if not found it should look for the JSESSIONIDSSO cookie (or
> param).  Then the same logic should be applied if either one is found.
> 
> Comments?
> 
> 


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

Re: mod_jk2 jvm thread issues

[costinm]

On Thu, 4 Jul 2002, Mladen Turk wrote:

> Hi,
> 
> We have still some problems with the threads and jvm attach/detach.
> The detaching is now done in the afterRequest (It was already there but
> commented), but that doesn't prevent the case of the premature request
> dying when we are processing a long request (ore hanged one) and trying
> to shutdown the server.
> 
> There fix for the Apache would be quite easy to implement (registering a
> pool cleanup for a request_rec), but the IIS imposes some problems.
> 
> IMO we are needing something like a TLS to fix that, or make the
> behavior similar to the apache's request rec, creating a pool for each
> request.
> Does anyone has some other ideas about that.

+1 on TLS, I think that would also give a bit of extra performance.

Note that you can't attach in one thread and use it in another - so
either attach/detach before/after requests or use a TLS plus 
a cleanup mechanism, the pool won't work.

Costin


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

DO NOT REPLY [Bug 10291] - JASPER fails to cause a fatal translaton error with incorrect taglib imports in the XML view of a JSP page

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

JASPER fails to cause a fatal translaton error with incorrect taglib imports in the 
XML view of a JSP page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

Re: [VOTE] 4.1.7 stability rating

[costinm]

On Fri, 5 Jul 2002, Remy Maucherat wrote:

> Note: The 4.1.7 release is virtually equivalent to 4.1.6, with the 
> addition of one major fix in Coyote JK 2 (fix for bug 10018). This is 
> why I'm posting the stability vote so soon after the release, given 
> 4.1.6 has been around for enough time, and has attracted very positive 
> feedback.
> 
> 
> [ ] Alpha
> [X] Beta
> [ ] Stable
> 
> 
> I'm voting "beta" personally, because there are many bugs which need to 
> be reviewed/fixed in Bugzilla, and because 4.1.x needs further testing 
> before going stable.

For most parts we are getting close to 'stable', all we need is more 
tests and fixes.

I still have an open question on the jasper2 variable declaration - 
I read the jsp2.0 spec and it doesn't add too much extra detail
(except it mentions something about AT_END beeing visible in
the 'scope' ). I have big problems accepting that AT_END is meant
to be defined at the beginning of the method, and the whole block 
'scoping' in all programming languages shouldn't apply to jsps.

Costin 




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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties

[luehe]

luehe   2002/07/08 10:28:58

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
  Log:
  Minor compliance fix and some resource bundle key fixes
  (Patch provided by Ryan Lubke)
  
  Revision  ChangesPath
  1.4   +12 -3 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspDocumentParser.java20 Jun 2002 23:02:16 -  1.3
  +++ JspDocumentParser.java8 Jul 2002 17:28:58 -   1.4
  @@ -434,6 +434,15 @@
   
// get the uri
String uri = attrs.getValue(i);
  + /*
  +  * make sure that a relative path is prefixed with
  +  * urn:jsptld:path
  +  */
  + if (uri.charAt(0) == '/') {
  + throw new JasperException(
  + err.getString("jsp.error.xml.taglib.uri.not_prefixed",
  +   uri));
  + }
if (uri.startsWith(URN_JSPTLD)) {
// uri value is of the form "urn:jsptld:path"
uri = uri.substring(URN_JSPTLD.length());
  
  
  
  1.11  +12 -12
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- Validator.java20 Jun 2002 23:48:23 -  1.10
  +++ Validator.java8 Jul 2002 17:28:58 -   1.11
  @@ -138,14 +138,14 @@
   
if ("language".equals(attr)) {
if (languageSeen)
  - err.jspError(n, "jsp.error.language.multiple");
  + err.jspError(n, "jsp.error.page.multiple.language");
languageSeen = true;
if (!"java".equalsIgnoreCase(value))
err.jspError(n, "jsp.error.language.nonjava");
pageInfo.setLanguage(value);
} else if ("extends".equals(attr)) {
if (extendsSeen)
  - err.jspError(n, "jsp.error.extends.multiple");
  + err.jspError(n, "jsp.error.page.multiple.extends");
extendsSeen = true;
pageInfo.setExtends(value);
/*
  @@ -158,7 +158,7 @@
n.addImport(value);
} else if ("contentType".equals(attr)) {
if (contentTypeSeen) 
  - err.jspError(n, "jsp.error.contentType.multiple");
  + err.jspError(n, "jsp.error.page.multiple.contenttypes");
contentTypeSeen = true;
pageInfo.setContentType(value);
} else if ("session".equals(attr)) {
  @@ -173,7 +173,7 @@
err.jspError(n, "jsp.error.session.invalid");
} else if ("buffer".equals(attr)) {
if (bufferSeen)
  - err.jspError(n, "jsp.error.buffer.multiple");
  + err.jspError(n, "jsp.error.page.multiple.buffer");
bufferSeen = true;
   
if ("none".equalsIgnoreCase(value))
  @@ -192,7 +192,7 @@
}
} else if ("autoFlush".equals(attr)) {
if (autoFlushSeen)
  - err.jspError(n, "jsp.error.autoFlush.multiple");
  + err.jspError(n, "jsp.error.page.multiple.autoflush");
autoFlushSeen = true;
if ("true".equalsIgnoreCase(value))
pageInfo.setAutoFlush(true);
  @@ -202,7 +202,7 @@
err.jspError(n, "jsp.error.autoFlush.invalid");
} else if ("isthreadSafe".equals(attr)) {
if (isThreadSafeSeen)
  - err.jspError(n, "jsp.error.isThreadSafe.multiple");
  + err.jspError(n, "jsp.error.page.multiple.threadsafe");
isThreadSafeSeen = true;
if ("true".equalsIgnoreCase(value))
pageInfo.setThreadSafe(true);
  @@ -212,7 +212,7 @@
err.jspError(n, "jsp.error.isThreadSafe.invalid");
} else if ("isErrorPage".equals(attr)) {
if (isErrorPageSeen)
  - 

Re: [PATCH] experimental jk2 iis thread pool

[costinm]

On Sat, 6 Jul 2002, Mladen Turk wrote:

> Before going to commit something I would like to hear some opinions, and
> tests preferably.

This is very good, and I wish we all did the same before commiting :-)

But it is common practice to commit-then-review, and if you think
a change is good and it helps you scratch an itch - just do it.

Posting informative messages before big changes is important, 
but in most cases a good ( and longer ) comment in the CVS message
would be enough. 

Don't worry - if someone has a problem you'll get a -1 very quickly :-)

Costin


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

Re: Jk2 logging

[costinm]

On Mon, 8 Jul 2002, Mladen Turk wrote:

> Hi,
> 
> Recently there was a question on the Users List about log messages in
> the Apache's error.log.
> I've changed the INFO logging to get logged as notice instead of warning
> (cause it may be misleading as the user reported).
> Now, I propose to change the every occurrence of the following:
> 
> if( ch->mbean->debug > 0 )
>   env->l->jkLog(env, env->l, JK_LOG_INFO, 
> to the :
> if( ch->mbean->debug > 0 )
>   env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
> 
> There are lots of places in the code where the second is used, but we
> should be consistent across the entire source code.
> I'll make the necessary commits, as soon I finish the macro.

+1

Just make sure the 'important' messages ( and errors ) are visible
in error.log, using the default Apache level.

The log has 2 filters - one is the jkLog level, and the second
is the global LogLevel in httpd.conf ( or whatever win32 uses for
the Event log ).

Costin  


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

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

[remm]

remm2002/07/08 09:50:46

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Fix support for HTTP/1.0 keep-alive.
  
  Revision  ChangesPath
  1.34  +3 -2  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- Http11Processor.java  26 Apr 2002 03:26:21 -  1.33
  +++ Http11Processor.java  8 Jul 2002 16:50:46 -   1.34
  @@ -739,9 +739,10 @@
   parseHost(valueMB);
   
   if (!contentDelimitation) {
  -// If there's no content length and we're using HTTP/1.1, assume
  +// If there's no content length and we're using keep-alive 
  +// (HTTP/1.0 with keep-alive or HTTP/1.1), assume
   // the client is not broken and didn't send a body
  -if (http11) {
  +if (keepAlive) {
   inputBuffer.addActiveFilter
   (inputFilters[Constants.VOID_FILTER]);
   contentDelimitation = true;
  
  
  

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

Re: Jetty and mod_jk2

[costinm]

On Thu, 4 Jul 2002, Simon Stewart wrote:

> > >The Jetty folks have been working hard on improving the connectivity
> > >between apache and jetty and so from 4.1.D2 Jetty has shipped with its
> > >own AJP13 Listener. According to Greg Wilkins, the currently shipped
> > >version has problems with authenticated and SSL connections, but these
> > >are solved in the latest CVS version.

Great news ! 

> > >Attached is a HOWTO on getting Jetty and Apache 2 talking via
> > >mod_jk2. Can I please get some feedback on this? And what do people
> > >think about this (or something similar) being included in the next
> > >release of the jtc?

I agree with Remy the jetty-specific docs should go with jetty. 

For the native code - I think we can add specific instructions or 
direct to the right place.


> > - It would also give the impression that we're somehow officially 
> > supporting Jetty in JK 2 or Coyote (we obviously don't), and people 
> > would bug us with Jetty questions/problems.

Well, both jk2 and coyote ( and in general tomcat and jasper ) is
 open source code that is intended to be usefull and reusable.
We can't support or endorse all products that include pieces
of tomcat ( enough work in supporting the tomcat release :-), but
we should do whatever possible to increase this kind of reuse - 
it helps us as much as it helps jetty. 


> > - We also have no buisness advocating Tomcat alternatives.

> It really does depend on how you're looking at it. While I can see
> your point of view, I believe that your last point is specious. 
> 
> Consider the facts:
> 
> 1) Tomcat is an Open Source product. It has no imperative to grab
> market share.
> 2) Open Source products thrive on collaboration and competition.
> 3) The AJP13 protocol, which mod_jk speaks, is openly
> documented. Tomcat has a java-side implementation of it. So does
> Jetty. The native side is common between both platforms.

+1

BTW, it may be a good idea for jetty to take a look at the 
java side of ajp as well, there are some interesting features. 
Coyote is quite flexible, and I'm sure it would be easier to 
adapt it to jetty and take advantage of all jk2 features.

And I'm looking forward to code contributions and bug fixes 
from jetty people. If there's anything we can do to help - 
please let us know. I don't see jetty as a 'competition' - 
and I hope they don't either. Our goal is to write a good servlet 
container and solve 'itches', their goal seems similar. 


Costin



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

DO NOT REPLY [Bug 10558] New: - encodeURL form submit doesn't include hidden form variables

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

encodeURL form submit doesn't include hidden form variables

   Summary: encodeURL form submit doesn't include hidden form
variables
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When encodeURL is used with a form with ENCTYPE="multipart/form-data", hidden 
values are not included in the response.


I have a jsp page that calls a servlet.

The jsp has 2 forms.

Form 1







Form 2







myservlet simply writes out what's in the request to see what's inside.

Enumeration enum = request.getParameterNames();
while (enum.hasMoreElements()) {
 System.out.println(enum.nextElement());
 }

When I submit Form 1, myservlet prints out the hidden value while Form 2 does 
not.

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

Use TreeControl in apps?

[Carsten Burghardt]

Hi,

I'm currently looking for a nice tree control to integrate in a struts 
project. Is it possible to integrate the TreeControl from the Tomcat 
4.1-admin webapp? I didn't find any other good one...

Regards,

Carsten Burghardt
-- 
Dipl. Inf. (FH) Carsten Burghardt
Login & Solutions AG
email: [EMAIL PROTECTED]
Tel: 0821/2488-311 Fax: 0821/2488-180


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

DO NOT REPLY [Bug 8459] - Tomcat Crash or stuck without DISPLAY

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

Tomcat Crash or stuck without DISPLAY





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 15:26 ---

The JDK will attempt to contact the X-Server if Fonts or other AWT Windowing
resources are requested.  Server code that attempts to use AWT to manipulate
images will often trigger this.  What version of the JDK are you using?
and what version of Solaris?

Cheers,
-bob

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

DO NOT REPLY [Bug 10555] New: - doHEAD breaks spec SRV 8.2

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

doHEAD breaks spec  SRV 8.2 

   Summary: doHEAD breaks spec  SRV 8.2
   Product: Tomcat 4
   Version: 4.1.6
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The HttpServlet.doHead method is

 protected void doHead(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
NoBodyResponse response = new NoBodyResponse(resp);

doGet(req, response);
response.setContentLength();
}

where

  class NoBodyResponse implements HttpServletResponse {...}



This breaks older versions of Jetty if a head request is
passed to a request dispatcher.  This is because Jetty used
to enforce the SRV 8.2 and the javadoc for RequestDispatcher 
that says

 * The request and response parameters must be either the same
 * objects as were passed to the calling servlet's service method or be
 * subclasses of the {@link ServletRequestWrapper} or 
 * {@link ServletResponseWrapper} classes that wrap them.


Thus the doHead mechanism breaks this because NoBodyResponse
does not extend HttpServletResponseWrapper.

The NoBodyResponse should extend the wrapper, so that containers can
enforce the SRC8.2 if they wish.

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

Doc fix "manager.xml"

[Bob Herrmann]

This patch makes the documentation reflect 4.1.x's behavior. Namely,
the only way to set the session timeout is via the webapp's web.xml
or the system wide web.xml  (also see bug 7613)

Cheers,
-bob

Index: manager.xml
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/config/manager.xml,v
retrieving revision 1.2
diff -u -r1.2 manager.xml
--- manager.xml 26 Sep 2001 01:38:08 -  1.2
+++ manager.xml 8 Jul 2002 13:38:27 -
@@ -62,10 +62,14 @@
 created by this Manager.  If not specified, the default value
is
 sixty (60) minutes.
 
-NOTE - The value for this property is
inherited
-automatically if you specify a

-element in the web application deployment descriptor
-(/WEB-INF/web.xml).
+NOTE - The value for this property is set
+automatically.  if you specify a
+ element in the web
+application deployment descriptor
+(/WEB-INF/web.xml), it is used, otherwise the
+system wide default from
+$TOMCAT_HOME/conf/web.xml is used.
+
   
 
 



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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel.c

[mturk]

mturk   2002/07/08 06:42:14

  Modified:jk/native2/common jk_channel.c
  Log:
  no message
  
  Revision  ChangesPath
  1.6   +5 -5  jakarta-tomcat-connectors/jk/native2/common/jk_channel.c
  
  Index: jk_channel.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_channel.c  29 Jun 2002 18:32:30 -  1.5
  +++ jk_channel.c  8 Jul 2002 13:42:14 -   1.6
  @@ -108,27 +108,27 @@
   int rc=JK_OK;
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "ch.%d() \n", code);
   
   switch( code ) {
   case CH_OPEN: {
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "ch.open()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "ch.open()\n");
   if( ch->open != NULL )
   rc=ch->open(env, ch, ep);
   return rc;
   }
   case CH_CLOSE: {
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "ch.close()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "ch.close()\n");
   if( ch->close != NULL )
   rc=ch->close(env, ch, ep);
   return rc;
   }
   case CH_READ: {
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "ch.recv()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "ch.recv()\n");
   if( ch->recv != NULL )
   rc=ch->recv(env, ch, ep, msg);
   if( rc==JK_OK )
  @@ -137,7 +137,7 @@
   }
   case CH_WRITE: {
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "ch.send()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "ch.send()\n");
   if( ch->serverSide )
   msg->serverSide=JK_TRUE;
   if( ch->send != NULL )
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_apr_socket.c

[mturk]

mturk   2002/07/08 06:42:03

  Modified:jk/native2/common jk_channel_apr_socket.c
  Log:
  no message
  
  Revision  ChangesPath
  1.24  +1 -1  
jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c
  
  Index: jk_channel_apr_socket.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_apr_socket.c,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_channel_apr_socket.c   27 Jun 2002 17:19:09 -  1.23
  +++ jk_channel_apr_socket.c   8 Jul 2002 13:42:03 -   1.24
  @@ -289,7 +289,7 @@
   }
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelApr.open(), sock = %d\n", sock);
   
   /* store the channel information */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c

[mturk]

mturk   2002/07/08 06:41:47

  Modified:jk/native2/common jk_channel_jni.c
  Log:
  no message
  
  Revision  ChangesPath
  1.32  +9 -10 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
  
  Index: jk_channel_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- jk_channel_jni.c  2 Jul 2002 12:08:25 -   1.31
  +++ jk_channel_jni.c  8 Jul 2002 13:41:46 -   1.32
  @@ -367,7 +367,7 @@
   (jk_ch_jni_ep_private_t *)endpoint->channelData;
   
   if( _this->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,"channel_jni.send() %#lx\n", epData 
); 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,"channel_jni.send() %#lx\n", epData 
); 
   
   if( epData == NULL ) {
   jk2_channel_jni_open( env, _this, endpoint );
  @@ -388,7 +388,7 @@
   b=msg->buf;
   
   if( _this->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,"channel_jni.send() (1) %#lx\n", 
epData ); 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,"channel_jni.send() (1) %#lx\n", 
epData ); 
   
   jniEnv=NULL; /* epData->jniEnv; */
   jbuf=epData->jarray;
  @@ -409,7 +409,7 @@
   }
   
   if( _this->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channel_jni.send() getting byte array \n" );
   
   /* Copy the data in the ( recycled ) jbuf, then call the
  @@ -439,7 +439,7 @@
   (*jniEnv)->ReleaseByteArrayElements(jniEnv, jbuf, nbuf, 0);
   #endif
   if( _this->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channel_jni.send() before send %#lx\n",
 (void *)(long)epData->jniJavaContext); 
   
  @@ -449,7 +449,7 @@
(jlong)(long)(void *)env,
epData->jniJavaContext );
   if( _this->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,"channel_jni.send() result %d\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,"channel_jni.send() result %d\n",
 sent); 
   return JK_OK;
   }
  @@ -507,7 +507,7 @@
   jk_workerEnv_t *we=worker->workerEnv;
   
   if( worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "service() attaching to vm\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "service() attaching to vm\n");
   
   return JK_OK;
   }
  @@ -527,9 +527,8 @@
   return JK_OK;
   }
   we->vm->detach( env, we->vm );
  -
   if( worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "channelJni.afterRequest() ok\n");
   return JK_OK;
   }
  @@ -567,13 +566,13 @@
   int rc=JK_OK;
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "ch.%d() \n", code);
   
   code = (int)msg->getByte(env, msg);
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,"channelJni.java2cInvoke() %d\n", 
code);
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,"channelJni.java2cInvoke() %d\n", 
code);
   
   return ep->worker->workerEnv->dispatch( env, ep->worker->workerEnv,
   ep->currentRequest, ep, code, ep->reply 
);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[mturk]

mturk   2002/07/08 06:41:30

  Modified:jk/native2/common jk_channel_socket.c
  Log:
  no message
  
  Revision  ChangesPath
  1.38  +5 -5  jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk_channel_socket.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- jk_channel_socket.c   2 Jul 2002 16:53:15 -   1.37
  +++ jk_channel_socket.c   8 Jul 2002 13:41:30 -   1.38
  @@ -193,7 +193,7 @@
   }
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channel_socket.init(): %s:%d \n", socketInfo->host, 
socketInfo->port );
   
   return rc;
  @@ -304,7 +304,7 @@
   /* Tries to connect to JServ (continues trying while error is EINTR) */
   do {
   if( ch->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelSocket.open() connect on %d\n",sock);
   
   ret = connect(sock,(struct sockaddr *)addr,
  @@ -340,7 +340,7 @@
   }   
   
   if( ch->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelSocket.connect(), sock = %d\n", sock);
   
   endpoint->sd=sock;
  @@ -545,7 +545,7 @@
   }
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelSocket.receive(): Received len=%d type=%d\n",
 blen, (int)msg->buf[hlen]);
   return JK_OK;
  @@ -608,7 +608,7 @@
   }
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelSocket.receive(): Received len=%d type=%d total=%d\n",
 blen, (int)msg->buf[hlen], inBuf );
   return JK_OK;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_un.c

[mturk]

mturk   2002/07/08 06:41:13

  Modified:jk/native2/common jk_channel_un.c
  Log:
  no message
  
  Revision  ChangesPath
  1.13  +5 -5  jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c
  
  Index: jk_channel_un.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_un.c,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- jk_channel_un.c   10 Jun 2002 21:55:06 -  1.12
  +++ jk_channel_un.c   8 Jul 2002 13:41:13 -   1.13
  @@ -160,7 +160,7 @@
   strcpy(socketInfo->unix_addr.sun_path,  socketInfo->file );
   
   if( ch->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelUn.init(): create AF_UNIX  %s\n", 
socketInfo->file );
   } else {
   env->l->jkLog(env, env->l, JK_LOG_ERROR, "channelUn.init(): "
  @@ -263,7 +263,7 @@
   }
   
   if( ch->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelUn.open(): create unix socket %s %d\n", 
socketInfo->file, unixsock );
   
   if (connect(unixsock,(struct sockaddr *)&(socketInfo->unix_addr),
  @@ -277,7 +277,7 @@
   }
   
   if( ch->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelUn.open(): connect unix socket %d %s\n", unixsock, 
socketInfo->file );
   /* store the channel information */
   endpoint->sd=unixsock;
  @@ -334,7 +334,7 @@
   this_time = write(unixsock, (char *)b + sent , len - sent);
   
   if( ch->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channel.apr:send() write() %d %d %s\n", this_time, errno,
 strerror( errno));
   if(0 == this_time) {
  @@ -436,7 +436,7 @@
   }
   
   if( ch->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "channelUn.receive(): Received len=%d type=%d\n",
 blen, (int)msg->buf[hlen]);
   return JK_OK;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_config.c

[mturk]

mturk   2002/07/08 06:40:54

  Modified:jk/native2/common jk_config.c
  Log:
  no message
  
  Revision  ChangesPath
  1.27  +5 -5  jakarta-tomcat-connectors/jk/native2/common/jk_config.c
  
  Index: jk_config.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_config.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_config.c   10 Jun 2002 21:55:06 -  1.26
  +++ jk_config.c   8 Jul 2002 13:40:54 -   1.27
  @@ -199,7 +199,7 @@
   }
   
   if( cfg->mbean->debug > 0 )
  -env->l->jkLog( env, env->l, JK_LOG_INFO, "config: set %s / %s / %#lx / %s = 
%s\n",
  +env->l->jkLog( env, env->l, JK_LOG_DEBUG, "config: set %s / %s / %#lx / %s 
= %s\n",
  mbean->name, name, mbean, pname, val);
   
   if( strcmp( name, "name" ) == 0 ) {
  @@ -234,7 +234,7 @@
   /* 'file' property on ourself, avoid rec.
*/
   if( cfg->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "config.setAttribute() ignore %s %s %s\n", mbean->name, 
name, val );
   
   return JK_OK;
  @@ -247,7 +247,7 @@
 "config.setAttribute() Error setting %s %s %s\n", 
mbean->name, name, val );
   }
   if( cfg->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "config.setAttribute() %d setting %s %s %s\n",
 cfg->mbean->debug, mbean->name, name, val );
   return rc;
  @@ -401,13 +401,13 @@
   char *verString;
   
   if( cfg->mbean->debug > 5 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "config.setConfig():  process %s\n", name );
   
   bean=env->getBean( env, name );
   if( bean==NULL ) {
   if( cfg->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "config.setConfig():  Creating %s\n", name );
   }
   bean=env->createBean( env, cfg->pool, name );
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_config_file.c

[mturk]

mturk   2002/07/08 06:40:41

  Modified:jk/native2/common jk_config_file.c
  Log:
  no message
  
  Revision  ChangesPath
  1.4   +1 -1  jakarta-tomcat-connectors/jk/native2/common/jk_config_file.c
  
  Index: jk_config_file.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_config_file.c,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_config_file.c  10 Jun 2002 21:55:06 -  1.3
  +++ jk_config_file.c  8 Jul 2002 13:40:41 -   1.4
  @@ -265,7 +265,7 @@
   
   if( !firstTime && statbuf.st_mtime < cfg->mtime ) {
   if( cfg->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "config.update(): No reload needed %s %ld %ld\n", 
cfg->file,
 cfg->mtime, statbuf.st_mtime );
   return JK_OK;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_endpoint.c

[mturk]

mturk   2002/07/08 06:40:27

  Modified:jk/native2/common jk_endpoint.c
  Log:
  no message
  
  Revision  ChangesPath
  1.21  +2 -2  jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c
  
  Index: jk_endpoint.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_endpoint.c,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- jk_endpoint.c 5 Jul 2002 08:05:15 -   1.20
  +++ jk_endpoint.c 8 Jul 2002 13:40:27 -   1.21
  @@ -103,14 +103,14 @@
   ep->workerEnv->epStat->structSize=sizeof( jk_stat_t );
   ep->workerEnv->epStat->structCnt=ep->mbean->id + 1;
   if( ep->worker != NULL && ep->worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "SHM stats %d %#lx %#lx %s %s childId=%d\n", 
ep->mbean->id,
 ep->workerEnv->epStat->data, stats,
 ep->mbean->localName, ep->mbean->name, 
ep->workerEnv->childId);
   } else {
   stats = (jk_stat_t *)ep->mbean->pool->calloc( env, ep->mbean->pool, sizeof( 
jk_stat_t ) );
   if( ep->worker != NULL && ep->worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "Local stats %d %#lx %d\n", ep->mbean->id, 
ep->workerEnv->epStat, ep->workerEnv->childId );
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_env.c

[mturk]

mturk   2002/07/08 06:40:02

  Modified:jk/native2/common jk_env.c
  Log:
  no message
  
  Revision  ChangesPath
  1.37  +7 -7  jakarta-tomcat-connectors/jk/native2/common/jk_env.c
  
  Index: jk_env.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_env.c,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- jk_env.c  11 Jun 2002 02:51:18 -  1.36
  +++ jk_env.c  8 Jul 2002 13:40:02 -   1.37
  @@ -154,7 +154,7 @@
   if( env->l == NULL ) 
   fprintf( stderr, "env:Create child env %#lx %#lx\n", parentEnv, 
env);
   else 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env:Create child env %#lx %#lx\n", parentEnv, env);
   }
   }
  @@ -245,7 +245,7 @@
   
   if( env->debug > 0 ) {
   if( env->l != NULL ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env.createBean2(): Create [%s] %s\n", type, localName);
   } else {
   fprintf(stderr, "env.createBean2(): Create [%s] %s\n", type, localName);
  @@ -309,7 +309,7 @@
   if( env->l == NULL ) 
   fprintf(stderr,"env.createBean2(): register %s %#lx\n", result->name, 
result->object);
   else 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env.createBean2(): register %s %#lx\n", result->name, 
result->object);
   }
   
  @@ -342,7 +342,7 @@
   if( env->debug > 0 )
   fprintf(stderr,"env.alias(): Not found %s\n", name);
   } else {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env.alias(): Not found %s\n", name);
   }
   return ;
  @@ -352,7 +352,7 @@
   if( env->l == NULL ) 
   fprintf(stderr,"env.alias(): alias %s %s\n", name, alias);
   else 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env.alias(): alias %s %s\n", name, alias);
   }
   
  @@ -370,7 +370,7 @@
   if( env->l == NULL ) 
   fprintf(stderr,"env.getByName(): Can't find %#lx %s\n", env, name);
   else 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env.getByName(): Can't find %#lx %s\n", env, name);
   }
   return NULL;
  @@ -380,7 +380,7 @@
   if( env->l == NULL ) 
   fprintf(stderr,"env.getByName(): Get by name %s %#lx\n", name, 
result->object);
   else 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "env.getByName(): Get by name %s %#lx\n", name, 
result->object);
   }
   return result->object;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_handler_response.c

[mturk]

mturk   2002/07/08 06:39:12

  Modified:jk/native2/common jk_handler_response.c
  Log:
  no message
  
  Revision  ChangesPath
  1.23  +2 -2  
jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c
  
  Index: jk_handler_response.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_handler_response.c,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- jk_handler_response.c 20 Jun 2002 18:45:01 -  1.22
  +++ jk_handler_response.c 8 Jul 2002 13:39:12 -   1.23
  @@ -152,7 +152,7 @@
   jk_xlate_from_ascii(valueS, strlen(valueS));
   
   if(debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "handler.response() Header[%d] [%s] = [%s]\n", 
 i, nameS, valueS);
   
  @@ -169,7 +169,7 @@
   
   
   if(debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "handler.response(): status=%d headers=%d\n",
 s->status, headerCount);
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_mutex.c

[mturk]

mturk   2002/07/08 06:38:26

  Modified:jk/native2/common jk_mutex.c
  Log:
  no message
  
  Revision  ChangesPath
  1.4   +4 -4  jakarta-tomcat-connectors/jk/native2/common/jk_mutex.c
  
  Index: jk_mutex.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_mutex.c,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_mutex.c10 Jun 2002 21:55:06 -  1.3
  +++ jk_mutex.c8 Jul 2002 13:38:26 -   1.4
  @@ -77,23 +77,23 @@
   int rc=JK_OK;
   
   if( mutex->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "mutex.%d() \n", code);
   
   switch( code ) {
   case MUTEX_LOCK: {
   if( mutex->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "mutex.open()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "mutex.open()\n");
   return mutex->lock(env, mutex);
   }
   case MUTEX_TRYLOCK: {
   if( mutex->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "mutex.close()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "mutex.close()\n");
   return mutex->tryLock(env, mutex);
   }
   case MUTEX_UNLOCK: {
   if( mutex->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "mutex.recv()\n");
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "mutex.recv()\n");
   return mutex->unLock(env, mutex);
   }
   }/* switch */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_requtil.c

[mturk]

mturk   2002/07/08 06:37:54

  Modified:jk/native2/common jk_requtil.c
  Log:
  no message
  
  Revision  ChangesPath
  1.23  +2 -2  jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c
  
  Index: jk_requtil.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_requtil.c,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- jk_requtil.c  10 Jun 2002 21:55:06 -  1.22
  +++ jk_requtil.c  8 Jul 2002 13:37:54 -   1.23
  @@ -575,7 +575,7 @@
   }
   } else {
   if( debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "serialize.request() Add headerName %s\n", name);
   if (msg->appendString(env, msg, name)) {
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
  @@ -700,7 +700,7 @@
   
   
   if( debug > 0  )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "serialize.request() serialized %s\n", s->req_uri);
   
   /*  msg->dump( env, msg, "Dump: " ); */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_shm.c

[mturk]

mturk   2002/07/08 06:37:10

  Modified:jk/native2/common jk_shm.c
  Log:
  no message
  
  Revision  ChangesPath
  1.28  +8 -8  jakarta-tomcat-connectors/jk/native2/common/jk_shm.c
  
  Index: jk_shm.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_shm.c,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- jk_shm.c  12 Jun 2002 12:40:17 -  1.27
  +++ jk_shm.c  8 Jul 2002 13:37:10 -   1.28
  @@ -128,12 +128,12 @@
   shm->head = (jk_shm_head_t *)shm->image;
   
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_ERROR, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "shm.create(): GLOBAL_SHM  %#lx\n", shm->image );
   return JK_OK;
   } else {
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_ERROR, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "shm.create(): NO GLOBAL_SHM  %#lx\n", shm->image );
   }
   
  @@ -157,7 +157,7 @@
   rc=apr_file_info_get(&finfo, APR_FINFO_SIZE, file);
   
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "shm.create(): file open %s %d %d\n", shm->fname, shm->size, 
finfo.size );
   
   if( finfo.size < shm->size ) {
  @@ -254,7 +254,7 @@
   }
   
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "shm.create(): file open %s %d %d\n", shm->fname, shm->size, 
filestat.st_size );
   
   if (filestat.st_size < shm->size ) {
  @@ -342,7 +342,7 @@
   }
   
   if( shm->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "shm.init(): file=%s size=%d\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "shm.init(): file=%s size=%d\n",
 shm->fname, shm->size);
   }
   
  @@ -362,7 +362,7 @@
   }
   
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "shm.create(): shm created %#lx\n", shm->head );
   
   return JK_OK;
  @@ -383,7 +383,7 @@
   shm->head->lastSlot = 1;
   
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "shm.init() Reset %s %#lx\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "shm.init() Reset %s %#lx\n",
 shm->fname, shm->image);
   
   return JK_OK;
  @@ -538,7 +538,7 @@
   jk_shm_t *shm=(jk_shm_t *)bean->object;
   
   if( shm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "shm.%d() \n", code);
   
   switch( code ) {
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriEnv.c

[mturk]

mturk   2002/07/08 06:36:29

  Modified:jk/native2/common jk_uriEnv.c
  Log:
  no message
  
  Revision  ChangesPath
  1.24  +9 -9  jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c
  
  Index: jk_uriEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriEnv.c,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- jk_uriEnv.c   10 Jun 2002 21:55:06 -  1.23
  +++ jk_uriEnv.c   8 Jul 2002 13:36:29 -   1.24
  @@ -260,16 +260,16 @@
   }
   if( uriEnv->mbean->debug > 0 ) {
   if( uriEnv->match_type == MATCH_TYPE_CONTEXT ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() context mapping %s=%s \n",
 uriEnv->prefix, uriEnv->workerName);
   
   } else if( uriEnv->match_type == MATCH_TYPE_HOST ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() host mapping %s=%s \n",
 uriEnv->virtual, uriEnv->workerName);
   } else {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() exact mapping %s=%s \n",
 uriEnv->prefix, uriEnv->workerName);
   }
  @@ -297,7 +297,7 @@
   uriEnv->match_type = MATCH_TYPE_CONTEXT_PATH;
   
   if( uriEnv->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "Into jk_uri_worker_map_t::uri_worker_map_open, "
 "general context path rule %s * %s -> %s was added\n",
 uri, asterisk + 2, uriEnv->workerName);
  @@ -311,7 +311,7 @@
   uriEnv->suffix  = asterisk + 3;
   uriEnv->match_type  = MATCH_TYPE_SUFFIX;
   if( uriEnv->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() suffix mapping %s .%s=%s was added\n",
 uriEnv->prefix, uriEnv->suffix, uriEnv->workerName);
   }
  @@ -323,7 +323,7 @@
   uriEnv->prefix_len  =strlen( uriEnv->prefix );
   uriEnv->match_type = MATCH_TYPE_GENERAL_SUFFIX;
   if( uriEnv->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() general suffix mapping %s.%s=%s\n",
 uri, asterisk + 2, uriEnv->workerName);
   }
  @@ -336,7 +336,7 @@
   uriEnv->prefix_len  =strlen( uriEnv->prefix );
   uriEnv->match_type  = MATCH_TYPE_PREFIX;
   if( uriEnv->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() prefix mapping %s=%s\n",
 uriEnv->prefix, uriEnv->workerName);
   }
  @@ -349,13 +349,13 @@
   uriEnv->suffix  = NULL;
   uriEnv->match_type  = MATCH_TYPE_PREFIX;
   if( uriEnv->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriEnv.init() prefix mapping2 %s=%s\n",
 uri, uriEnv->workerName);
   }
   }
   if( uriEnv->mbean->debug > 0 )
  -env->l->jkLog( env, env->l, JK_LOG_INFO,
  +env->l->jkLog( env, env->l, JK_LOG_DEBUG,
  "uriEnv.init()  %s  host=%s  uri=%s type=%d ctx=%s prefix=%s 
suffix=%s\n",
  uriEnv->mbean->name, uriEnv->virtual, uriEnv->uri,
  uriEnv->match_type, uriEnv->contextPath, uriEnv->prefix, 
uriEnv->suffix );
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_uriMap.c

[mturk]

mturk   2002/07/08 06:35:53

  Modified:jk/native2/common jk_uriMap.c
  Log:
  no message
  
  Revision  ChangesPath
  1.35  +18 -18jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c
  
  Index: jk_uriMap.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_uriMap.c,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- jk_uriMap.c   10 Jun 2002 21:55:06 -  1.34
  +++ jk_uriMap.c   8 Jul 2002 13:35:53 -   1.35
  @@ -144,7 +144,7 @@
   {
   uriMap->maps->put( env, uriMap->maps, uriEnv->name, uriEnv, NULL );
   if( uriMap->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.addUriEnv() %s %s %s\n", uriEnv->name, 
uriEnv->virtual, uriEnv->uri);
   return JK_OK;
   }
  @@ -211,7 +211,7 @@
   if(0 == strcmp(suffix, uwr->suffix)) {
   #endif
   if( uriMap->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l,JK_LOG_INFO,
  +env->l->jkLog(env, env->l,JK_LOG_DEBUG,
 "uriMap.mapUri() suffix match %s\n",
 uwr->suffix );
   }
  @@ -336,7 +336,7 @@
   uriMap->defaultVhost=mbean->object;
   
   if( uriMap->mbean->debug > 5 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "uriMap.init() set default 
host\n"); 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "uriMap.init() set default 
host\n"); 
   
   /* Initialize the vhosts table */
   for(i = 0 ; i < uriMap->maps->size( env, uriMap->maps ) ; i++) {
  @@ -350,7 +350,7 @@
uriEnv->virtual, uriEnv, NULL );
   }
   if( uriMap->mbean->debug > 5 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.init() loaded host %s\n",uriEnv->virtual); 
   }
   }
  @@ -390,7 +390,7 @@
   env->createBean2( env, uriMap->mbean->pool, "uri", uriPath );
   rootCtx=env->getByName2( env, "uri", uriPath );
   if( uriMap->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.init() Create default context %s\n", uriPath 
);
   rootCtx->mbean->setAttribute( env, rootCtx->mbean, "context", "/" );
   }
  @@ -401,7 +401,7 @@
   env->createBean2( env, uriMap->mbean->pool, "uri", "/" );
   uriEnv=env->getByName2( env, "uri", "/" );
   if( uriMap->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.init() Create default context / ( for default 
host )\n" );
   uriEnv->mbean->setAttribute( env, uriEnv->mbean, "context", "/" );
   }
  @@ -413,7 +413,7 @@
   char *uri;
   char *context;
   if( uriEnv==NULL ) {
  -env->l->jkLog(env, env->l, JK_LOG_ERROR,
  +env->l->jkLog(env, env->l, JK_LOG_INFO,
 "uriMap.init() NPE\n");
   }
   uri=uriEnv->uri;
  @@ -424,7 +424,7 @@
   jk_uriEnv_t *hostEnv=jk2_uriMap_hostMap( env, uriMap, vhost );
   
   if( uriMap->mbean->debug > 5 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.init() loaded context %s %s %#lx %#lx %#lx\n",
 uriEnv->virtual, context, hostEnv, hostEnv->webapps,
 uriMap->pool); 
  @@ -442,7 +442,7 @@
   }
   
   if( uriMap->mbean->debug > 5 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.init() processing mappings\n");
   
   /* All other mappings are added in the right context leaf.
  @@ -487,7 +487,7 @@
   {
   
   if( uriMap->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "uriMap.destroy()\n"); 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "uriMap.destroy()\n"); 
   
   /* this can't be null ( or a NPE would have been generated */
   uriMap->pool->close(env, uriMap->pool);
  @@ -562,7 +562,7 @@
return NULL;
   
   if( uriMap->mbean->debug > 1 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "uriMap.mapUri() %s %s\n", vhost, uri);
   
   if( '/' != uri[0]) {
  @@ -574,7 +574,7 @@
   hostEnv=jk2_uriMap_hostMap( env, uriMap, vhost );
   
  

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c

[mturk]

mturk   2002/07/08 06:35:02

  Modified:jk/native2/common jk_vm_default.c
  Log:
  no message
  
  Revision  ChangesPath
  1.21  +5 -5  jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c
  
  Index: jk_vm_default.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- jk_vm_default.c   5 Jul 2002 08:06:51 -   1.20
  +++ jk_vm_default.c   8 Jul 2002 13:35:02 -   1.21
  @@ -237,7 +237,7 @@
   }
   
   if( jkvm->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,  
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,  
 "jni.loadJvm() %s symbols resolved\n",
 jkvm->jvm_dll_path); 
   
  @@ -273,8 +273,8 @@
  appropriate interface. There is no need to call the AttachCurrentThread.
   */
   if( err == 0) {
  -if( jkvm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "vm.attach() allready 
attached\n");
  +if( jkvm->mbean->debug >= 0 )
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "vm.attach() allready 
attached\n");
   return (void *)rc;
   }
   /* The error code is either JNI_OK (allready attached) or JNI_EDETACHED.
  @@ -295,8 +295,8 @@
 "vm.attach() error %d\n", err);
   return NULL;
   }
  -if( jkvm->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "vm.attach() ok\n");
  +if( jkvm->mbean->debug >= 0 )
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "vm.attach() ok\n");
   return (void *)rc;
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_ajp13.c

[mturk]

mturk   2002/07/08 06:34:26

  Modified:jk/native2/common jk_worker_ajp13.c
  Log:
  no message
  
  Revision  ChangesPath
  1.38  +15 -15jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c
  
  Index: jk_worker_ajp13.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_ajp13.c,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- jk_worker_ajp13.c 8 Jul 2002 00:26:07 -   1.37
  +++ jk_worker_ajp13.c 8 Jul 2002 13:34:26 -   1.38
  @@ -202,7 +202,7 @@
   static void jk2_close_endpoint(jk_env_t *env, jk_endpoint_t *ae)
   {
   if( ae->worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "endpoint.close() %s\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "endpoint.close() %s\n",
 ae->worker->mbean->name);
   
   /* ae->reuse = JK_FALSE; */
  @@ -236,7 +236,7 @@
   }
   
   if( ae->worker->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.connect() %s %s\n", ae->worker->channelName, 
channel->mbean->name );
   
   err=channel->open( env, channel, ae );
  @@ -324,7 +324,7 @@
   return err;
   }
   if( worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.service() connecting to endpoint \n");
   }
   
  @@ -422,16 +422,16 @@
   int err;
   
   if( e->worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.forwardST() Before calling native channel %s\n",
 e->worker->channel->mbean->name);
   err=e->worker->channel->send( env, e->worker->channel, e,
 e->request );
   if( e->worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.forwardST() After %d\n",err);
   
  -
  +
   return err;
   }

  @@ -483,7 +483,7 @@
   }
   
   if( w->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.service() %s\n", w->channelName);
   
   if( w->channel->beforeRequest != NULL ) {
  @@ -502,7 +502,7 @@
   }
   
   if( w->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.service() done %s\n", e->worker->mbean->name);
   
   if( w->channel->afterRequest != NULL ) {
  @@ -547,7 +547,7 @@
   return rc;
   }
   if( w->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.done() return to pool %s\n",
 w->mbean->name );
   return JK_OK;
  @@ -603,11 +603,11 @@
   
   if( ajp13->mbean->debug > 0 ) {
   if (ret==JK_OK)
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.getEndpoint(): Created endpoint %s %s \n",
 ajp13->mbean->name, jkb->name);
   else
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.getEndpoint(): endpoint creation %s %s failed\n",
 ajp13->mbean->name, jkb->name);
   }
  @@ -725,7 +725,7 @@
   lb->mbean->setAttribute(env, lb->mbean, "worker",
   ajp13->mbean->name);
   if( ajp13->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.init(): Adding %s to default lb\n", 
ajp13->mbean->localName);
   } else {
   for( i=0; imbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.init(): Adding %s to %s\n",
 ajp13->mbean->localName, name);
   lb= env->getByName2( env, "lb", name );
   if( lb==NULL ) {
   /* Create the lb group */
   if( ajp13->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "ajp13.init(): Automatically creating the grou

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_lb.c

[mturk]

mturk   2002/07/08 06:33:38

  Modified:jk/native2/common jk_worker_lb.c
  Log:
  no message
  
  Revision  ChangesPath
  1.23  +4 -4  jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c
  
  Index: jk_worker_lb.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_lb.c,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- jk_worker_lb.c29 Jun 2002 18:28:10 -  1.22
  +++ jk_worker_lb.c8 Jul 2002 13:33:38 -   1.23
  @@ -374,7 +374,7 @@
   }
   
   if( lb->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "lb.service() try %s\n", rec->mbean->name );
   
   if( rec->route==NULL ) {
  @@ -446,7 +446,7 @@
* another worker... Lets try to do that.
*/
   if( lb->mbean->debug > 0 ) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "lb_worker.service() try other hosts\n");
   }
   }
  @@ -512,7 +512,7 @@
   lb->lbWorkerMap->add(env, lb->lbWorkerMap, value, "");
   
   if( lb->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "lb_worker.setAttribute(): Adding to %s: %s\n", 
lb->mbean->localName, value);
   
   jk2_lb_refresh( env, lb );
  @@ -542,7 +542,7 @@
   /* if( lb->workerEnv->shm != NULL && lb->workerEnv->shm->head != NULL)  */
   /* jk2_lb_updateWorkers(env, lb, lb->workerEnv->shm); */
   if( lb->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "lb.init() %s %d workers\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "lb.init() %s %d workers\n",
 lb->mbean->name, num_of_workers );
   
   return JK_OK;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c

[mturk]

mturk   2002/07/08 06:32:49

  Modified:jk/native2/common jk_worker_status.c
  Log:
  no message
  
  Revision  ChangesPath
  1.30  +1 -1  jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c
  
  Index: jk_worker_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_status.c,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- jk_worker_status.c10 Jun 2002 21:55:06 -  1.29
  +++ jk_worker_status.c8 Jul 2002 13:32:49 -   1.30
  @@ -423,7 +423,7 @@
   int didUpdate;
   
   if( w->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "status.service() %s %s\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "status.service() %s %s\n",
 JK_CHECK_NULL(uri), JK_CHECK_NULL(s->query_string));
   
   /* Generate the header */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c

[mturk]

mturk   2002/07/08 06:32:15

  Modified:jk/native2/common jk_workerEnv.c
  Log:
  no message
  
  Revision  ChangesPath
  1.56  +5 -5  jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c
  
  Index: jk_workerEnv.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_workerEnv.c,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- jk_workerEnv.c20 Jun 2002 18:45:01 -  1.55
  +++ jk_workerEnv.c8 Jul 2002 13:32:14 -   1.56
  @@ -326,7 +326,7 @@
   if( wEnv->shm != NULL && wEnv->shm->head != NULL ) {
   wEnv->shm->reset( env, wEnv->shm);
   if( wEnv->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_ERROR, "workerEnv.init() Reset shm\n" 
);
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "workerEnv.init() Reset shm\n" 
);
   }
return JK_OK;
   }
  @@ -378,7 +378,7 @@
   jk_bean_t *jkb=env->createBean2(env, wEnv->pool, "lb", "lb" );
   w=jkb->object;
   if( wEnv->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_ERROR, "workerEnv.init() create 
default worker %s\n",  jkb->name );
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "workerEnv.init() create 
default worker %s\n",  jkb->name );
   }
   wEnv->defaultWorker= w;
   }
  @@ -427,7 +427,7 @@
   }
   
   if( wEnv->mbean->debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "workerEnv.dispatch() Calling %d %s\n", handler->messageId,
 handler->name);
   
  @@ -470,7 +470,7 @@
   handler=NULL;
   
   if( ep->worker->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "workerEnv.callbacks() %s\n",
 ep->worker->channel->mbean->name);
   
  
  
  

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

Re: DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs

[Simon Stewart]

On Mon, Jul 08, 2002 at 01:49:17AM -0700, vicky kak wrote:
> Hi,
>   I have already mailed you and informed you to remove
> myself from your mailing list,but it seems no action
> have been taken.I have mialed you on saturday but I
> still got the posts on monday.Please remove my id from
> your mailing list as I dont get the required mails.Hope
> to unsubscribed now..

Vicky, why not just follow the links at the bottom of all the emails
from this list? I include the line from your own post...

> To unsubscribe, e-mail:   

HTH. HAND.

Cheers,

Simon

-- 
"Even had to open up the case and gaze upon the hallowed peace that
graced the helpdesk that day." -- Megahal (trained on asr), 1998-11-06

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 mod_jk2.c

[mturk]

mturk   2002/07/08 06:31:23

  Modified:jk/native2/server/apache2 mod_jk2.c
  Log:
  no message
  
  Revision  ChangesPath
  1.39  +5 -5  jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c
  
  Index: mod_jk2.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/mod_jk2.c,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- mod_jk2.c 1 Jul 2002 15:46:20 -   1.38
  +++ mod_jk2.c 8 Jul 2002 13:31:23 -   1.39
  @@ -580,7 +580,7 @@
   }
   
   if( uriEnv->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "mod_jk.handler() serving %s with %#lx %#lx %s\n",
 uriEnv->mbean->localName, worker, worker->mbean, 
worker->mbean->localName );
   
  @@ -590,7 +590,7 @@
   if( rPool == NULL ) {
   rPool=worker->mbean->pool->create( env, worker->mbean->pool, HUGE_POOL_SIZE 
);
   if( uriEnv->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO,
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG,
 "mod_jk.handler(): new rpool %#lx\n", rPool );
   }
   
  @@ -656,7 +656,7 @@
*/
   if( uriEnv!= NULL && uriEnv->workerName != NULL) {
   if( uriEnv->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "PerDir mapping  %s=%s\n",r->uri, uriEnv->workerName);
   
   ap_set_module_config( r->request_config, &jk2_module, uriEnv );
  @@ -692,7 +692,7 @@
   r->handler=JK_HANDLER;
   
   if( uriEnv->mbean->debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "mod_jk.translate(): uriMap %s %s %#lx\n",
 r->uri, uriEnv->workerName, uriEnv->worker);
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_service_apache2.c

[mturk]

mturk   2002/07/08 06:30:57

  Modified:jk/native2/server/apache2 jk_service_apache2.c
  Log:
  no message
  
  Revision  ChangesPath
  1.27  +5 -5  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c
  
  Index: jk_service_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_service_apache2.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_service_apache2.c  10 Jun 2002 21:55:08 -  1.26
  +++ jk_service_apache2.c  8 Jul 2002 13:30:56 -   1.27
  @@ -126,7 +126,7 @@
   numheaders = headers->size(env, headers);
   /* XXX As soon as we switch to jk_map_apache2, this will not be needed ! */
   if( debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "service.head() %d %d %#lx\n", s->status,
 numheaders, s->uriEnv);
   
  @@ -137,7 +137,7 @@
   val=s->pool->pstrdup( env, s->pool, val );
   
   if( debug > 0 ) 
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "service.head() %s: %s %d %d\n", name, val, h, 
headers->size( env, headers ));
   
   /* the cmp can also be avoided in we do this earlier and use
  @@ -257,7 +257,7 @@
   
   if(!s->response_started) {
   if( debug > 0 )
  -env->l->jkLog(env, env->l, JK_LOG_INFO, 
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, 
 "service.write() default head\n");
   rc=s->head(env, s);
   if( rc != JK_OK) {
  @@ -273,7 +273,7 @@
   
   if( debug > 0 ) {
   for(i = 0 ; i < t->nelts ; i++) {
  -env->l->jkLog(env, env->l, JK_LOG_INFO, "OutHeaders %s: 
%s\n",
  +env->l->jkLog(env, env->l, JK_LOG_DEBUG, "OutHeaders %s: 
%s\n",
 elts[i].key, elts[i].val);
   }
   }
  
  
  

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

DO NOT REPLY [Bug 5507] - Swapping sessions causes exceptions and it doesn't work with FileStore

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

Swapping sessions causes exceptions and it doesn't work with FileStore





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 13:01 ---

Currently when backup's of sessions expire they take out the session in RAM
along with them.  This patch fixes this problem.

Some details...  There are 2 types of sessions in the Store.

   1. Backed up Sessions (copies of sessions currently in RAM)

   2. Swapped out Sessions (not in RAM)

When backed up sessions expire, they should go away quietly.  When
swapped out sessions go away, they should do so like ones in RAM. (events
fire, etc...) Additionally, a backed up session expireing should not
effect a copy of that session currently in RAM (RAM holds a more recent
copy - when a RAM version is expired, its backup is always removed) So
sessions in the store, but not in RAM are swap outs.  Sessions in RAM
and in the store are backups.

This code "expires" swap outs, and "recycles" backups when they run out
of time.

Cheers,
-bob


Index: PersistentManagerBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java,v
retrieving revision 1.8
diff -u -r1.8 PersistentManagerBase.java
--- PersistentManagerBase.java  9 Jun 2002 02:19:43 -   1.8
+++ PersistentManagerBase.java  8 Jul 2002 12:53:04 -
@@ -551,6 +551,26 @@
 
 
 /**
+ * Return true, if the session id is loaded in memory
+ * otherwise false is returned
+ *
+ * @param id The session id for the session to be searched for
+ *
+ * @exception IOException if an input/output error occurs while
+ *  processing this request
+ */
+public boolean isLoaded( String id ){
+try {
+if ( super.findSession(id) != null )
+return true;
+} catch (IOException e) {
+log("checking isLoaded for id, " + id + ", "+e.getMessage(), e);
+}
+return false;
+}
+
+
+/**
  * Return the active Session, associated with this Manager, with the
  * specified session id (if any); otherwise return null.
  * This method checks the persistence store if persistence is enabled,
Index: StoreBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StoreBase.java,v
retrieving revision 1.5
diff -u -r1.5 StoreBase.java
--- StoreBase.java  9 Jun 2002 02:19:43 -   1.5
+++ StoreBase.java  8 Jul 2002 12:53:04 -
@@ -313,7 +313,13 @@
 int timeIdle = // Truncate, do not round up
 (int) ((timeNow - session.getLastAccessedTime()) / 1000L);
 if (timeIdle >= maxInactiveInterval) {
-session.expire();
+if ( ( (PersistentManagerBase) manager).isLoaded( keys[i] )) {
+// recycle old backup session
+session.recycle();
+} else {
+// expire swapped out session
+session.expire();
+}
 remove(session.getId());
 }
 } catch (IOException e) {

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

DO NOT REPLY [Bug 6048] - JDBC pool unavailable while using WARP connector

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

JDBC pool unavailable while using WARP connector





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 12:40 ---
I have ran into the same problem myself and I'm now trying to find a fix to it.
I could not find any solutions. David, you said that it might be from mod_webapp
adding slashes ('/') after the context name. This is probably not the case.

Snippet from my server.xml. 


  
  

  user
  XXX


  password
  XXX


  driverClassName
  oracle.jdbc.driver.OracleDriver


  driverName
  jdbc:oracle:thin:@HOST:PORT:SID

  
  
 

  (Yes, I've also tried auth="Container")

1. No Oracle pool is created, with 4.0.3 the 

Context initCtx = new InitialContext();
   Context envCtx  = (Context)initCtx.lookup("java:comp/env");
   ds=(DataSource)envCtx.lookup("jdbc/pool");

   ds would be null

   in 4.0.4, this is what I get:

javax.naming.NamingException: Exception creating DataSource: org.hsql.jdbcDriver

   ... something hard-coded in tyrex... Weird...

   And I got the same Exception if I would comment out the whole resource.

2. No parameters were passed.

   getServletContext().getInitParameter("Test") returns false.

It almost seems as if everything even slightly context-related would be thrown
into the trashbin. 

Suggestions?

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

Jk2 logging

[Mladen Turk]

Hi,

Recently there was a question on the Users List about log messages in
the Apache's error.log.
I've changed the INFO logging to get logged as notice instead of warning
(cause it may be misleading as the user reported).
Now, I propose to change the every occurrence of the following:

if( ch->mbean->debug > 0 )
env->l->jkLog(env, env->l, JK_LOG_INFO, 
to the :
if( ch->mbean->debug > 0 )
env->l->jkLog(env, env->l, JK_LOG_DEBUG, 

There are lots of places in the code where the second is used, but we
should be consistent across the entire source code.
I'll make the necessary commits, as soon I finish the macro.

MT.


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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache2 jk_logger_apache2.c

[mturk]

mturk   2002/07/08 05:13:51

  Modified:jk/native2/server/apache2 jk_logger_apache2.c
  Log:
  Change the JK_LOG_INFO to be logged as [notice] instead of [warning].
  This is much more intuitive for the context we are logging.
  
  Revision  ChangesPath
  1.27  +1 -1  
jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c
  
  Index: jk_logger_apache2.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache2/jk_logger_apache2.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_logger_apache2.c   12 Jun 2002 12:42:25 -  1.26
  +++ jk_logger_apache2.c   8 Jul 2002 12:13:51 -   1.27
  @@ -136,7 +136,7 @@
   if( level == JK_LOG_DEBUG_LEVEL ) {
   ap_log_error( file, line, APLOG_DEBUG | APLOG_NOERRNO, 0, s, buf);
   } else if( level == JK_LOG_INFO_LEVEL ) {
  -ap_log_error( file, line, APLOG_WARNING | APLOG_NOERRNO, 0, s, buf);
  +ap_log_error( file, line, APLOG_NOTICE | APLOG_NOERRNO, 0, s, buf);
   } else {
   ap_log_error( file, line, APLOG_ERR | APLOG_NOERRNO, 0, s, buf);
   }
  
  
  

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

Re: jspc - more patch

[Henri Gomez]

Quoting Henri Gomez <[EMAIL PROTECTED]>:

Oups, attachment missing :

> Hi to all,
> 
> A coworker found some more problems with jspc encoding and
> provided the attached patch for 3.3.1.
> 
> Thanks to take a look and apply (didn't have access to 
> cvs via ssh for now).
> 
> Regards
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 





Index: org/apache/jasper/compiler/CharDataGenerator.java
===
RCS file: 
c:/data/cvs/jakarta-tomcat-3.3.1/org/apache/jasper/compiler/CharDataGenerator.java,v
retrieving revision 1.1
diff -u -r1.1 CharDataGenerator.java
--- org/apache/jasper/compiler/CharDataGenerator.java   5 Jul 2002 10:20:22 -  
 1.1
+++ org/apache/jasper/compiler/CharDataGenerator.java   8 Jul 2002 11:07:35 -
@@ -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 );
+}
+}
 
 }
Index: org/apache/jasper/compiler/MappedCharDataGenerator.java
===
RCS file: 
c:/data/cvs/jakarta-tomcat-3.3.1/org/apache/jasper/compiler/MappedCharDataGenerator.java,v

retrieving revision 1.1
diff -u -r1.1 MappedCharDataGenerator.java
--- org/apache/jasper/compiler/MappedCharDataGenerator.java 5 Jul 2002 10:20:24 
-   1.1
+++ org/apache/jasper/compiler/MappedCharDataGenerator.java 8 Jul 2002 11:07:35 
+-
@@ -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: 

jspc - more patch

[Henri Gomez]

Hi to all,

A coworker found some more problems with jspc encoding and
provided the attached patch for 3.3.1.

Thanks to take a look and apply (didn't have access to 
cvs via ssh for now).

Regards

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

DO NOT REPLY [Bug 10423] - Premature packet header end

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

Premature packet header end





--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 10:01 ---
This bug happens to be a BIG problem if you are using netscape 4! 
By examining the headers, you can see that the HTTP response number (200) is not
included in the header that comes back by way of tomcat -> mod_webapp -> apache,
while it is included in the header straight from apache.

This results in netscape 4 displaying a pop-up error message 
   "Unknown status reply from server: 0!"

Apart from the error message the page loads up fine

using apache 2.0.39, tomcat 4.0.4

URL: http://cscw.cs.uec.ac.jp/index.html
Server response: HTTP/1.1 200 OK
Server: Apache/2.0.39 (Unix) mod_ssl/2.0.39 OpenSSL/0.9.6c DAV/2
mod_webapp/1.2.0-dev
Content-type: text/html
Content-encoding: null
Accept-Ranges: bytes
Last modified: Wed Jul 03 19:24:13 JST 2002
Content-length: 1150

URL: http://cscw.cs.uec.ac.jp/examples/servlets/index.html
Server response: HTTP/1.1 OK
Server: Apache/2.0.39 (Unix) mod_ssl/2.0.39 OpenSSL/0.9.6c DAV/2
mod_webapp/1.2.0-dev
Content-type: text/html
Content-encoding: null
Accept-Ranges: null
Last modified: Tue Jul 02 14:35:27 JST 2002
Content-length: 4988

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

Re: webapp- who handles static content: Tomcat or Apache

[Pier Fumagalli]

Bill Barker <[EMAIL PROTECTED]> wrote:

> 
> - Original Message -
> From: "Pier Fumagalli" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Sunday, July 07, 2002 4:04 PM
> Subject: Re: webapp- who handles static content: Tomcat or Apache
> 
> 
>> Sam Ewing <[EMAIL PROTECTED]> wrote:
>> 
>>> I read elsewhere that that mod_webapp fowarded
>>> requests for static resources to Tomcat (instead of
>>> Apache). Is this fixed? If not, are there workarounds?
>> 
>> It is forwarding requests, and it's definitely the last of my priorities
>> to "fix" (actually I don't even consider it a "bug" anymore).
>> 
> 
> I want some of what he is smoking ;-).

Cute... You can have some... Visit your local tobacconist.
Anyhow, you'll see my reasoning when the article gets published. Few other
folks having the same problems we do (very high loads + servlets) don't have
the same problem as well It's actually way easier and "better" (in terms
of what solutions it allows you to have), to move them away entirely from
the web application at all...

People doing GIFs HTMLs and CCS are (in our case), completely separate from
JSP/Servlet writers, so I don't even need to give them acceess to the web
application files... They can't overwrite or even "touch" any of the dynamic
content...

Pier

--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


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

Re: [VOTE] Apache Tomcat 5.0 Proposal

[Henri Gomez]

> As long as the interfaces don't change too much (especially, Container and
> Component, all the rest I don't care). We started out process of stripping
> out "for good" all the stuff distributed with TC4x, working on some new
> startup classes and so on (and looking over at the excellent work made by
> MinTC, and what Scarab is doing on that front)...
> 
> If you want to be flamed heavily check out 

Welcome to Jerry ;)

BTW, emulation is allways great till it didn't turn in flam wars.

I'll try to track both TC 5.0 and Jerry 


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

Re: DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs

[vicky kak]

Hi,
  I have already mailed you and informed you to remove
myself from your mailing list,but it seems no action
have been taken.I have mialed you on saturday but I
still got the posts on monday.Please remove my id from
your mailing list as I dont get the required mails.Hope
to unsubscribed now..
regards vicky

_
FindLaw - Free Case Law, Jobs, Library, Community
http://www.FindLaw.com
Get your FREE @JUSTICE.COM email!
http://mail.Justice.com

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

DO NOT REPLY [Bug 10541] - Content-length header should be automatically set for buffered Servlets/JSPs

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

Content-length header should be automatically set for buffered Servlets/JSPs

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-07-08 08:36 ---
Since both work fine and work transparently for a non broken HTTP/1.1 client,
the spec has no buisness specifying how the transport layer should behave. Also,
a number of intermediate protocols, like AJP, may not be able/willing to
implement the spec requirements.

I think the spec is broken here.

Coyote HTTP/1.1 does implement this requirement in some specific cases (many are
not implementable); the old HTTP connector will not be modified to fix it.

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

Re: [VOTE] Apache Tomcat 5.0 Proposal

[jean-frederic clere]

+1

Remy Maucherat wrote:
> After trying to address the concerns raised by the proposal draft, I 
> would like to call for a vote on it, now that the discussions have died 
> down.
> 
> 
> [ ] +1 I support the proposal, and will help implement it
> [ ] +0 I support the proposal
> [ ] -0 I do not support the proposal
> [ ] -1 I am against the proposal being implemented, because:
> 
> 
> 
> 
> The vote will run for one full week until July 9th. Users and other 
> contributors may vote, but only committers have binding votes.
> 
> Remy
> 
> 
> 
> 
> 
> 
> Proposal for Apache Tomcat 5.0
> ==
> 
> 
> 
> Introduction:
> 
> 
> This document is a proposal for the next major release of Apache Tomcat, 
> Apache Tomcat 5.0.
> 
> Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache
> Tomcat 4.1 architectures, by making them simpler, more flexible and more 
> modular, while at the same time adding support for the new Servlet API 2.4 and
> JSP 2.0 specifications, currently under development by the Java Community 
> Process.
> 
> The major goals for Apache Tomcat 5.0 are to:
> - improve scalability, reliability and performance over previous versions
> - have simpler/cleaner code, so more people can get involved
> - merge of the various ideas in 3.x and 4.x
> - get the community togheter
> - provide maximum modularity and compliance to the standards
> - make it easy to continue to maintain the existing codebases
> 
> Testing will occur to make sure the stated robustness and performance goals
> are met by Tomcat 5.0.
> 
> This proposal also tries to take advantage of the lessons learned while 
> optimizing and maintaining Tomcat.
> 
> Note: The development of Apache Tomcat 4.1.x will continue in parallel to the 
> implementation of this proposal.
> 
> 
> 
> General architecture:
> 
> 
> 
> An improved version of Coyote 1.0, called Coyote 2.0, will be used as 
> the Apache Tomcat 5.0 core.
> 
> Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under
> development in the jakarta-tomcat-connectors repository.
> 
> Coyote 1.0 includes:
> - Protocol handlers for AJP 1.3, HTTP/1.1 and JNI
> - Adapter for Tomcat 3.3
> - Adapter for Tomcat 4.x
> 
> Extensibility capabilities will be added to Coyote, as well as JMX management
> features, and if possible, addional protocol handlers (like WARP 1.0).
> 
> The Servlet API 2.4 specification will be implemented in a new version of 
> Catalina, called Catalina 2.0. A new version of the Coyote adapter will be
> written for it if mandated by API changes. Components which duplicate 
> functionality provided by Coyote will be removed, including the old connectors.
> 
> On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed 
> to Jasper 3, and is the proposed Jasper codebase. It provides many 
> improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including 
> good tag library handling, and near zero overhead when compared to 
> an equivalent hand coded servlet. Jasper 2 will also undergo additional 
> optimizations.
> 
> Apache Tomcat 5.0 will be made by default of the following components:
> - Coyote 2.0 - core
> - Catalina 2.0 - Servlet API 2.4 implementation
> - Jasper 2 - JSP 2.0 implementation
> 
> Many other configurations are also possible, and it is expected that advanced
> users take advantage of it to make Tomcat better suit their needs. It is also
> possible that new special purpose components, like a bare bones Servlet API 
> implementation, be developed to address the embedded market.
> 
> Due to the scope of this work, this initial Proposal only plans 
> the implementation and support of the default configuration described above.
> 
> 
> 
> Changes over Apache Tomcat 4.1.x:
> 
> 
> 
> A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x 
> codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code.
> 
> The following major changes and additions are proposed to the current Apche
> Tomcat code, and related dependencies:
> 
> A) Removal of the org.apache.catalina.connector.*
> 
> This package is currently deprecated in Tomcat 4.1 because of 
> its implementation inefficiencies, and general bad design. It is thus proposed
> that it is removed in Tomcat 5.0.
> 
> B) Addition of new loader code for the commons-daemon subproject
> 
> It is proposed that, in an attempt to solve the problems with using startup 
> scripts, as well as adding additional features oriented towards reliability
> (including the capability to restart Tomcat automatically should the JVM
> crashes or experience memory management related problems), the launcher code
> which will be developed as part of commons-daemon be adopted.
> This code will be based in part on the launcher code used for the Sun Web
> S

Re: Undefined Symbol when testing mod_webapp.so

[jean-frederic clere]

Adrian Wenden wrote:
> Hi
> 
>  
> 
> I have built apache 1.3.26 on RedHat 7.2. The server runs fine. I then
> built the webapp connector library. Here are the commands I used:
> 
>  
> 
> ./support/buildconf.sh
> 
> ./configure -with-apxs
> 
>  
> 
> When I tested the mod_webapp.so through apache it reported that the
> mod_webapp.so had a missing symbol pthread_sigmask.
> 
>  
> 
> So I rebuilt with the following commands:
> 
>  
> 
> ./support/buildconf.sh CC=/usr/sbin/cc CFLAGS=-DXTI_SUPPORT
> 
> ./configure -with-apr-lib=/var/downloads/APR/apr/.libs
> -with-apr-include=/var/downloads/APR/apr/include
> -with-apxs=/usr/sbin/apxs
> 
>  
> 
> Running the same test apache reports that the mod_webapp.so is missing
> apr_atomic_init
> 
>  
> 
> Can you help? 

Which APR are you using?

> 
>  
> 
> Best regards
> 
>  
> 
> Adrian
> 
>  
> 
> Adrian Wenden
> Director 
> Ape-IT 
> 
> 9 Cresswell Park 
> Blackheath Village 
> London 
> England 
> SE3 9RD 
> 
> Tel  +44 (0) 20 8318 5938 
> Fax +44 (0) 20 8318 1379 
> Web http://www.Ape-IT.com 
> 
> Ape-IT is the technical arm of Go Ape Ltd. We design, build and host
> e-commerce systems entirely in-house, based on Go Ape's leading edge
> Java architecture.
> 
>  
> 
> 




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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_iis.h

[mturk]

mturk   2002/07/08 00:48:47

  Modified:jk/native2/server/isapi jk_iis.h
  Log:
  Add the needed prototypes for the ThreadPool.
  
  Revision  ChangesPath
  1.10  +7 -0  jakarta-tomcat-connectors/jk/native2/server/isapi/jk_iis.h
  
  Index: jk_iis.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_iis.h,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jk_iis.h  6 Jul 2002 08:06:55 -   1.9
  +++ jk_iis.h  8 Jul 2002 07:48:47 -   1.10
  @@ -157,6 +157,13 @@
   DWORD bufsz,
   char  *def_val);
   
  +DWORD WINAPI HttpExtensionProcWorker(LPEXTENSION_CONTROL_BLOCK  lpEcb, 
  + jk_ws_service_t *service);
  +
  +int jk2_iis_init_pool(jk_env_t *env);
  +int jk2_iis_thread_pool(LPEXTENSION_CONTROL_BLOCK lpEcb);
  +int jk2_iis_close_pool(jk_env_t *env);
  +
   #ifdef __cplusplus
   }
   #endif /* __cplusplus */
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi isapi.dsp

[mturk]

mturk   2002/07/08 00:46:02

  Modified:jk/native2/server/isapi isapi.dsp
  Log:
  Add the jk_iis_thread_pool.c to the build.
  
  Revision  ChangesPath
  1.17  +4 -0  jakarta-tomcat-connectors/jk/native2/server/isapi/isapi.dsp
  
  Index: isapi.dsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/isapi.dsp,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- isapi.dsp 12 Jun 2002 23:26:35 -  1.16
  +++ isapi.dsp 8 Jul 2002 07:46:02 -   1.17
  @@ -145,6 +145,10 @@
   # End Source File
   # Begin Source File
   
  +SOURCE=.\jk_iis_thread_pool.c
  +# End Source File
  +# Begin Source File
  +
   SOURCE=..\..\jni\jk_jni_aprImpl.c
   # End Source File
   # Begin Source File
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c

[mturk]

mturk   2002/07/08 00:45:32

  Modified:jk/native2/server/isapi jk_isapi_plugin.c
  Log:
  Move the init to the GetFilterVersion, allowing p file authComplete
  config value.
  Needed changes for the ThreadPool.
  
  Revision  ChangesPath
  1.37  +160 -145  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- jk_isapi_plugin.c 8 Jul 2002 00:26:07 -   1.36
  +++ jk_isapi_plugin.c 8 Jul 2002 07:45:32 -   1.37
  @@ -86,6 +86,7 @@
   #define EXTENSION_URI_TAG   ("extensionUri")
   #define WORKERS_FILE_TAG("workersFile")
   #define USE_AUTH_COMP_TAG   ("authComplete")
  +#define THREAD_POOL_TAG ("threadPool")
   
   
   static char  file_name[_MAX_PATH];
  @@ -95,9 +96,10 @@
   static int   is_mapread = JK_FALSE;
   static int   was_inited = JK_FALSE;
   static int   auth_notification_flags = 0;
  +static int   use_auth_notification_flags = 0;
   
   static jk_workerEnv_t *workerEnv;
  -static apr_pool_t *jk_globalPool;
  +apr_pool_t *jk_globalPool;
   
   static char extension_uri[INTERNET_MAX_URL_LENGTH] = 
"/jakarta/isapi_redirector2.dll";
   static char worker_file[MAX_PATH * 2] = "";
  @@ -120,6 +122,10 @@
   static jk_env_t* jk2_create_config();
   static int get_auth_flags();
   
  +/*  ThreadPool support
  + *
  + */
  +int use_thread_pool = 0;
   
   static void write_error_response(PHTTP_FILTER_CONTEXT pfc,char *status,char * msg)
   {
  @@ -141,14 +147,58 @@
   pfc->WriteClient(pfc, msg, &len, 0);
   }
   
  +HANDLE jk2_starter_event;
  +HANDLE jk2_inited_event;
  +HANDLE jk2_starter_thread = NULL;
  +
  +DWORD WINAPI jk2_isapi_starter( LPVOID lpParam ) 
  +{
  +Sleep(1000);
  +
  +apr_initialize();
  +apr_pool_create( &jk_globalPool, NULL );
  +initialize_extension();
  +if (is_inited) {
  +if (init_jk(NULL))
  +is_mapread = JK_TRUE;
  +}
  +SetEvent(jk2_inited_event);
  +WaitForSingleObject(jk2_starter_event, INFINITE);
  +
  +if (is_inited) {
  +was_inited = JK_TRUE;
  +is_inited = JK_FALSE;
  +if (workerEnv) {
  +jk_env_t *env = workerEnv->globalEnv;
  +jk2_iis_close_pool(env);
  +workerEnv->close(env, workerEnv);
  +}
  +is_mapread = JK_FALSE;
  +}
  +apr_pool_destroy(jk_globalPool);
  +apr_terminate();
  +return 0; 
  +} 
   
   BOOL WINAPI GetFilterVersion(PHTTP_FILTER_VERSION pVer)
   {
   ULONG http_filter_revision = HTTP_FILTER_REVISION;
  +DWORD dwThreadId;
   
  +jk2_inited_event = CreateEvent(NULL, FALSE, FALSE, NULL);
  +jk2_starter_event = CreateEvent(NULL, FALSE, FALSE, NULL);
   
  -pVer->dwFilterVersion = pVer->dwServerFilterVersion;
  +jk2_starter_thread = CreateThread(NULL, 0,
  +  jk2_isapi_starter,
  +  NULL,
  +  0,
  +  &dwThreadId);
   
  +WaitForSingleObject(jk2_inited_event, INFINITE);
  +if (!is_inited || !is_mapread) {
  +return FALSE;
  +}
  +pVer->dwFilterVersion = pVer->dwServerFilterVersion;
   if (pVer->dwFilterVersion > http_filter_revision) {
   pVer->dwFilterVersion = http_filter_revision;
   }
  @@ -403,108 +453,109 @@
   return TRUE;
   }
   
  -DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK  lpEcb)
  +DWORD WINAPI HttpExtensionProcWorker(LPEXTENSION_CONTROL_BLOCK  lpEcb, 
  + jk_ws_service_t *service)
   {   
   DWORD rc = HSE_STATUS_ERROR;
   jk_env_t *env;
  -lpEcb->dwHttpStatusCode = HTTP_STATUS_SERVER_ERROR;
  +jk_ws_service_t sOnStack;
  +jk_ws_service_t *s;
  +char *worker_name;
  +char huge_buf[16 * 1024]; /* should be enough for all */
  +DWORD huge_buf_sz;
  +jk_worker_t *worker;
  +jk_pool_t *rPool=NULL;
  +int rc1;
   
  -if (!is_inited) {
  -initialize_extension();
  -}
  +if (service)
  +s = service;
  +else
  +s = &sOnStack;
   
  -/* Initialise jk */
  -if (is_inited && !is_mapread) {
  -char serverName[MAX_SERVERNAME];
  -DWORD dwLen = sizeof(serverName);
  -if (lpEcb->GetServerVariable(lpEcb->ConnID, SERVER_NAME, serverName, 
&dwLen)){
  -if (dwLen > 0) serverName[dwLen-1] = '\0';
  -if (init_jk(serverName))
  -is_mapread = JK_TRUE;
  -}
  -if (!is_mapread)
  -is_inited = JK_FALSE;
  +lpEcb->dwHttpStatusCode = HTTP_STATUS_SERVER_ERROR;
  +env = workerEnv->globalEnv->getEnv( w

cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_iis_thread_pool.c

[mturk]

mturk   2002/07/08 00:43:51

  Added:   jk/native2/server/isapi jk_iis_thread_pool.c
  Log:
  IIS Thread pool.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_iis_thread_pool.c
  
  Index: jk_iis_thread_pool.c
  ===
  /* = *
   *   *
   * The Apache Software License,  Version 1.1 *
   *   *
   *  Copyright (c) 1999-2002 The Apache Software Foundation.  *
   *   All rights reserved.*
   *   *
   * = *
   *   *
   * Redistribution and use in source and binary forms,  with or without modi- *
   * fication, are permitted provided that the following conditions are met:   *
   *   *
   * 1. Redistributions of source code  must retain the above copyright notice *
   *notice, this list of conditions and the following disclaimer.  *
   *   *
   * 2. Redistributions  in binary  form  must  reproduce the  above copyright *
   *notice,  this list of conditions  and the following  disclaimer in the *
   *documentation and/or other materials provided with the distribution.   *
   *   *
   * 3. The end-user documentation  included with the redistribution,  if any, *
   *must include the following acknowlegement: *
   *   *
   *   "This product includes  software developed  by the Apache  Software *
   *Foundation ."  *
   *   *
   *Alternately, this acknowlegement may appear in the software itself, if *
   *and wherever such third-party acknowlegements normally appear. *
   *   *
   * 4. The names  "The  Jakarta  Project",  "Jk",  and  "Apache  Software *
   *Foundation"  must not be used  to endorse or promote  products derived *
   *from this  software without  prior  written  permission.  For  written *
   *permission, please contact <[EMAIL PROTECTED]>.*
   *   *
   * 5. Products derived from this software may not be called "Apache" nor may *
   *"Apache" appear in their names without prior written permission of the *
   *Apache Software Foundation.*
   *   *
   * THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR IMPLIED WARRANTIES *
   * INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WARRANTIES OF MERCHANTABILITY *
   * AND FITNESS FOR  A PARTICULAR PURPOSE  ARE DISCLAIMED.  IN NO EVENT SHALL *
   * THE APACHE  SOFTWARE  FOUNDATION OR  ITS CONTRIBUTORS  BE LIABLE  FOR ANY *
   * DIRECT,  INDIRECT,   INCIDENTAL,  SPECIAL,  EXEMPLARY,  OR  CONSEQUENTIAL *
   * DAMAGES (INCLUDING,  BUT NOT LIMITED TO,  PROCUREMENT OF SUBSTITUTE GOODS *
   * OR SERVICES;  LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION) *
   * HOWEVER CAUSED AND  ON ANY  THEORY  OF  LIABILITY,  WHETHER IN  CONTRACT, *
   * STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN *
   * ANY  WAY  OUT OF  THE  USE OF  THIS  SOFTWARE,  EVEN  IF  ADVISED  OF THE *
   * POSSIBILITY OF SUCH DAMAGE.   *
   *   *
   * = *
   *   *
   * This software  consists of voluntary  contributions made  by many indivi- *
   * duals on behalf of the  Apache Software Foundation.  For more information *
   * on the Apache Software Foundation, please see .   *
   *   *
   * = */
  
  /***
   * Description: IIS Jk2 Threa