Invalid no-cache http headers

2003-02-28 Thread Dennis van den Berg
Since I already posted this to the user-mailing-list but did not get any usefull 
replies.
And because I think this is actually a development question.

Hi all,

I encountered problems with the newer Tomcat 4 versions.
There are caching-headers set on the response, in case of URL's with security 
constraints, which are not set in older Tomcat 4 versions versions. 

This results in 2 things;
- The user is not able to use the back-button anymore (This page has expired, in IE6 
anyway)
- When you send a file as an attachement to the browser the user gets an open/save 
dialog.
  When the user presses open, the file is first put into the cache and then opened (by 
IE6 anyway)
  So this results in an 'file not found' message, because caching is disabled.

In the following method in org.apache.catalina.authenticator.AuthenticatorBase:
public void invoke(Request request, Response response,
   ValveContext context)
throws IOException, ServletException {

I found the following code-fragment:
// Make sure that constrained resources are not cached by web proxies
// or browsers as caching can provide a security hole
if (disableProxyCaching  
!(((HttpServletRequest) hrequest.getRequest()).isSecure())) {
HttpServletResponse sresponse = 
(HttpServletResponse) response.getResponse();
sresponse.setHeader(Pragma, No-cache);
sresponse.setHeader(Cache-Control, no-cache);
sresponse.setDateHeader(Expires, 1);
}

I think this piece of code is the source of the problem.
When I read the specs for HTTP, I think I can conclude there are more applicable 
values for the Cache-Control header in this case. For example private or 
no-store.

Did anyone else encounter any problems of this kind, or did I overlook something?

Thanks for any replies,

Dennis


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



DO NOT REPLY [Bug 15576] - IllegalArgumentException during adding a cookie

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15576.
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=15576

IllegalArgumentException during adding a cookie





--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 09:06 ---
I have got the same problem. In my opinion this has to do with the cookie 
version. If you take a look inside the code at ServerCookie line 315, the
exception is thrown, if the cookie has the version 0. But the interface
javax.servlet.http.Cookie recomments to create a cookie of version 0 to ensure 
the best interoperability.
It seems that the coyote connector doesn't support cookies of version 0 any 
more?

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



RE: Default context as a war archive (bug?)

2003-02-28 Thread Jason Corley

What the last poster meant was put this in your server.xml:
 Context path= docBase=ROOT1.war debug=0/
It won't unpack the war I believe, but it should server pages
out of it.
Jason

-Original Message-
From:   Mingfai Ma [mailto:[EMAIL PROTECTED]
Sent:   Fri 2/28/2003 1:14 AM
To: Tomcat Developers List
Cc: 
Subject:RE: Default context as a war archive (bug?)
yes, that's exactly my point. it doesn't work.

1. ROOT1.war does extracted automatically to ROOT1/, so, it works in the
ROOT1 context, but not the default context.

2. I used a fresh copy of Tomcat 4.1.18 to try, if i delete the ROOT1/
directory, and deploy a ROOT1.war which is set as the default context, the
default context is not initialized. (notice that ROOT1.war is a zip of the
default ROOT/ and is renamed)

the problem can be repeated easily by the following steps:
i.  extract tomcat from zip or install by other means
ii. war the default ROOT/ directory, rename the war
iii.configure in server.xml to use the renamed war's filename without
extension as default context docbase
iv. start tomcat, go to html manager, the root context should be not
started, and cannot be started

Regards,
mingfai

 -Original Message-
 From: jakarta-pipon [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 28, 2003 4:31 AM
 To: Tomcat Developers List
 Subject: Re: Default context as a war archive (bug?)


  1. in server.xml: Context path= docBase=ROOT1 debug=0/
 ^
  ROOT1.war should work



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



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





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

[GUMP] Build Failure - jakarta-tomcat-5

2003-02-28 Thread bobh

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-02-28/jakarta-tomcat-5.html


Buildfile: build.xml

prepare-release:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib

deploy-static:

deploy:
 [echo] Target: Servlet API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr154/build

dist:
 [echo] Target: JSP API - Dist ...

prepare:

static:

compile:

examples:

javadoc:

jar:
 [copy] Copying 1 file to /home/rubys/jakarta/jakarta-servletapi-5/jsr152/build

dist:
 [echo] Target: Modeler - Dist ...

BUILD FAILED
file:///home/rubys/jakarta/jakarta-tomcat-5/build.xml:577: Basedir 
/usr/local/commons-modeler-1.1dev does not exist

Total time: 7 seconds

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



Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJasperLoader.java

2003-02-28 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:
kinman  2003/02/27 14:51:38

  Modified:jasper2/src/share/org/apache/jasper JspC.java
JspCompilationContext.java
   jasper2/src/share/org/apache/jasper/compiler Compiler.java
   jasper2/src/share/org/apache/jasper/servlet
JasperLoader.java
  Log:
  - Fixes to make Jspc work:
* Make sure the correct classloader is used.
* Mangle package names if they contain Java keywords.
Wonderful fix :) Everything works now !!

Hopefully, having JSPC as part of the build will allow avoiding nasty 
regressions.

Remy

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


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

2003-02-28 Thread remm
remm2003/02/28 02:49:06

  Modified:coyote/src/java/org/apache/coyote/tomcat5 CoyoteAdapter.java
  Log:
  - Fix NPE parsing cookies.
  
  Revision  ChangesPath
  1.11  +8 -5  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java
  
  Index: CoyoteAdapter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- CoyoteAdapter.java26 Feb 2003 19:33:04 -  1.10
  +++ CoyoteAdapter.java28 Feb 2003 10:49:06 -  1.11
  @@ -361,7 +361,10 @@
  scookie.getValue().toString());
   cookie.setPath(scookie.getPath().toString());
   cookie.setVersion(scookie.getVersion());
  -cookie.setDomain(scookie.getDomain().toString());
  +String domain = scookie.getDomain().toString();
  +if (domain != null) {
  +cookie.setDomain(scookie.getDomain().toString());
  +}
   cookies[i] = cookie;
   }
   
  
  
  

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



Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Henri Gomez
i guess server-admins want to distinguish between normal-server 
operation and network-errors.

currently the log is flooded with unimportant log-messages that are the 
result of bad error-detection (i hope, i can do better)
Without specifics add-ons on the protocol, I doubt you could
distinguiss between normal and error socket close..
Another point is that adding new message to protocol make
it incompatible with olders java implementations or with alternate
implementations (like jetty).


OK, but is there a handshake when mod_jk connects to tomcat?
mod_jk could receive a sub-version of the protocol to determine which 
extensions are available.
Features present in ajp13++ (ajp14) proposal but not in standard ajp13.
So sending unknown messages may crash old ajp13 implementations and
that's certainly something we don't want.
That was one of the reason why I started to think about an ajp13++
or ajp14.


I hope that ajp14 will do better.
I would also use JNI-workers, if mod_jk2 would be stable enough. I read 
that it didn't enjoy such extensive tests as mod_jk. Is this still true?
Still i'm worriing about apache-stability when using JNI-workers.
JK2 is less tested than JK and we need help here.
IMO spending times testing jk2 is more important than trying to resolve
this missing ajp13 feature (gracefull close).
- update the protocol paper (easy)

- update java side implementations (easy for JTC, dunno for Jetty,
  may be impossible for Tomcat 3.2.x).


Some protocols include version-numbers in their handshake, to overcome 
such problems. I agree with you, that the protocol should be some kind 
of KISS (keep it simply stupid)
ajp13++/ajp14 will be able to do this, I'll work when I could find some
times (no before 3 or 4 months ;(
But it will be available only in JK2.

- add native side code to trap child/thread handle the shutdown
  more gracefully.


that would be a much more cleaner sollution.
You could start studying where and how to trap this child/thread
kill/stop, will put gracefull exit code for ajp13++ here later.


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


Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Henri Gomez
Glenn Nielsen wrote:
Henri Gomez wrote:

Sven Köhler wrote:

When Apache will be closing connections at a high rate, you make Tomcat
spend precious cycle to catch exceptions, and so you'll slow tomcat also.
FYI, Apache close ajp13 connections each time it recycle/kill a child
and under heavy load on webserver, it happen very often.



I also dislike how mod_jk handles ajp socket connections.

There is another problem with how mod_jk handles the ajp connetor sockets.
That is the one to one mapping of apache child process to an ajp connector.
On an apache server that serves normal http requests you can end up with
many idle socket connections to Tomcat, and Tomcat will spawn many more
Connector threads than it needs to handle the request volume.
I have been toying with the idea of implementing a global worker socket
connection pool using APR for the Apache 2 version of mod_jk 1.2.
A global pool would allow the sockets to survive a child exit so they
don't have to be closed/reopened.  This would also reduce the number of
socket connections and Tomcat Connectors to the bare miniumum needed to
handle the request volume.
This would get rid of the normal operation exceptions and would not
require changing the AJP protocol.
This could also be done with mod_jk for Apache 1.3 if a dependency on
the APR were added.
In the end, I think this is the best solution.
+1, that's a great idea.



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


Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Henri Gomez
[EMAIL PROTECTED] wrote:
Why not restart work on mod_webapp?  I still wonder why it got dropped.
Because there was only one developper, Pier, with little help from JF Clere.

BTW, jk2 is here, it's modular and use solid foundations.

Why not works on it ?



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


Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Henri Gomez
Henri Gomez wrote:
[EMAIL PROTECTED] wrote:

Why not restart work on mod_webapp?  I still wonder why it got dropped.


Because there was only one developper, Pier, with little help from JF 
Clere.

BTW, jk2 is here, it's modular and use solid foundations.

Why not works on it ?
And JK2 support also Apache 1.3/IIS  ;-)



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


DO NOT REPLY [Bug 10789] - Setting DirectoryIndex of index.jsp does not get served by jk2

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10789.
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=10789

Setting DirectoryIndex of index.jsp does not get served by jk2





--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 12:20 ---
Using 1.2.2 worked fine.
will be good to put something like this in any place on the docs

Use only mod_jk 1.2 for Apache 1.3, with jk 2.x not all features will work

Thanks

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



DO NOT REPLY [Bug 17523] New: - Servlet can't getSession

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17523.
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=17523

Servlet can't getSession

   Summary: Servlet can't getSession
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Problem occur when I start tomcat (with securityManager) and try to 
run one servlet that uses Session, I got ClassNotFound Exception.

If I load one jsp page that uses session it works and then the session 
will work for the servlets too.

Why this ? 
The Class needed is inside 
server/lib/tomcat-coyote.jar

This lib are not available to applications. 

I don't know why it works for JSP as it is inside
common/lib/jasper-compiler.jar
common/lib/jasper-runtime.jar

And in my mind I have read in some place, the classes in common also 
can't access classes in server/lib.

Probably the solution for this is to include in
org/apache/catalina/startup/SecurityClassLoad.java
or
org/apache/coyote/tomcat4/CoyoteRequest.java

to load the class :
org/apache/coyote/tomcat4/CoyoteRequest$PrivilegedGetSession


I don't have here the correct environment to build Tomcat and
test one of this solutions.





Test Servlet
-
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class TS extends HttpServlet {



   public void doGet(HttpServletRequest request,
 HttpServletResponse response)
   throws ServletException, IOException {
   PrintWriter pw = new PrintWriter(response.getWriter());
   pw.println(pTeste);
   pw.println(p);
   pw.println(request.getSession(false));
   pw.println(p);
   pw.println(request.getSession(true));
   }
}



javax.servlet.ServletException: Invoker service() exception
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:524)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:180)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:98)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:176)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:172)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at

DO NOT REPLY [Bug 17504] - JDBCRealm start() opens but does not close connection.

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17504.
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=17504

JDBCRealm start() opens but does not close connection.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 14:33 ---
JDBCRealm synchronizes use of one db connection for all realm
authentications. There is no need to close the connection since
it is reused.

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



Re: Default context as a war archive (bug?)

2003-02-28 Thread jakarta-pipon
sorry i'm using
Context path= docBase=../server/webapps/ROOT1.war debug=0/
'cause if you leave the war in the $CATALINA_HOME/webapps, it won't work
fine. so i put in the webapps a root.xml with the resources declaration,
ecc., and a war in the server/webapps. it works. good luck.


- Original Message -
From: Jason Corley [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, February 28, 2003 7:19 AM
Subject: RE: Default context as a war archive (bug?)



What the last poster meant was put this in your server.xml:
 Context path= docBase=ROOT1.war debug=0/
It won't unpack the war I believe, but it should server pages
out of it.
Jason

-Original Message-
From: Mingfai Ma [mailto:[EMAIL PROTECTED]
Sent: Fri 2/28/2003 1:14 AM
To: Tomcat Developers List
Cc:
Subject: RE: Default context as a war archive (bug?)
yes, that's exactly my point. it doesn't work.

1. ROOT1.war does extracted automatically to ROOT1/, so, it works in the
ROOT1 context, but not the default context.

2. I used a fresh copy of Tomcat 4.1.18 to try, if i delete the ROOT1/
directory, and deploy a ROOT1.war which is set as the default context, the
default context is not initialized. (notice that ROOT1.war is a zip of the
default ROOT/ and is renamed)

the problem can be repeated easily by the following steps:
i. extract tomcat from zip or install by other means
ii. war the default ROOT/ directory, rename the war
iii. configure in server.xml to use the renamed war's filename without
extension as default context docbase
iv. start tomcat, go to html manager, the root context should be not
started, and cannot be started

Regards,
mingfai

 -Original Message-
 From: jakarta-pipon [mailto:[EMAIL PROTECTED]
 Sent: Friday, February 28, 2003 4:31 AM
 To: Tomcat Developers List
 Subject: Re: Default context as a war archive (bug?)


  1. in server.xml: Context path= docBase=ROOT1 debug=0/
 ^
  ROOT1.war should work



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



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












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


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



mod_jk 1.2 Apache 2.0 piped mod_jk logs

2003-02-28 Thread Glenn Nielsen
I have a patch which uses APR to implement logging for mod_jk 1.2
for Apache 2.0.  This update allows piped logs to be used.  This
allows you to pipe the mod_jk logs to external programs such as
apache's rotatelogs or cronolog.
I will commit this to CVS unless there are any objections. :-)

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: mod_jk 1.2 Apache 2.0 piped mod_jk logs

2003-02-28 Thread Henri Gomez
Glenn Nielsen wrote:
I have a patch which uses APR to implement logging for mod_jk 1.2
for Apache 2.0.  This update allows piped logs to be used.  This
allows you to pipe the mod_jk logs to external programs such as
apache's rotatelogs or cronolog.
I will commit this to CVS unless there are any objections. :-)
+1



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


Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Jeff Tulley
So, we had a problem trying to port mod_jk2 to NetWare, and that is why
we decided to stick with mod_jk.  Basically the problem was that mod_jk2
assumed that some data table that existed when Apache does its first
load will still be there when apache unloads mod_jk and reloads it. 
This is not the case on some OS platforms, so this code did not port
well at alll.

Is this still the case?

Jeff Tulley  ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] 2/28/03 3:56:59 AM 
[EMAIL PROTECTED] wrote:
 Why not restart work on mod_webapp?  I still wonder why it got
dropped.

Because there was only one developper, Pier, with little help from JF
Clere.

BTW, jk2 is here, it's modular and use solid foundations.

Why not works on it ?




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


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



cvs commit: jakarta-tomcat-connectors/jk/native/common jk_logger.h jk_util.c

2003-02-28 Thread glenn
glenn   2003/02/28 09:58:40

  Modified:jk/native/apache-2.0 mod_jk.c
   jk/native/common jk_logger.h jk_util.c
  Log:
  Use APR for Apache 2.0 mod_jk logging so that piped logs can be used
  
  Revision  ChangesPath
  1.66  +187 -55   jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.65
  retrieving revision 1.66
  diff -u -r1.65 -r1.66
  --- mod_jk.c  7 Jan 2003 01:27:11 -   1.65
  +++ mod_jk.c  28 Feb 2003 17:58:39 -  1.66
  @@ -72,6 +72,7 @@
   #include apr_lib.h
   #include apr_date.h
   #include apr_file_info.h
  +#include apr_file_io.h
   #include httpd.h
   #include http_config.h
   #include http_request.h
  @@ -109,6 +110,7 @@
   #include jk_service.h
   #include jk_worker.h
   #include jk_uri_worker_map.h
  +#include jk_logger.h
   
   #define JK_WORKER_ID(jakarta.worker)
   #define JK_HANDLER  (jakarta-servlet)
  @@ -127,7 +129,6 @@
   /* module MODULE_VAR_EXPORT jk_module; */
   AP_MODULE_DECLARE_DATA module jk_module;
   
  -
   typedef struct {
   
   /*
  @@ -136,6 +137,7 @@
   char *log_file;
   int  log_level;
   jk_logger_t *log;
  +apr_file_t *jklogfp;
   
   /*
* Worker stuff
  @@ -199,7 +201,7 @@
   
   static jk_logger_t * main_log = NULL;
   static jk_worker_env_t   worker_env;
  -
  +static apr_global_mutex_t *jk_log_lock = NULL;
   
   static int JK_METHOD ws_start_response(jk_ws_service_t *s,
  int status,
  @@ -313,8 +315,9 @@
   int long rv = OK;
   if (rv = ap_change_request_body_xlate(p-r, 65535, 65535)) /* turn off request 
body translation*/
   { 
  -ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, 
  - NULL, mod_jk: Error on ap_change_request_body_xlate, rc=%d 
\n, rv);
  +ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
  + mod_jk: Error on ap_change_request_body_xlate, rc=%d \n,
  + rv);
   return JK_FALSE;
   }
   #else
  @@ -382,12 +385,12 @@
   #ifdef AS400
   rc = ap_change_response_body_xlate(p-r, 65535, 65535); /* turn off 
response body translation*/
if(rc){
  -ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, 
  - NULL, mod_jk: Error on ap_change_response_body_xlate, 
rc=%d \n, rc);
  - return JK_FALSE; 
  +ap_log_error(APLOG_MARK, APLOG_STARTUP | APLOG_NOERRNO, 0, NULL,
  + mod_jk: Error on ap_change_response_body_xlate, rc=%d 
\n, rc);
  + return JK_FALSE;
   }
   #endif
  -
  +
   /* Debug - try to get around rwrite */
   while( ll  0 ) {
   size_t toSend=(llCHUNK_SIZE) ? CHUNK_SIZE : ll;
  @@ -858,9 +861,12 @@
   jk_server_conf_t *conf =
   (jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
   
  -/* we need an absolut path */
  -conf-log_file = ap_server_root_relative(cmd-pool,log_file);
  - 
  +/* we need an absolute path */
  +if (*log_file != '|' )
  +conf-log_file = ap_server_root_relative(cmd-pool,log_file);
  +else
  +conf-log_file = apr_pstrdup(cmd-pool, log_file);
  +
   if (conf-log_file == NULL)
   return JkLogFile file_name invalid;
   
  @@ -971,7 +977,7 @@
   }
   *s = 0;
   
  -jk_log(conf-log ? conf-log : main_log, JK_LOG_REQUEST, str);
  +jk_log(main_log, JK_LOG_REQUEST, str);
   }
   
   /*
  @@ -1651,7 +1657,6 @@
   {   
   const char   *worker_name;
   jk_server_conf_t *xconf;
  -jk_logger_t  *xl;
   jk_server_conf_t *conf;
   int  rc,dmt=1;
   
  @@ -1672,7 +1677,6 @@
   return DECLINED;
   
   worker_name = apr_table_get(r-notes, JK_WORKER_ID);
  -xl = xconf-log ? xconf-log : main_log;
   
   /* Set up r-read_chunked flags for chunked encoding, if present */
   if(rc = ap_setup_client_block(r, REQUEST_CHUNKED_DECHUNK)) {
  @@ -1690,22 +1694,21 @@
 I'm not sure how ). We also have a manual config directive that
 explicitely give control to us. */
 worker_name=  worker_env.first_worker;
  -  jk_log(xl, JK_LOG_DEBUG, 
  +  jk_log(main_log, JK_LOG_DEBUG, 
Manual configuration for %s %s %d\n,
r-uri, worker_env.first_worker, worker_env.num_of_workers); 
 } else {
  -  worker_name = map_uri_to_worker(xconf-uw_map, r-uri, 
  -  xconf-log ? xconf-log : main_log);
  +  

DO NOT REPLY [Bug 17390] - If jsp:text is provided an invalid body in the context of a JSP document, a translation error is not raised.

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17390.
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=17390

If jsp:text is provided an invalid body in the context of a JSP document, a 
translation error is not raised.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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



Re: [4.1.21] Stability rating

2003-02-28 Thread Hans Bergsten
Remy Maucherat wrote:
ballot
[X] Alpha
[ ] Beta
[ ] Stable (GA)
/ballot
The TagLibraryInfoImpl patch attached to bug 14302 is still not
applied, so JSPC fails with an NPE for any web app that contains
a tag library packaged as a JAR file (with the TLD in the JAR file).
Other than that, all my tests works okay.

Hans
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [4.1.21] Stability rating

2003-02-28 Thread Hans Bergsten
Actually, let's change that to Beta; it's just one bug after all,
even though it's a fairly important one.
Hans

Hans Bergsten wrote:
Remy Maucherat wrote:

ballot
[X] Alpha
[ ] Beta
[ ] Stable (GA)
/ballot


The TagLibraryInfoImpl patch attached to bug 14302 is still not
applied, so JSPC fails with an NPE for any web app that contains
a tag library packaged as a JAR file (with the TLD in the JAR file).
Other than that, all my tests works okay.

Hans


--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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

2003-02-28 Thread luehe
luehe   2003/02/28 12:12:26

  Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
  Log:
  Use correct error code
  
  Revision  ChangesPath
  1.67  +5 -7  
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.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- Parser.java   28 Feb 2003 00:12:41 -  1.66
  +++ Parser.java   28 Feb 2003 20:12:26 -  1.67
  @@ -1234,15 +1234,13 @@
parseForward(parent);
} else if (reader.matches(INVOKE_ACTION)) {
if (!isTagFile) {
  - err.jspError(reader.mark(),
  -  jsp.error.invalid.action.isnottagfile,
  + err.jspError(reader.mark(), jsp.error.action.isnottagfile,
 lt;jsp:invoke);
}
parseInvoke(parent);
} else if (reader.matches(DOBODY_ACTION)) {
if (!isTagFile) {
  - err.jspError(reader.mark(),
  -  jsp.error.invalid.action.isnottagfile,
  + err.jspError(reader.mark(), jsp.error.action.isnottagfile,
 lt;jsp:doBody);
}
parseDoBody(parent);
  
  
  

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



Multiple IN's in EJB-QL ?

2003-02-28 Thread Sherbahador Khurshid
Hi,
I need the EJB QL equivilant of the following SQL
[brief descr of the prob -   I have 5 tables
camp,a,b,c and d. a,b,c, and d are each related
to camp via a campid. Each of a,b,c and d also
have their own id's a_id,b_id,c_id and d_id
respectively. Given these id's (i.e. a_id,b_id...), 
I'd like to select the matching instances of
the camp table (since a,b,c and d are all related
to camp via camp_id)
]:

SELECT camp.* FROM camp,a,b,c,d
WHERE a.campid=camp.campid
AND WHERE b.campid=camp.campid
AND WHERE c.campid=camp.campid
AND WHERE d.campid=camp.campid
AND WHERE a.a_id=name
AND WHERE b.b_id=tel
AND WHERE c.c_id=greeting
AND WHERE d.d_id=514

1) would the EJB QL equivilant be :

SELECT DISTINCT OBJECT(camp)
FROM Campaign camp, IN (camp.a) AS ca,IN (camp.b) AS cb, IN (camp.c) AS cc,
IN (camp.d) AS cd
WHERE ca.a_id=?1
AND WHERE cb.b_id=?2
AND WHERE cc.c_id=?3
AND WHERE cd.d_id=?4

2) Or would the EJB QL equivilant be:

SELECT DISTINCT OBJECT(camp)
FROM Campaign camp, RestrictionA a,RestrictionB b,RestrictionC
c,RestrictionD d  
WHERE a.campid=camp.campid
AND WHERE b.campid=camp.campid
AND WHERE c.campid=camp.campid
AND WHERE d.campid=camp.campid
AND WHERE a.a_id=?1
AND WHERE b.b_id=?2
AND WHERE c.c_id=?3
AND WHERE d.d_id=?4

3) Or would the EJB QL equivilant be:
SELECT DISTINCT OBJECT(camp)
FROM Campaign camp
WHERE camp.a.a_id=?1
AND WHERE camp.b.b_id=?1
AND WHERE camp.c.c_id=?1
AND WHERE camp.d.d_id=?1

Psudo code for campBean class finder method:

campBean {
Collection findByConstraints(String a_id,String b_id,String c_id,String
d_id)
}


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



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

2003-02-28 Thread costin
costin  2003/02/28 12:36:52

  Modified:jk/native2/common jk_worker_status.c
  Log:
  Few fixes and changes to make parsing faster. Since : is used for port and type/name 
separator.
  I use | as delimiter.
  
  Revision  ChangesPath
  1.35  +14 -12jakarta-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.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- jk_worker_status.c28 Feb 2003 05:02:24 -  1.34
  +++ jk_worker_status.c28 Feb 2003 20:36:52 -  1.35
  @@ -432,10 +432,11 @@
   qryLen=strlen( cName );
   }
   if( qryLen 0 ) {
  -if( cName[strlen(cName)] == '*' ) {
  +if( cName[strlen(cName)-1] == '*' ) {
   printf(Exact match off %s\n, cName );
  -cName[strlen(cName)]='\0';
  +cName[strlen(cName)-1]='\0';
   exact=0;
  +qryLen--;
   }
   }
   for( i=0; i  env-_objects-size( env, env-_objects ); i++ ) {
  @@ -449,7 +450,7 @@
   continue;
   
   /* Prefix */
  -if( ! exact   qryLen != 0  strncmp( name, cName, qryLen )!= 0 )
  +if( (! exact)   qryLen != 0  strncmp( name, cName, qryLen )!= 0 )
   continue;
   
   /* Exact */
  @@ -458,15 +459,15 @@
   
   if( mbean==NULL ) 
   continue;
  -s-jkprintf(env, s, N:%s:%s\n, mbean-type, name);
  +s-jkprintf(env, s, N|%s|%s\n, mbean-type, name);
   
   while( getAtt != NULL  *getAtt != NULL  **getAtt!='\0' ) {
  -s-jkprintf(env, s, G:%s:%s\n, name, *getAtt);
  +s-jkprintf(env, s, G|%s|%s\n, name, *getAtt);
   getAtt++;
   }
   
   while( setAtt != NULL  *setAtt != NULL  **setAtt!='\0' ) {
  -s-jkprintf(env, s, S:%s:%s\n, name, *setAtt);
  +s-jkprintf(env, s, S|%s|%s\n, name, *setAtt);
   setAtt++;
   }
   
  @@ -491,10 +492,11 @@
   qryLen=strlen( cName );
   }
   if( qryLen 0 ) {
  -if( cName[strlen(cName)] == '*' ) {
  +if( cName[strlen(cName)-1] == '*' ) {
   printf(Exact match off %s\n, cName );
  -cName[strlen(cName)]='\0';
  +cName[strlen(cName)-1]='\0';
   exact=0;
  +qryLen--;
   }
   }
   for( i=0; i  env-_objects-size( env, env-_objects ); i++ ) {
  @@ -517,12 +519,12 @@
   
   if( mbean==NULL ) 
   continue;
  -s-jkprintf(env, s, P:%s:%s:%lp\n, mbean-type, name, mbean-object );
  +s-jkprintf(env, s, P|%s|%s|%lp\n, mbean-type, name, mbean-object );
   
   while( getAtt != NULL  *getAtt != NULL  **getAtt!='\0' ) {
   char *attName=*getAtt;
   char *val=mbean-getAttribute(env, mbean, *getAtt );
  -s-jkprintf(env, s, G:%s:%s:%s\n, name, *getAtt, (val==NULL)? NULL: 
val);
  +s-jkprintf(env, s, G|%s|%s|%s\n, name, *getAtt, (val==NULL)? NULL: 
val);
   getAtt++;
   }
   }
  @@ -554,7 +556,7 @@
   if( strcmp( name, cName ) == 0 
   mbean-getAttribute != NULL ) {
   void *result=mbean-getAttribute( env, mbean, attName );
  -s-jkprintf( env, s, OK:%s:%s, cName, attName );
  +s-jkprintf( env, s, OK|%s|%s, cName, attName );
   s-jkprintf( env, s, %s, result );
   return JK_OK;
   }
  @@ -596,7 +598,7 @@
   if( strcmp( name, cName ) == 0 
   mbean-setAttribute != NULL ) {
   int res=mbean-setAttribute( env, mbean, attName, attVal );
  -s-jkprintf( env, s, OK:%s:%s:%d, cName, attName, res );
  +s-jkprintf( env, s, OK|%s|%s|%d, cName, attName, res );
   return JK_OK;
   }
   }
  
  
  

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



Custom HostDeployer (Digester) and context config file encryption

2003-02-28 Thread Roytman, Alex
Hello,

I would like to be able to use custom Digester for my contexts. One of the reason is 
that we have tons of passwords in context xml files and I would much rather prefer to 
encrypt/decrypt entire file to encrypting/decrypting each password (which will mean I 
have to rewrite several JNDI resource factories). 
It would be nice to use a system property org.apache.catalina.core.HostDeployer.my 
context name (context specific) and org.apache.catalina.core.HostDeployer (tomcat 
wide)
to tell StandardHost to which deployer to delegate the job.
Alternatively it would be sufficient for me to have custom digester (which will 
naturally extend the default one). Any other solution (especially the one I can 
implement now and without altering tomcat source code) would be very welcome.

This is pretty urgent matter for us and I am very anxious to hear from you

Thank you in advance

Alex Roytman
Peace Technology, Inc.
301-206-9696 ext. 103 

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



cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java

2003-02-28 Thread costin
costin  2003/02/28 12:47:59

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  Reduce verbosity.
  
  Revision  ChangesPath
  1.35  +3 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- ChannelSocket.java17 Feb 2003 02:17:15 -  1.34
  +++ ChannelSocket.java28 Feb 2003 20:47:59 -  1.35
  @@ -420,7 +420,9 @@
   s.close();
   sSocket.close(); // XXX?
   } catch(Exception e) {
  -e.printStackTrace();
  +log.info(Error shutting down the channel  + port +   +
  +e.toString());
  +if( log.isDebugEnabled() ) log.debug(Trace, e);
   }
   }
   
  
  
  

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



DO NOT REPLY [Bug 17401] - Symbolic links not handled properly

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17401.
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=17401

Symbolic links not handled properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 OS/Version|HP-UX   |Solaris
   Platform|HP  |Sun



--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 20:51 ---
I ran into this too. I have an whatever.jsp who uses an applet ... PARAM 
NAME=code VALUE=sub/FrameCs.class PARAM NAME=codebase VALUE=. ...
Then in my tomcat directory like /xxx/tomcat4/webapps/mine I had a symbolic 
link to WEB-INF/classes/sub.  sub is my subdirectory package for class files. I 
would get a browser console error saying classNotFound or something like that. 
It could not find the applet class file to load it.  Then I tried moving 
the 'sub' directory up to 'mine' and linking up to it like ln -s ../../sub and 
that did not work either (giving a different error, maybe 505). So I have to 
have the directory and all the files in both places, and maintain duplicates :-(
This worked in tomcat 4.1.10 before I just upgraded.  [EMAIL PROTECTED]

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



cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ModJkMX.java

2003-02-28 Thread costin
costin  2003/02/28 12:51:03

  Added:   jk/java/org/apache/jk/common ModJkMX.java
  Log:
  Initial code for the jmx proxy.
  
  Setting is not yet implemented, and I get strange values with get - but
  getting metadata and registration is fine.
  
  Configure by adding:
   class.modjkmx=org.apache.
   modjkmx.webServerHost=localhost
   modjkmx.webServerPort=80
  
  Make sure jkstatus is enabled and mapped.
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java
  
  Index: ModJkMX.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/).
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names The Jakarta Project, Tomcat, and Apache Software
   *Foundation must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called Apache
   *nor may Apache appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * http://www.apache.org/.
   *
   * [Additional notices, if required by prior licensing conditions]
   *
   */
  package org.apache.jk.common;
  
  import java.io.IOException;
  import java.io.FileInputStream;
  import java.io.InputStream;
  import java.io.BufferedInputStream;
  import java.io.BufferedReader;
  import java.io.InputStreamReader;
  import java.net.URLConnection;
  import java.net.URL;
  import java.util.List;
  import java.util.StringTokenizer;
  import java.util.ArrayList;
  import java.util.HashMap;
  import javax.management.MBeanServer;
  import javax.management.AttributeNotFoundException;
  import javax.management.MBeanException;
  import javax.management.ReflectionException;
  import javax.management.Attribute;
  import javax.management.ObjectName;
  
  import org.apache.jk.core.JkHandler;
  import org.apache.jk.server.JkMain;
  import org.apache.commons.modeler.Registry;
  import org.apache.commons.modeler.BaseModelMBean;
  import org.apache.commons.modeler.ManagedBean;
  import org.apache.commons.modeler.AttributeInfo;
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogFactory;
  
  /**
   * A small mbean that will act as a proxy for mod_jk2
   *
   */
  public class ModJkMX extends JkHandler
  {
  private static Log log = LogFactory.getLog(ModJkMX.class);
  
  MBeanServer mserver;
  String webServerHost=localhost;
  int webServerPort=80;
  String statusPath=/jkstatus;
  String user;
  String pass;
  Registry reg;
  
  HashMap mbeans=new HashMap();
  long lastRefresh=0;
  long updateInterval=5000; // 5 sec - it's min time 

Re: [4.1.21] Stability rating

2003-02-28 Thread Kin-Man Chung
The patch you mentioned in 14302 was actually applied to TC5.

 Date: Fri, 28 Feb 2003 12:07:21 -0800
 From: Hans Bergsten [EMAIL PROTECTED]
 Subject: Re: [4.1.21] Stability rating
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Remy Maucherat wrote:
  ballot
  [X] Alpha
  [ ] Beta
  [ ] Stable (GA)
  /ballot
 
 The TagLibraryInfoImpl patch attached to bug 14302 is still not
 applied, so JSPC fails with an NPE for any web app that contains
 a tag library packaged as a JAR file (with the TLD in the JAR file).
 
 Other than that, all my tests works okay.
 
 Hans
 -- 
 Hans Bergsten[EMAIL PROTECTED]
 Gefion Software   http://www.gefionsoftware.com/
 Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
 Details athttp://TheJSPBook.com/
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


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



Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Costin Manolache
Sven Köhler wrote:

 There is another problem with how mod_jk handles the ajp connetor
 sockets. That is the one to one mapping of apache child process to an ajp
 connector. On an apache server that serves normal http requests you can
 end up with many idle socket connections to Tomcat, and Tomcat will spawn
 many more Connector threads than it needs to handle the request volume.
 
 Changing this, is much work, and it might get better with Apache 2.0 as
 it uses Threads.

I don't know any way to avoid this for apache1.3 - if we close the
connections the performance will drop. The next request can come on any of
the apache childs.


 I took a short look at the ajp13 protocol draft, and the design of the
 protocol is really simple, too simple.

There are few knwon problems with the protocol - both sides of jk2 are
designed to support multiple protocols and extensions. 


 I can't see any possibility to send idle-packets to prevent a connection
 from timing out. That's a basic requirement, but it seems, that nobody
 thought of it. It also doens't include a quit-command (quits the

What prevents you from sending idle packets ? Or adding a quit command ? 

You can implement both - either with new packet types or by using 
normal Ajp requests with some special URIs ( that will be handled by a jk 
handler or even by a servlet ).


 connection), but a shutdown-command (shuts down the servlet container,
 i think it's unused at the moment).

Again - both can be easily added, if anyone has an itch.


 so tomcat's connections will keep timing out, and i see no sollution for
 this with the current protocl design.

The protocol is a simple request/response - with apache initiating the
communication, and some twists to avoid some roundtrips. You can send any
type of packet - and do any kind of action.

The only change to the protocol that I think we should do is to replace
the marshalling with XDR. Besides that - we can add as many packets and 
messages as we want - it's just RPC.


 I cannot find a describtion of some kind of simple handshake in the
 draft i've found. so mod_jk is totally unaware of the server it's
 talking too.

Is there any handshake in the HTTP protocol ? 
Does anything in the current jk prevent you from adding any kind of
handshake you need ? 

There is one proposal ( made by Henri ) - that include capabilities
and version checking. I personally don't see the real need - in most
cases it is much easier to just configure this explicitely.


 I think, AJP needs a better design than AJP13.
 all i found about AJP14 shows, that it comes with more features, but
 doesn't give a damn on the basic-problems.

Again - ajp13 defines a marshalling protocol and the 3-4 messages that 
are needed for request processing. It is not an exclusive list - other
messages can be added.

In many cases simpler is better - HTTP is a very good proof of that. 
I don't see any good reason to make the ajp13 protocol any more complex 
than it is. 

I am perfectly fine with adding other message types via plugins ( Jk
handlers and mod_jk components ), but the simple and stable base 
protocol needs to remain stable.

Costin
 
 But AJP was flamed enough now! If we have enough ideas, we could write
 our own connector for Tomcat and a module for Apache HTTPD.
 Any volunteers ?




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



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

2003-02-28 Thread costin
costin  2003/02/28 13:55:49

  Modified:jk/native2/common jk_worker_status.c
  Log:
  Few more fixes.
  
  Revision  ChangesPath
  1.36  +5 -5  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.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- jk_worker_status.c28 Feb 2003 20:36:52 -  1.35
  +++ jk_worker_status.c28 Feb 2003 21:55:49 -  1.36
  @@ -536,7 +536,7 @@
  jk_ws_service_t *s)
   {
   char *cName=s-query_string + 4;
  -char *attName=rindex(cName, ':' );
  +char *attName=rindex(cName, '|' );
   int i;
   
   if( attName == NULL ) {
  @@ -561,7 +561,7 @@
   return JK_OK;
   }
   }
  -s-jkprintf( env, s, ERROR: mbean not found %s\n, cName );
  +s-jkprintf( env, s, ERROR|mbean not found|%s\n, cName );
   return JK_OK;
   }
   
  @@ -570,7 +570,7 @@
  jk_ws_service_t *s)
   {
   char *cName=s-query_string + 4;
  -char *attVal=rindex(cName, ':' );
  +char *attVal=rindex(cName, '|' );
   char *attName;
   int i;
   
  @@ -581,7 +581,7 @@
   *attVal='\0';
   attVal++;
   
  -attName=rindex( cName, ':' );
  +attName=rindex( cName, '|' );
   if( attName == NULL ) {
   s-jkprintf( env, s, ERROR: attribute name not found\n, cName);
   return JK_OK;
  @@ -602,7 +602,7 @@
   return JK_OK;
   }
   }
  -s-jkprintf( env, s, ERROR: mbean not found %s\n, cName );
  +s-jkprintf( env, s, ERROR|not found|%s|%s|%s\n, cName, attName, attVal );
   return JK_OK;
   }
   
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ModJkMX.java

2003-02-28 Thread costin
costin  2003/02/28 13:58:02

  Modified:jk/java/org/apache/jk/common ModJkMX.java
  Log:
  Few more fixes.
  
  Now both reading and writting works ( and metadata, of course ).
  It is a bit weird that we don't support anything but strings - but anything else
  would be painfull in C. Later we can extend it to override the types and convert.
  
  The only remaining issue before I cross this is adding getters and setters for
  more info on the C side.
  
  Revision  ChangesPath
  1.2   +20 -4 
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java
  
  Index: ModJkMX.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ModJkMX.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ModJkMX.java  28 Feb 2003 20:51:03 -  1.1
  +++ ModJkMX.java  28 Feb 2003 21:58:02 -  1.2
  @@ -188,6 +188,7 @@
   if( time - lastRefresh  updateInterval ) {
   return;
   }
  +log.debug( Refreshing attributes);
   lastRefresh=time;
   // connect to apache, get a list of mbeans
   BufferedReader is=getStream( dmp=*);
  @@ -197,16 +198,20 @@
   // for each mbean, create a proxy
   log.info(Read  + line);
   StringTokenizer st=new StringTokenizer(line,|);
  -if( st.countTokens()  5 ) continue;
  +if( st.countTokens()  4 ) continue;
   String key=st.nextToken();
   if( ! G.equals( key )) continue;
   String name=st.nextToken();
   String att=st.nextToken();
  -String val=st.nextToken(null);
  +String val=st.nextToken().substring(1);
   log.info(Token:  + key +  name:  + name +  att= + att +
val= + val);
   MBeanProxy proxy=(MBeanProxy)mbeans.get(name);
  -proxy.update(att, val);
  +if( proxy==null ) {
  +log.info( Unknown object  + name);
  +} else {
  +proxy.update(att, val);
  +}
   
   }
   } catch( Exception ex ) {
  @@ -301,6 +306,7 @@
   {
   log.info(Register  + name );
   int col=name.indexOf( ':' );
  +this.jkName=name;
   String type=name.substring(0, col );
   String id=name.substring(col+1);
   id=id.replace(':', '%');
  @@ -339,6 +345,7 @@
   }
   
   private void update( String name, String val ) {
  +log.debug( Updating  + jkName +   + name +   + val);
   atts.put( name, val);
   }
   
  @@ -353,7 +360,16 @@
   throws AttributeNotFoundException, MBeanException,
   ReflectionException
   {
  -
  +try {
  +// we support only string values
  +String val=(String)attribute.getValue();
  +String name=attribute.getName();
  +BufferedReader is=jkmx.getStream(set= + jkName + | +
  +name + | + val);
  +log.info( Setting  + jkName +   + name +  result  + 
is.readLine());
  +} catch( Exception ex ) {
  +throw new MBeanException(ex);
  +}
   }
   }
   }
  
  
  

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



Re: [4.1.21] Stability rating

2003-02-28 Thread Hans Bergsten
Kin-Man Chung wrote:
The patch you mentioned in 14302 was actually applied to TC5.
Right, thanks, but it needs to be applied to TC 4.1 as well. And this
is a stability ballot for TC 4.1 ;-)
Hans

Date: Fri, 28 Feb 2003 12:07:21 -0800
From: Hans Bergsten [EMAIL PROTECTED]
Subject: Re: [4.1.21] Stability rating
To: Tomcat Developers List [EMAIL PROTECTED]
Remy Maucherat wrote:

ballot
[X] Alpha
[ ] Beta
[ ] Stable (GA)
/ballot
The TagLibraryInfoImpl patch attached to bug 14302 is still not
applied, so JSPC fails with an NPE for any web app that contains
a tag library packaged as a JAR file (with the TLD in the JAR file).
Other than that, all my tests works okay.

Hans
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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


--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-tomcat-5 tomcat.nsi

2003-02-28 Thread remm
remm2003/02/28 14:11:40

  Modified:.tomcat.nsi
  Log:
  - Removed old laucher based link.
  
  Revision  ChangesPath
  1.26  +1 -6  jakarta-tomcat-5/tomcat.nsi
  
  Index: tomcat.nsi
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- tomcat.nsi19 Feb 2003 07:59:19 -  1.25
  +++ tomcat.nsi28 Feb 2003 22:11:40 -  1.26
  @@ -207,11 +207,6 @@
'//GT//Tomcat5' \
$INSTDIR\tomcat.ico 0 SW_SHOWNORMAL
   
  -  CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat (old).lnk \
  - $2\bin\java.exe \
  - '-Duser.dir=$INSTDIR\bin LauncherBootstrap -launchfile 
catalina.xml catalina start' \
  - $INSTDIR\tomcat.ico 0 SW_SHOWNORMAL
  -
   SectionEnd
   
   Section Examples SecExamples
  
  
  

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



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

2003-02-28 Thread kinman
kinman  2003/02/28 14:12:39

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  - Fix a typo for tag plugins.
  
  Revision  ChangesPath
  1.171 +4 -4  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.170
  retrieving revision 1.171
  diff -u -r1.170 -r1.171
  --- Generator.java27 Feb 2003 20:10:13 -  1.170
  +++ Generator.java28 Feb 2003 22:12:38 -  1.171
  @@ -1906,7 +1906,7 @@
Node.CustomTag tag = n.getTag();
   Node.JspAttribute[] attrs = tag.getJspAttributes();
   for (int i=0; iattrs.length; i++) {
  - if (attrs[i].getName().equals(n.getQName())) {
  + if (attrs[i].getName().equals(n.getName())) {
out.print(evaluateAttribute(getTagHandlerInfo(tag),
attrs[i], tag, null));
break;
  
  
  

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



DO NOT REPLY [Bug 11739] - Unable to locate TLDs based on uri element

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11739.
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=11739

Unable to locate TLDs based on uri element

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 23:03 ---


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

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



DO NOT REPLY [Bug 14200] - TLDs under WEB-INF are not scanned for URI mappings

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14200.
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=14200

TLDs under WEB-INF are not scanned for URI mappings

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 23:03 ---
*** Bug 11739 has been marked as a duplicate of this bug. ***

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



DO NOT REPLY [Bug 17504] - JDBCRealm start() opens but does not close connection.

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17504.
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=17504

JDBCRealm start() opens but does not close connection.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-02-28 23:04 ---
Yes, I understand why it is not a problem in the default implementation, but it
is a problem if you are extending this class, in my case, to use a connection pool. 
To prevent the connection from never being closed or returned to the pool, I
have to do some ugly workarounds in the extended class. It seems to me like just
closing the connection opened by start() would be an extremely simple change and
would have little risk of destabilizing anything.

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



Re: [4.1.21] Stability rating

2003-02-28 Thread Costin Manolache
Remy Maucherat wrote:

 ballot
 [ ] Alpha
 [ ] Beta
 [X] Stable (GA)
 /ballot
 
 Please vote (after testing the release, if possible ;).

It works for me. It would be nice to fix the jspc bugs tough.
I fixed a small regression in modeler(HEAD) so it can be used as drop-in
replacement ( if you have non-supported components - like other connectors -
to avoid the exceptions )


Any chance of making a build of jk(HEAD) to match the 4.1.21 and
have it included somewhere ? IMHO the extra measurements are pretty
nice - and the rest of the code is identical ( except the dependency 
on JMX, of course ). 


Costin




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



Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Sven Köhler
I took a short look at the ajp13 protocol draft, and the design of the
protocol is really simple, too simple.
There are few knwon problems with the protocol - both sides of jk2 are
designed to support multiple protocols and extensions. 
yes, but how? how can either client or server guess, which extensions 
the other side supports?

I can't see any possibility to send idle-packets to prevent a connection
from timing out. That's a basic requirement, but it seems, that nobody
thought of it. It also doens't include a quit-command (quits the
What prevents you from sending idle packets ? Or adding a quit command ? 
such are not part of ajp13, and adding them will surely brake 
compatibility to existing implementations as long as i can't determinte 
the supported features of the other side.

You can implement both - either with new packet types or by using 
normal Ajp requests with some special URIs ( that will be handled by a jk 
handler or even by a servlet ).
same reason as above

connection), but a shutdown-command (shuts down the servlet container,
i think it's unused at the moment).
Again - both can be easily added, if anyone has an itch.
Henri was protesting. I'm just repeating the Henri's doubts.

so tomcat's connections will keep timing out, and i see no sollution for
this with the current protocl design.
The protocol is a simple request/response - with apache initiating the
communication, and some twists to avoid some roundtrips. You can send any
type of packet - and do any kind of action.
yes, but what will the other side do if it receives an unsupported 
package? it might drop a note to the log, and that would result in a 
log-flood again :-(

I cannot find a describtion of some kind of simple handshake in the
draft i've found. so mod_jk is totally unaware of the server it's
talking too.
Is there any handshake in the HTTP protocol ? 
You forget, that HTTP is designed, to be a temporal connection. Without 
keep-alive and such (which were added to HTTP1.0), a HTTP connection 
doesn't survive longer than one request.
Sending headers and receiving them could also be interpreted, as a 
handshake.

A connection between apache and tomcat should survive a longer time, and 
delivers many requests.

Does anything in the current jk prevent you from adding any kind of
handshake you need ?  
umm ... yes?
Adding new messages is a bad bad thing. I agree with Henri's opinion in 
this case. It's just a shame, that the protocol isn't designed to be 
extended without loosing compatibility.

There is one proposal ( made by Henri ) - that include capabilities
and version checking. I personally don't see the real need - in most
cases it is much easier to just configure this explicitely.
So you really think, that many administrator cares about the 
documentation, or if they do understand it? You will have people mailing 
to the list, or just leaving the options as is, so mod_jk wouldn't 
take advantage of the features with default configuration.

I think, AJP needs a better design than AJP13.
all i found about AJP14 shows, that it comes with more features, but
doesn't give a damn on the basic-problems.
Again - ajp13 defines a marshalling protocol and the 3-4 messages that 
are needed for request processing. It is not an exclusive list - other
messages can be added.
So where can i find the final draft or something, that explains all 
that stuff?
After all you wrote, this draft should include a statement like 
additional message-type that can be added, and should be silently 
ignored, so every conformant implementaion reacts the same way.

In many cases simpler is better - HTTP is a very good proof of that. 
I don't see any good reason to make the ajp13 protocol any more complex 
than it is. 
proof?
hmm ...
- HTTP includes a version in each request and each response
- a client does not know which features the server supports
- = it blindly sends a request with a let's see what happens strategy
- ...
this should not apply for AJP13
- the versions or feature information could be exchange at the start of 
the connection, a connection should remain for some amount of time
- a client should know, if the server supports idle-message or 
quit-messages, the server should also know, which message the client may 
understand (for future enhancements and full compatibility)

I am perfectly fine with adding other message types via plugins ( Jk
handlers and mod_jk components ), but the simple and stable base 
protocol needs to remain stable.
why should it get unstable. how can a protocol get unstable?
the protocol isself should be simple, and an implementaion shouldn't get 
to complicated (if we have to much additions, or even conflicting 
additions, it's time for a new protocol)



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


DO NOT REPLY [Bug 17504] - JDBCRealm start() opens but does not close connection.

2003-02-28 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17504.
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=17504

JDBCRealm start() opens but does not close connection.





--- Additional Comments From [EMAIL PROTECTED]  2003-03-01 00:47 ---
Ooops. I meant to say call JDBCRealm.release(con) not close. In the standard
JDBCRealm implementation this will not do anything and is harmless, but for
sub-classes this allows us to return the connection to a pool.

So the change is just:

try {
release(open());
} catch (SQLException e) {
throw new LifecycleException(sm.getString(jdbcRealm.open), e);
}

I would be happy to do this change, but it is so trivial that it just seems
easier for a committer to do it.

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



Re: [4.1.21] Stability rating

2003-02-28 Thread Glenn Nielsen
Remy Maucherat wrote:
ballot
[ ] Alpha
[ ] Beta
[X] Stable (GA)
/ballot
Please vote (after testing the release, if possible ;).

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


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


Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Costin Manolache
Sven Köhler wrote:

I took a short look at the ajp13 protocol draft, and the design of the
protocol is really simple, too simple.
 
 There are few knwon problems with the protocol - both sides of jk2 are
 designed to support multiple protocols and extensions.
 
 yes, but how? how can either client or server guess, which extensions
 the other side supports?

By default - client and server assume the base protocol, ajp13.
You extend the server and the client by adding more components ( handlers,
etc). Then you configure those handlers.

Whoever configures the system is supposed to know what versions are
installed and what features he wants to use.

There is no reason to not add a FeatureNegotiationHandler and do whatever
complex thing you want. 

However there is a very simpler solution - both sides support JMX ( or the 
equivalent in C ). Listing all components is quite easy ( I already checked
in the proxy - so now all jk C components are visible in the JMX console ).
JMX is a registry for all the components, and each component supports a
certain API. 

If the other side doesn't support a feature - you'll just get an error,
which is the normal thing to happen. 

Can you be a bit more concrete and describe what exactly you want to do 
and can't because of the current architecture ? It is just a plain RPC
with some modifications for the part that is performance critical - any
handler you want can be implemented as a normal sync RPC call. I just can't
see what you would want to do and can't be done using normal and simple
RPC, but you could do with some complex negotiation.


I can't see any possibility to send idle-packets to prevent a connection
from timing out. That's a basic requirement, but it seems, that nobody
thought of it. It also doens't include a quit-command (quits the
 
 What prevents you from sending idle packets ? Or adding a quit command ?
 
 such are not part of ajp13, and adding them will surely brake
 compatibility to existing implementations as long as i can't determinte
 the supported features of the other side.

Yes - they are not part of ajp13. And yes - if you send those packets to 
an ajp13-only container, it'll not work. Think of Ajp13 request processing
as an interface - if you add more methods, you'll break existing
implementations. But that doesn't mean everything you want to do should 
be added to ajp13.

Don't confuse the Ajp13RequestProcessing API - the 3-4 messages that are 
used for sending request and response - with the whole jk2. It's just 
one interface. It is not concerned with discovery or anything else - just 
sending requests and receiving responses.

Besides - there is a huge number of features that could be implemented using
only the Ajp13RequestProcessing - just think about HTTP, which also has 
about 2-3 usefull messages ( 99% of the web uses GET and POST with one
header + body message in both sides ). On top of HTTP you can implement a
huge amount of features.

Do you want idle packets ? Send a AJP13 request to a URI /_jk/idlePing. 
Want a quit ? Send a request to /_jk/quit. Add whatever headers, user,
pass or other info you want. 

Both are reasonably easy to implement - the first will probably have less
overhead ( specialized packets ), the second will require the least amount
of work - and will be the easiest to maintain.

 
 You can implement both - either with new packet types or by using
 normal Ajp requests with some special URIs ( that will be handled by a jk
 handler or even by a servlet ).
 
 same reason as above

What do you mean ? Make a AjpRequest to
/_jk/ListAllTheBloatedFeaturesYouSupport and you can get any answer you
want. Why would this discovery be part of the request/response processing ?



 The protocol is a simple request/response - with apache initiating the
 communication, and some twists to avoid some roundtrips. You can send any
 type of packet - and do any kind of action.
 
 yes, but what will the other side do if it receives an unsupported
 package? it might drop a note to the log, and that would result in a
 log-flood again :-(

What will HTTP do if it receive an unuspported message ? Return an 
error and log a message. What should jk do ? 
Such mismatch happens only as a result of a config error - when you have 
a client asking for some unsupported server features.

If you implement the new message types as normal requests - you'll just 
get a 404 response code - and the normal access_log message.


I cannot find a describtion of some kind of simple handshake in the
draft i've found. so mod_jk is totally unaware of the server it's
talking too.
 
 Is there any handshake in the HTTP protocol ?
 
 You forget, that HTTP is designed, to be a temporal connection. Without
 keep-alive and such (which were added to HTTP1.0), a HTTP connection
 doesn't survive longer than one request.
 Sending headers and receiving them could also be interpreted, as a
 handshake.

And exactly the same send headers and receive headers is possible in
exactly 

Re: socket errors in catalina.out and mod_jk.log

2003-02-28 Thread Costin Manolache
Sorry, my previous mail got a bit long ( and a bit unfriendly :-)

The short version:
There are 3 ways to extend jk2:
1. With a completely different protocol module - marshalling and all low
level stuff. I'm +1 on such a thing if the new marshalling is a standard
one - and I think XDR is the right one ( i.e. simple enough, supported in
many places ). 

2. With new message types. Again - I'm +1 on a new message format for
the request, as it got a bit hairy. New messages can be added without
affecting the existing ones as long as both ends are proper configured.

3. On top of regular request/response. Almost everything related with auth,
pings, discovery, reconfiguration can be implemented by just using regular
Ajp13 requests - with a special URL. That is by far my favorite mechanism.
It also has the advantage that it can reuse other parts of tomcat - mapper, 
coyote actions, etc. I strongly believe that most features should be
implemented at this layer ( regardless of the request message or the wire 
protocol changes )

I believe the high level features like discovery, introspection,
negotitation, etc are mostly orthogonal - they can be implemented using 
normal protocol requests, without requiring anything special in the 
protocol. All you need is the basic request/response ( or message ).

I'm +1 on any change that is required in jk to better support protocol
abstraction and to support new features - but with a lot of care to 
avoid bloat and keep things as simple as is reasonable.

Costin



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



cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_env.h jk_map.h

2003-02-28 Thread costin
costin  2003/02/28 21:49:58

  Modified:jk/native2/common jk_channel_socket.c jk_endpoint.c jk_env.c
jk_map.c jk_uriEnv.c jk_worker_ajp13.c
jk_worker_lb.c jk_worker_status.c
   jk/native2/include jk_env.h jk_map.h
  Log:
  Added more getters and setters.
  
  A bit of refactoring for common methods ( the itoa and map concat ).
  
  The really interesting one is adding getters and setters to the endpoint ( to 
abstract
  the info from scoreboard ), I'm working on it.
  
  I split the status page in 4 - the config info doesn't change, there is no
  need to display it all the time, and the scoreboard page can grow and is the
  really interesting one from performance perspective.
  
  Revision  ChangesPath
  1.49  +19 -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.48
  retrieving revision 1.49
  diff -u -r1.48 -r1.49
  --- jk_channel_socket.c   28 Feb 2003 05:05:03 -  1.48
  +++ jk_channel_socket.c   1 Mar 2003 05:49:58 -   1.49
  @@ -113,10 +113,10 @@
   static int JK_METHOD jk2_channel_socket_close(jk_env_t *env, jk_channel_t *ch,
jk_endpoint_t *endpoint);
   
  -static char *jk2_channel_socket_multiValueInfo[]={group, NULL };
  -static char *jk2_channel_socket_getAttributeInfo[]={name, NULL };
  -static char *jk2_channel_socket_setAttributeInfo[]={host, port, route, 
lb_factor,
  -level, NULL };
  +static char *jk2_channel_socket_getAttributeInfo[]={host, port, keepalive, 
timeout, nodelay,
  +debug, disabled, NULL };
  +static char *jk2_channel_socket_setAttributeInfo[]={host, port, keepalive, 
timeout, nodelay,
  +debug, disabled, NULL };
   
   static int JK_METHOD jk2_channel_socket_setAttribute(jk_env_t *env,
  jk_bean_t *mbean,
  @@ -152,6 +152,20 @@
   
   if( strcmp( name, name )==0 ) {
   return  bean-name;
  +} else if( strcmp( host, name ) == 0 ) {
  +return socketInfo-host;
  +} else if( strcmp( port, name ) == 0 ) {
  +return jk2_env_itoa( env, socketInfo-port );
  +} else if( strcmp( nodelay, name ) == 0 ) {
  +return jk2_env_itoa( env, socketInfo-ndelay );
  +} else if( strcmp( keepalive, name ) == 0 ) {
  +return jk2_env_itoa( env, socketInfo-keepalive );
  +} else if( strcmp( timeout, name ) == 0 ) {
  +return jk2_env_itoa( env, socketInfo-timeout );
  +} else if( strcmp( debug, name ) == 0 ) {
  +return jk2_env_itoa( env, ch-mbean-debug );
  +} else if( strcmp( disabled, name ) == 0 ) {
  +return jk2_env_itoa( env, ch-mbean-disabled );
   }
   return NULL;
   }
  @@ -670,7 +684,7 @@
   result-init= jk2_channel_socket_init; 
   
   result-getAttributeInfo=jk2_channel_socket_getAttributeInfo;
  -result-multiValueInfo=jk2_channel_socket_multiValueInfo;
  +result-multiValueInfo=NULL;
   result-setAttributeInfo=jk2_channel_socket_setAttributeInfo;
   
   result-object= ch;
  
  
  
  1.23  +20 -1 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.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- jk_endpoint.c 4 Feb 2003 07:39:59 -   1.22
  +++ jk_endpoint.c 1 Mar 2003 05:49:58 -   1.23
  @@ -126,9 +126,26 @@
return JK_OK;
   }
   
  +static char *getAttInfo[]={ id, NULL };
  +
  +static void * JK_METHOD jk2_endpoint_getAttribute(jk_env_t *env, jk_bean_t *bean,
  +  char *name )
  +{
  +jk_endpoint_t *ep=(jk_endpoint_t *)bean-object;
  +
  +if( strcmp( name, id )==0 ) {
  +return  1;
  +} else if (strcmp(inheritGlobals, name) == 0) {
  +return ;
  +}
  +return NULL;
  +}
  +
  +
  +
   int JK_METHOD
   jk2_endpoint_factory( jk_env_t *env, jk_pool_t *pool,
  -  jk_bean_t *result,
  +  jk_bean_t *result,
 const char *type, const char *name)
   {
   jk_endpoint_t *e = (jk_endpoint_t *)pool-calloc(env, pool,
  @@ -162,6 +179,8 @@
   epId=atoi( result-localName );
   
   result-object = e;
  +result-getAttributeInfo=getAttInfo;
  +result-getAttribute=jk2_endpoint_getAttribute;
   e-mbean=result;
   
   e-workerEnv=env-getByName( env, workerEnv );
  

Jk MX proxy for mod_jk

2003-02-28 Thread Costin Manolache
I would really apreciate if someone could check how this works.

The steps are:
- compile 
- make sure /jkstatus is enabled and works
- configure jk2.properties: 

class.modjkmx=org.apache.jk.common.ModJkMX
modjkmx.webServerHost=localhost
modjkmx.webServerPort=80
mx.port=

- start apache
- make sure mx4j-tools.jar is in server/lib
- start tomcat

You should see in the jmx console a number of mbeans in the apache domain,
including URIs, workers, etc. Set should work ( try disabling the worker or
uri ).

I haven't tried the saving of the modified config

Costin


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



Re: [4.1.21] Stability rating

2003-02-28 Thread Remy Maucherat
Costin Manolache wrote:
Remy Maucherat wrote:


ballot
[ ] Alpha
[ ] Beta
[X] Stable (GA)
/ballot
Please vote (after testing the release, if possible ;).


It works for me. It would be nice to fix the jspc bugs tough.
I fixed a small regression in modeler(HEAD) so it can be used as drop-in
replacement ( if you have non-supported components - like other connectors -
to avoid the exceptions )
Good. For JspC, I think there are more urgent problems than the tag 
related problem, such as the mangling issues which just got fixed in 
Tomcat 5. That's why I didn't bother trying to apply whatever patch was 
needed for tags, knowing it would still be broken.

Any chance of making a build of jk(HEAD) to match the 4.1.21 and
have it included somewhere ? IMHO the extra measurements are pretty
nice - and the rest of the code is identical ( except the dependency 
on JMX, of course ). 
Looking at the diffs, it also uses thread with attributes, and stuff. 
That's a whole lot of stuff. Since I don't want to start having to test 
all combinations :-P
I'm not against upgrading to Coyote HEAD eventually.

Remy

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


Re: Jk MX proxy for mod_jk

2003-02-28 Thread Bill Barker
Once I have time to go through and patch the regression failures for Jk2,
maybe I'll test the new features.  Until then, I'm strictly a Jk1 person.

You could try posting this on the tomcat-user list.  There are a lot of
people there that are playing with Jk2.

- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, February 28, 2003 9:50 PM
Subject: Jk MX proxy for mod_jk


 I would really apreciate if someone could check how this works.

 The steps are:
 - compile
 - make sure /jkstatus is enabled and works
 - configure jk2.properties:

 class.modjkmx=org.apache.jk.common.ModJkMX
 modjkmx.webServerHost=localhost
 modjkmx.webServerPort=80
 mx.port=

 - start apache
 - make sure mx4j-tools.jar is in server/lib
 - start tomcat

 You should see in the jmx console a number of mbeans in the apache
domain,
 including URIs, workers, etc. Set should work ( try disabling the worker
or
 uri ).

 I haven't tried the saving of the modified config

 Costin


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



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