RE: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Constants.java Http11Connector.java InternalOutputBuffer.java
Hi Remy,
What's the final goal for Coyote ?
;)
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 10, 2002 5:58 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Constants.java Http11Connector.java InternalOutputBuffer.java
remm02/01/10 08:58:17
Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Connector.java InternalOutputBuffer.java
Log:
- Add support for sending acknoledgments.
- Implement reset.
Revision ChangesPath
1.6 +8 -1
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/htt
p11/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/
coyote/http11/Constants.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Constants.java 9 Jan 2002 23:29:29 - 1.5
+++ Constants.java 10 Jan 2002 16:58:17 - 1.6
@@ -141,7 +141,7 @@
/**
* Default HTTP header buffer size.
*/
-public static final int DEFAULT_HTTP_HEADER_BUFFER_SIZE
= 128 * 1024;
+public static final int DEFAULT_HTTP_HEADER_BUFFER_SIZE
= 128 * 1000;
/**
@@ -178,6 +178,13 @@
* HTTP/1.1.
*/
public static final String HTTP_11 = HTTP/1.1;
+
+
+/**
+ * Ack string when pipelining HTTP requests.
+ */
+public static final byte[] ACK =
+(new String(HTTP/1.1 100 Continue\r\n\r\n)).getBytes();
}
1.11 +17 -3
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/htt
p11/Http11Connector.java
Index: Http11Connector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/
coyote/http11/Http11Connector.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Http11Connector.java 10 Jan 2002 15:23:23 - 1.10
+++ Http11Connector.java 10 Jan 2002 16:58:17 - 1.11
@@ -163,6 +163,12 @@
/**
+ * HTTP/1.1 flag.
+ */
+protected boolean http11 = true;
+
+
+/**
* Content delimitator for the request (if false, the
connection will
* be closed at the end of the request).
*/
@@ -360,7 +366,13 @@
// Send a 100 status back if it makes sense
(response not committed
// yet, and client specified an expectation for
100-continue)
-// FIXME
+try {
+outputBuffer.sendAck();
+} catch (IOException e) {
+// Log the error, and set error flag
+e.printStackTrace();
+error = true;
+}
} else if (actionCode == ActionCode.ACTION_CLOSE) {
@@ -383,6 +395,8 @@
// Note: This must be called before the
response is committed
+outputBuffer.reset();
+
} else if (actionCode == ActionCode.ACTION_CUSTOM) {
// Do nothing
@@ -423,7 +437,7 @@
*/
protected void prepareRequest() {
-boolean http11 = true;
+http11 = true;
contentDelimitation = false;
MessageBytes protocolMB = request.protocol();
@@ -434,6 +448,7 @@
keepAlive = false;
} else {
// Unsupported protocol
+http11 = false;
error = true;
// Send 505; Unsupported HTTP version
response.setStatus(505);
@@ -541,7 +556,6 @@
*/
protected void prepareResponse() {
-boolean http11 = true;
boolean http09 = false;
contentDelimitation = false;
1.9 +28 -5
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/htt
p11/InternalOutputBuffer.java
Index: InternalOutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/
coyote/http11/InternalOutputBuffer.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- InternalOutputBuffer.java10 Jan 2002 12:53:50
- 1.8
+++ InternalOutputBuffer.java10 Jan 2002 16:58:17
- 1.9
@@ -226,8 +226,6 @@
*/
public void addFilter(OutputFilter filter) {
-// FIXME: Check for null ?
-
OutputFilter[] newFilterLibrary =
new
RE: nbio connector
In few days we'll have the jk2 working, so you can play with unix domain sockets - that should improve a bit the performance. There are few other optimizations there ( more agressive recycling, etc ) - and we really need help testing it and feedback. ( I have it working on my machine, but I'm still trying to figure how to deal with 4.0 class loaders - if I can't I'll just use the old mechanism ). Unix domain will be faster on systems running Apache and Tomcat on the same box, so faster network IO will still be fine for configuration with separate Webserver and Tomcat (security concerns or load-balancing) Regarding NBIO and Jk2 - I think the Channel abstraction could be enhanced to use poll() ( using APR ). Jk2 is really a whole new study for the good old mod_jk developpers, like many others I'm back to school Professor Costin ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4212] - How to configure Apache to serve static contents?
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=4212. 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=4212 How to configure Apache to serve static contents? [EMAIL PROTECTED] changed: What|Removed |Added Component|Other Connectors|WARP Connector -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Constants.java Http11Connector.java InternalOutputBuffer.java
Hi Remy, What's the final goal for Coyote ? ;) - It should be faster than the current HTTP/1.1 processor - It should address the HTTP/1.1 items marked as later in bugzilla - It should be maintainable - It should be easily testable - It uses j-t-c/util and should be GC friendly, at least when used standalone (without any adapter) - It should work with 4.0 and 4.1; I'll make it available as a module for 4.0.x to get some testing At the moment, I need to add: - support for input chunking (that's the hardest filter to write) - HTTP/0.9 support - some tweaks to the response processing (I think there are a few cases missing) - write more tests - and of course, the adapter for Catalina Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5759] - CGI servlet mapping by extension *.cgi does not work
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=5759. 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=5759 CGI servlet mapping by extension *.cgi does not work [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 02:54 --- The example that you gave: servlet-mapping servlet-namecgi/servlet-name url-pattern/cgi-bin/*/url-pattern /servlet-mapping is called path mapping. Extension mapping works like this: servlet-mapping servlet-namecgi/servlet-name url-pattern*.cgi/url-pattern /servlet-mapping You can read up on that in section SRV.11.2 of the servlet 2.3 specification. The mapping of the *.jsp extension to the JSP compiler is another example of extension mapping. While path mapping requires that all files of some functionality (e.g. CGI scripts) be located and isolated in a special directory hierarchy, extension mapping does not have this requirement. With extension mapping you can arrange your hierarchy however you like. The important point here is that with extension mapping you can arrange by package, e.g. have all files (static html, JSP, CGI) of a subpackage of your application reside in one directory. This is a definitive advantage if you want to deploy optional features which not every installation will get. Please read again my original problem description. You will find that this actually does NOT work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Add a new mime-type to web.xml
Hi, Would it be possible to add the following mime-mapping to the default web.xml file for future releases of Tomcat? mime-mapping extensionhtc/extension mime-typetext/plain/mime-type /mime-mapping It's for DHTML behaviors, which don't work without this mime type. It's a minor addition, and quite simple, so I hope someone can do this (maybe in time for the release of 4.0.2 ?) Thanks, Chris Brown -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
preferred method of handling empty form fields
Hi I use tomcat 3.2 on various platforms. My problem is this: when modifying a bean's properties through a jsp form, I would like a property to be cleared if the corresponding form field is cleared. The introspect(...) method in the JspRuntimeLibrary does not do this for me. I searched the archives and found that according to the spec, if a request parameter has no value, then the corresponding bean property is not to be modified (see http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html). Oh well. That still leaves me the problem of handling empty fields. I could 1) Go through the list of request parameters myself and clear the corresponding bean properties if parameters have no value. This feels like duplicating some of what the introspectHelper(...) method does. 2) Use javascript to record all empty fields to a hidden field at submit time. This is rather cumbersome and requires a little extra code in the form bean. I've used both but neither is very satisfying. So, to summarize, is there a preferred or recommended way of doing this that anybody knows of? Thanks Johan Hoogenboezem -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: preferred method of handling empty form fields
Hi Johan, I always create a reset() method within beans to circumvent this problem. It clears all fields that I don't want to hold any value during form processing. Mika - Original Message - From: Johan Hoogenboezem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 1:02 PM Subject: preferred method of handling empty form fields Hi I use tomcat 3.2 on various platforms. My problem is this: when modifying a bean's properties through a jsp form, I would like a property to be cleared if the corresponding form field is cleared. The introspect(...) method in the JspRuntimeLibrary does not do this for me. I searched the archives and found that according to the spec, if a request parameter has no value, then the corresponding bean property is not to be modified (see http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html). Oh well. That still leaves me the problem of handling empty fields. I could 1) Go through the list of request parameters myself and clear the corresponding bean properties if parameters have no value. This feels like duplicating some of what the introspectHelper(...) method does. 2) Use javascript to record all empty fields to a hidden field at submit time. This is rather cumbersome and requires a little extra code in the form bean. I've used both but neither is very satisfying. So, to summarize, is there a preferred or recommended way of doing this that anybody knows of? Thanks Johan Hoogenboezem -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: preferred method of handling empty form fields
Hi Mika Thanks for your reply. I can see how the reset() method can be useful. It is like the reset type button in html, no? Especially if you re-use the same form+bean to edit a lot of records. You don't want to carry over values from the previous record. However, I do not see how it will help to figure out which field on the form the user just cleared out (say, by selecting the text with her mouse and hitting delete before clicking the submit button) so that the corresponding bean property can also be cleared... -Original Message- From: Mika Goeckel [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 2:32 PM To: Tomcat Developers List Subject: Re: preferred method of handling empty form fields Hi Johan, I always create a reset() method within beans to circumvent this problem. It clears all fields that I don't want to hold any value during form processing. Mika - Original Message - From: Johan Hoogenboezem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 1:02 PM Subject: preferred method of handling empty form fields Hi I use tomcat 3.2 on various platforms. My problem is this: when modifying a bean's properties through a jsp form, I would like a property to be cleared if the corresponding form field is cleared. The introspect(...) method in the JspRuntimeLibrary does not do this for me. I searched the archives and found that according to the spec, if a request parameter has no value, then the corresponding bean property is not to be modified (see http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html). Oh well. That still leaves me the problem of handling empty fields. I could 1) Go through the list of request parameters myself and clear the corresponding bean properties if parameters have no value. This feels like duplicating some of what the introspectHelper(...) method does. 2) Use javascript to record all empty fields to a hidden field at submit time. This is rather cumbersome and requires a little extra code in the form bean. I've used both but neither is very satisfying. So, to summarize, is there a preferred or recommended way of doing this that anybody knows of? Thanks Johan Hoogenboezem -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: preferred method of handling empty form fields
Yep,
if you have a one2one mapping between form and bean, you can be sure that
all fields, that have no value will not be touched. As you have reset them
previously, you do something like
% bean.reset(); %
jsp:setProperty name=bean property=*/
So you clear all the fields and let them set afterwards. What is still the
same since you sent the bean's properties in that form to the user will get
into the bean again. What is cleared will remain cleared, because you have
called the reset() method. What has changed will change :-)
If you use a bean for more than one form, you will not be able to do it that
way. It is not really good style to have specialised reset() methods for the
different pages because you couple the bean to the layout of your pages. I
rather would recommend to explicitely set the properties then:
% if(request.getAttribute(yourProperty)!=null) {
bean.setYourProperty(request.getAttribute(yourProperty);
} else {
bean.setYourProperty(null);
} %
(Depends on the type your property has. In case of non-string you may have
to do some converting, anyway, to put much code into jsps is not a good
idea)
By the way, do you use a framework? Have a look into jakarta.struts, there
you may find more related stuff.
M.
- Original Message -
From: Johan Hoogenboezem [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 1:43 PM
Subject: RE: preferred method of handling empty form fields
Hi Mika
Thanks for your reply. I can see how the reset() method can be useful. It
is
like the reset type button in html, no? Especially if you re-use the same
form+bean to edit a lot of records. You don't want to carry over values
from
the previous record.
However, I do not see how it will help to figure out which field on the
form
the user just cleared out (say, by selecting the text with her mouse and
hitting delete before clicking the submit button) so that the
corresponding
bean property can also be cleared...
-Original Message-
From: Mika Goeckel [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 2:32 PM
To: Tomcat Developers List
Subject: Re: preferred method of handling empty form fields
Hi Johan,
I always create a reset() method within beans to circumvent this problem.
It
clears all fields that I don't want to hold any value during form
processing.
Mika
- Original Message -
From: Johan Hoogenboezem [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 1:02 PM
Subject: preferred method of handling empty form fields
Hi
I use tomcat 3.2 on various platforms.
My problem is this: when modifying a bean's properties through a jsp
form,
I
would like a property to be cleared if the corresponding form field is
cleared. The introspect(...) method in the JspRuntimeLibrary does not do
this for me.
I searched the archives and found that according to the spec, if a
request
parameter has no value, then the corresponding bean property is not to
be
modified (see
http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html).
Oh
well.
That still leaves me the problem of handling empty fields. I could
1) Go through the list of request parameters myself and clear the
corresponding bean properties if parameters have no value. This feels
like
duplicating some of what the introspectHelper(...) method does.
2) Use javascript to record all empty fields to a hidden field at submit
time. This is rather cumbersome and requires a little extra code in the
form
bean.
I've used both but neither is very satisfying.
So, to summarize, is there a preferred or recommended way of doing this
that
anybody knows of?
Thanks
Johan Hoogenboezem
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: preferred method of handling empty form fields
Excellent Mika!
Thanks, I would never have thought of that.
Regards
Johan
-Original Message-
From: Mika Goeckel [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 3:25 PM
To: Tomcat Developers List
Subject: Re: preferred method of handling empty form fields
Yep,
if you have a one2one mapping between form and bean, you can be sure that
all fields, that have no value will not be touched. As you have reset them
previously, you do something like
% bean.reset(); %
jsp:setProperty name=bean property=*/
So you clear all the fields and let them set afterwards. What is still the
same since you sent the bean's properties in that form to the user will get
into the bean again. What is cleared will remain cleared, because you have
called the reset() method. What has changed will change :-)
If you use a bean for more than one form, you will not be able to do it that
way. It is not really good style to have specialised reset() methods for the
different pages because you couple the bean to the layout of your pages. I
rather would recommend to explicitely set the properties then:
% if(request.getAttribute(yourProperty)!=null) {
bean.setYourProperty(request.getAttribute(yourProperty);
} else {
bean.setYourProperty(null);
} %
(Depends on the type your property has. In case of non-string you may have
to do some converting, anyway, to put much code into jsps is not a good
idea)
By the way, do you use a framework? Have a look into jakarta.struts, there
you may find more related stuff.
M.
- Original Message -
From: Johan Hoogenboezem [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 1:43 PM
Subject: RE: preferred method of handling empty form fields
Hi Mika
Thanks for your reply. I can see how the reset() method can be useful. It
is
like the reset type button in html, no? Especially if you re-use the same
form+bean to edit a lot of records. You don't want to carry over values
from
the previous record.
However, I do not see how it will help to figure out which field on the
form
the user just cleared out (say, by selecting the text with her mouse and
hitting delete before clicking the submit button) so that the
corresponding
bean property can also be cleared...
-Original Message-
From: Mika Goeckel [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 2:32 PM
To: Tomcat Developers List
Subject: Re: preferred method of handling empty form fields
Hi Johan,
I always create a reset() method within beans to circumvent this problem.
It
clears all fields that I don't want to hold any value during form
processing.
Mika
- Original Message -
From: Johan Hoogenboezem [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 1:02 PM
Subject: preferred method of handling empty form fields
Hi
I use tomcat 3.2 on various platforms.
My problem is this: when modifying a bean's properties through a jsp
form,
I
would like a property to be cleared if the corresponding form field is
cleared. The introspect(...) method in the JspRuntimeLibrary does not do
this for me.
I searched the archives and found that according to the spec, if a
request
parameter has no value, then the corresponding bean property is not to
be
modified (see
http://w4.metronet.com/~wjm/tomcat/2000/Jul/msg00481.html).
Oh
well.
That still leaves me the problem of handling empty fields. I could
1) Go through the list of request parameters myself and clear the
corresponding bean properties if parameters have no value. This feels
like
duplicating some of what the introspectHelper(...) method does.
2) Use javascript to record all empty fields to a hidden field at submit
time. This is rather cumbersome and requires a little extra code in the
form
bean.
I've used both but neither is very satisfying.
So, to summarize, is there a preferred or recommended way of doing this
that
anybody knows of?
Thanks
Johan Hoogenboezem
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: shell connector
On Thu, Jan 10, 2002 at 11:08:00AM -0800, Craig R. McClanahan wrote: I'm working on a webapp, for which I want to build (eventually) some shell access for administration purposes. I want administrators to be able to log into the application and perform maintenance through a UNIX like shell. I was thinking about writing this in Jython, but I wonder how I can do this best. Does this involve writing a new connector and if so, is it the best thing to do (and do others need it as well)? What's wrong with just using telnet or ssh, and running command line apps that update the *data* that underlies your web application? I don't see any reason that all data updates need to be made through Tomcat. Well, I prefer updates to be mode through one program for consistency. If anything changes, it's easier to maintain/update one application, than two. I'll give a small example of a use I see. To manage servlerts in my Tomcat instance I don't want to use the web (I'm a console guy and lynx is not my favourite webbrowser). I'd rather use a shell like tool to control the server. As in, use ls (or dir, whatever you prefer) to see all webapps and use small commands like `stop webapp'. So, even though I appreciate your answers and suggestions (I am a stubborn guy by nature :) I want to write it. I don't think I want to use HTTP as the underlying protocol (and no one said servlets should use HTTP). I'll flesh out the idea a bit more, see what's on the market (maybe JMX). Thanks so far :) armijn -- --- [EMAIL PROTECTED] | http://people.nl.linux.org/~armijn/ | Penguin Power --- http://nl.linux.org/ | Alles over Linux --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
I was just wondering why you do not want to use http as the underlying protocol. I do not believe it would be that difficult to write a shell application to utilize the management web app in tomcat. In fact with a little abstraction this could be rather simplistic. I may be totally off base here on what you are trying to do. I personally think this would be a good project and may even be interested in helping with it. I have some ideas on how to make it configurable so that as the manager adds new commands we do not have to change the code of the shell. Creighton Kirkendall -Original Message- From: Armijn Hemel [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 9:05 AM To: Tomcat Developers List Subject: Re: shell connector On Thu, Jan 10, 2002 at 11:08:00AM -0800, Craig R. McClanahan wrote: I'm working on a webapp, for which I want to build (eventually) some shell access for administration purposes. I want administrators to be able to log into the application and perform maintenance through a UNIX like shell. I was thinking about writing this in Jython, but I wonder how I can do this best. Does this involve writing a new connector and if so, is it the best thing to do (and do others need it as well)? What's wrong with just using telnet or ssh, and running command line apps that update the *data* that underlies your web application? I don't see any reason that all data updates need to be made through Tomcat. Well, I prefer updates to be mode through one program for consistency. If anything changes, it's easier to maintain/update one application, than two. I'll give a small example of a use I see. To manage servlerts in my Tomcat instance I don't want to use the web (I'm a console guy and lynx is not my favourite webbrowser). I'd rather use a shell like tool to control the server. As in, use ls (or dir, whatever you prefer) to see all webapps and use small commands like `stop webapp'. So, even though I appreciate your answers and suggestions (I am a stubborn guy by nature :) I want to write it. I don't think I want to use HTTP as the underlying protocol (and no one said servlets should use HTTP). I'll flesh out the idea a bit more, see what's on the market (maybe JMX). Thanks so far :) armijn -- --- [EMAIL PROTECTED] | http://people.nl.linux.org/~armijn/ | Penguin Power --- http://nl.linux.org/ | Alles over Linux --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5031] - Misconfiguration of service Tomcat-Apache in distributed files
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=5031. 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=5031 Misconfiguration of service Tomcat-Apache in distributed files [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 08:32 --- No that is 100% not correct: the appBase could be in WarpConnector. The Hosts are deployed by the WarpConfigurationHandler class. I will change the files. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
I'm working on something very similar, I have a management servlet that uses rhino to wrap important container objects as javascript objects. You can then send javascript function definitions and commands over HTTP. Basically this is the plumbing for a nice ant task that will deploy a webapp to a remote server. After building a WAR, Ant will transfer the WAR to a remote tomcat server, remove an existing context and clear it out of the filesystem if necessary, and then (re)deploy the WAR. This allows WAR deployment and redeployment to be part of a build process without needing access to the filesystem and, most importantly, without the need to restart Tomcat. The javascript infrastructure allows us to perform this task and others in the future in a consistent general way (and securely, through the use of authentication etc.). It makes it really really easy to define new adminstration tasks that can then be scripted remotely as part of a buildprocess, or through a utility tool. HOWEVER, I feel that the ability to make third party management-type servlets (i.e., ContainerServlets) is a bit broken currently. The ContainerServlet interface exists, however it only properly loads tomcat classes (from 'org.apache.catalina') correctly to have access to the various container object necessary for management (is this a design decision? if so, why publicize such an interface?). One could write their own ServletWrapper to load servlets in a context however they like, but the 'wrapperClass' property of a Context doesn't correctly induce a Context to use that Wrapper class instead of StandardWrapper. So for a third party to add a ContainerServlet to Tomcat, they must either change Tomcat source (undesirable, it would be nicer to be able to drop such a webapp in any Tomcat install) or reimplement a bunch of things (extend StandardContext and override 'createWrapper()', use that Context's className in a Context tag in server.xml, have that Context return the custom Wrapper, have that Wrapper use the catalina class loader for its servlets, etc.). If anyone thinks this is wrong and there is an easier way to do it, please let me know it would make my life easier :) -alan p l u m b d e s i g n alan newberger chief architect 157 chambers st ny ny 10007 p.212.381.0541 | f.212.285.8999 -Original Message- From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 11:08 AM To: 'Tomcat Developers List' Subject: RE: shell connector I was just wondering why you do not want to use http as the underlying protocol. I do not believe it would be that difficult to write a shell application to utilize the management web app in tomcat. In fact with a little abstraction this could be rather simplistic. I may be totally off base here on what you are trying to do. I personally think this would be a good project and may even be interested in helping with it. I have some ideas on how to make it configurable so that as the manager adds new commands we do not have to change the code of the shell. Creighton Kirkendall -Original Message- From: Armijn Hemel [mailto:[EMAIL PROTECTED]] Sent: Friday, January 11, 2002 9:05 AM To: Tomcat Developers List Subject: Re: shell connector On Thu, Jan 10, 2002 at 11:08:00AM -0800, Craig R. McClanahan wrote: I'm working on a webapp, for which I want to build (eventually) some shell access for administration purposes. I want administrators to be able to log into the application and perform maintenance through a UNIX like shell. I was thinking about writing this in Jython, but I wonder how I can do this best. Does this involve writing a new connector and if so, is it the best thing to do (and do others need it as well)? What's wrong with just using telnet or ssh, and running command line apps that update the *data* that underlies your web application? I don't see any reason that all data updates need to be made through Tomcat. Well, I prefer updates to be mode through one program for consistency. If anything changes, it's easier to maintain/update one application, than two. I'll give a small example of a use I see. To manage servlerts in my Tomcat instance I don't want to use the web (I'm a console guy and lynx is not my favourite webbrowser). I'd rather use a shell like tool to control the server. As in, use ls (or dir, whatever you prefer) to see all webapps and use small commands like `stop webapp'. So, even though I appreciate your answers and suggestions (I am a stubborn guy by nature :) I want to write it. I don't think I want to use HTTP as the underlying protocol (and no one said servlets should use HTTP). I'll flesh out the idea a bit more, see what's on the market (maybe JMX). Thanks so far :) armijn -- --- [EMAIL PROTECTED] |
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml
jfclere 02/01/11 08:39:14 Modified:catalina/src/conf Tag: tomcat_40_branch server.xml Log: The appBase should be in WarpConnector not in WarpEngine. It will apply for all virtual hosts deployed bu mod_webapp. PR: 5031 Revision ChangesPath No revision No revision 1.29.2.11 +2 -2 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.29.2.10 retrieving revision 1.29.2.11 diff -u -r1.29.2.10 -r1.29.2.11 --- server.xml26 Oct 2001 17:17:52 - 1.29.2.10 +++ server.xml11 Jan 2002 16:39:14 - 1.29.2.11 @@ -313,12 +313,12 @@ Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 - enableLookups=true + enableLookups=true appBase=webapps acceptCount=10 debug=0/ !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine - name=Apache debug=0 appBase=webapps + name=Apache debug=0 !-- Global logger unless overridden at lower levels -- Logger className=org.apache.catalina.logger.FileLogger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml
jfclere 02/01/11 08:43:58 Modified:catalina/src/conf server.xml Log: The appBase has be to in WarpConnector not it WarpEngine. PR: 5031 Revision ChangesPath 1.48 +2 -2 jakarta-tomcat-4.0/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- server.xml3 Jan 2002 02:01:55 - 1.47 +++ server.xml11 Jan 2002 16:43:58 - 1.48 @@ -326,12 +326,12 @@ Connector className=org.apache.catalina.connector.warp.WarpConnector port=8008 minProcessors=5 maxProcessors=75 - enableLookups=true + enableLookups=true appBase=webapps acceptCount=10 debug=0/ !-- Replace localhost with what your Apache ServerName is set to -- Engine className=org.apache.catalina.connector.warp.WarpEngine - name=Apache debug=0 appBase=webapps + name=Apache debug=0 !-- Global logger unless overridden at lower levels -- Logger className=org.apache.catalina.logger.FileLogger -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5741] - Apache goes into infinite loop in startup
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=5741. 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=5741 Apache goes into infinite loop in startup [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 08:55 --- That an old problem... The binary of mod_webapp are so old! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
I think that you could use the Rhino shell to be this shell. You would have
to write an initializer so that all of the command objects that you wanted
to work on where available. This would fit nicely with some of my ideas on
how to wrap different commands. You could simply use the HTTP connection
class in initialization to execute the commands. You would have to write a
script that ran the initializer before you return the shell to the user.
Bellow is some rhino code that I think could initialize the reload web app
command. This is vary basic it does not take authentication or error
handling into account. It is just to illustrate the point. I do not know
rhino that well, I just started playing today.
defineClass(java.net.URL);
defineClass(java.net.HTTPConnectionClass);
server=localhost:8080;
function reload(webapp) {
url=new URL(http://+server+/manager/reload?path=+webapp);
conn=url.OpenConnection();
// code to return the results.
// I think a wrapper for the connection
// object is probably required to handle
// exception well.
}
Creighton Kirkendall
-Original Message-
From: Alan Newberger [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 11:28 AM
To: Tomcat Developers List
Subject: RE: shell connector
I'm working on something very similar, I have a management servlet that uses
rhino to wrap important container objects as javascript objects. You can
then send javascript function definitions and commands over HTTP. Basically
this is the plumbing for a nice ant task that will deploy a webapp to a
remote server. After building a WAR, Ant will transfer the WAR to a remote
tomcat server, remove an existing context and clear it out of the filesystem
if necessary, and then (re)deploy the WAR. This allows WAR deployment and
redeployment to be part of a build process without needing access to the
filesystem and, most importantly, without the need to restart Tomcat. The
javascript infrastructure allows us to perform this task and others in the
future in a consistent general way (and securely, through the use of
authentication etc.). It makes it really really easy to define new
adminstration tasks that can then be scripted remotely as part of a
buildprocess, or through a utility tool.
HOWEVER, I feel that the ability to make third party management-type
servlets (i.e., ContainerServlets) is a bit broken currently. The
ContainerServlet interface exists, however it only properly loads tomcat
classes (from 'org.apache.catalina') correctly to have access to the various
container object necessary for management (is this a design decision? if so,
why publicize such an interface?). One could write their own ServletWrapper
to load servlets in a context however they like, but the 'wrapperClass'
property of a Context doesn't correctly induce a Context to use that Wrapper
class instead of StandardWrapper. So for a third party to add a
ContainerServlet to Tomcat, they must either change Tomcat source
(undesirable, it would be nicer to be able to drop such a webapp in any
Tomcat install) or reimplement a bunch of things (extend StandardContext and
override 'createWrapper()', use that Context's className in a Context tag in
server.xml, have that Context return the custom Wrapper, have that Wrapper
use the catalina class loader for its servlets, etc.). If anyone thinks
this is wrong and there is an easier way to do it, please let me know it
would make my life easier :)
-alan
p l u m b d e s i g n
alan newberger
chief architect
157 chambers st ny ny 10007
p.212.381.0541 | f.212.285.8999
-Original Message-
From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 11:08 AM
To: 'Tomcat Developers List'
Subject: RE: shell connector
I was just wondering why you do not want to use http as the underlying
protocol. I do not believe it would be that difficult to write a shell
application to utilize the management web app in tomcat. In fact with a
little abstraction this could be rather simplistic. I may be totally off
base here on what you are trying to do. I personally think this would be a
good project and may even be interested in helping with it. I have some
ideas on how to make it configurable so that as the manager adds new
commands we do not have to change the code of the shell.
Creighton Kirkendall
-Original Message-
From: Armijn Hemel [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 11, 2002 9:05 AM
To: Tomcat Developers List
Subject: Re: shell connector
On Thu, Jan 10, 2002 at 11:08:00AM -0800, Craig R. McClanahan wrote:
I'm working on a webapp, for which I want to build (eventually) some
shell
access for administration purposes. I want administrators to be able to
log into the application and perform maintenance through a UNIX like
shell.
I was thinking about writing this in Jython, but
DO NOT REPLY [Bug 5220] - Problem with mod_webapp.so getting confused with tomcat restart
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=5220. 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=5220 Problem with mod_webapp.so getting confused with tomcat restart [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
On Fri, 11 Jan 2002, Creighton Kirkendall wrote:
Date: Fri, 11 Jan 2002 12:39:08 -0500
From: Creighton Kirkendall [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
Subject: RE: shell connector
I think that you could use the Rhino shell to be this shell. You would have
to write an initializer so that all of the command objects that you wanted
to work on where available. This would fit nicely with some of my ideas on
how to wrap different commands. You could simply use the HTTP connection
class in initialization to execute the commands. You would have to write a
script that ran the initializer before you return the shell to the user.
Bellow is some rhino code that I think could initialize the reload web app
command. This is vary basic it does not take authentication or error
handling into account. It is just to illustrate the point. I do not know
rhino that well, I just started playing today.
defineClass(java.net.URL);
defineClass(java.net.HTTPConnectionClass);
server=localhost:8080;
function reload(webapp) {
url=new URL(http://+server+/manager/reload?path=+webapp);
conn=url.OpenConnection();
// code to return the results.
// I think a wrapper for the connection
// object is probably required to handle
// exception well.
}
Creighton Kirkendall
You might also be amused by some Ant tasks for all the basic Manager
servlet functions that I committed to the HEAD branch yesterday. Now you
can do things like install and reload apps directly from your build
scripts.
Docs are on the manager-howto.html page in last night's nightly build.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Performance comparison TC3.2/4.0
Please don't send big attachments to the list, the commits are enough to fill my yahoo mailbox :-) And please don't send xls/doc - it's painfull to read on linux. Costin On Fri, 11 Jan 2002, Lauer, Oliver wrote: Hi, we've made a performance comparison between TC3.2 and 4.0 and TC3.2 seems to be much faster. I've attached the measurement. Can somebody try to explain that or has a similar experience ? Thanx Oliver P.S. We would like to use 4.0 in production. AXA eSolutions GmbH AXA Konzern AG Germany Oliver Lauer Web Architect Wörthstraße 34 D-50668 Köln Germany Tel.: +49 221 148 31277 Fax: +49 221 148 43963 Mobil: +49 179 59 064 59 e-Mail: [EMAIL PROTECTED] _ Comparison_TC3.2-TC4.0.xls Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene Information nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach. Beachten Sie bitte, dass jede Form der unautorisierten Nutzung, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht gestattet ist.Diese Nachricht ist ausschliesslich fuer den bezeichneten Adressaten oder dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit dem Absender der E-Mail in Verbindung zu setzen. For legal and security reasons the information provided in this e-mail is not legally binding. Upon request we would be pleased to provide you with a legally binding confirmation in written form. Any form of unauthorised use, publication, reproduction, copying or disclosure of the content of this e-mail is not permitted. This message is exclusively for the person addressed or their representative. If you are not the intended recipient of this message and its contents, please notify the sender immediately. --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
From: Alan Newberger [mailto:[EMAIL PROTECTED]] I'm working on something very similar, I have a management servlet that uses rhino to wrap important container objects as javascript objects. You can then send javascript function definitions and commands over HTTP. Basically this is the plumbing for a nice ant task that will deploy a webapp to a remote server. After building a WAR, Ant will transfer the WAR to a remote tomcat server, remove an existing context and clear it out of the filesystem if necessary, and then (re)deploy the WAR. This allows WAR deployment and redeployment to be part of a build process without needing access to the filesystem and, most importantly, without the need to restart Tomcat. The javascript infrastructure allows us to perform this task and others in the future in a consistent general way (and securely, through the use of authentication etc.). It makes it really really easy to define new adminstration tasks that can then be scripted remotely as part of a buildprocess, or through a utility tool. I committed some Ant custom tasks yesterday that talk to Manager ... they might be useful to you. HOWEVER, I feel that the ability to make third party management-type servlets (i.e., ContainerServlets) is a bit broken currently. The ContainerServlet interface exists, however it only properly loads tomcat classes (from 'org.apache.catalina') correctly to have access to the various container object necessary for management (is this a design decision? Yes. if so, why publicize such an interface?). So that one can write servlet-based services that need access to Catalina internals. Existing examples include: * Manager servlet (needs to install, remove, and reload webapps) * Invoker servlet (needs to create new Wrapper instances on the fly) * Administration servlet (will provide web-based user interface for updating pretty much all of the things in server.xml). The third thing is in the admin webapp in the HEAD branch. One could write their own ServletWrapper to load servlets in a context however they like, but the 'wrapperClass' property of a Context doesn't correctly induce a Context to use that Wrapper class instead of StandardWrapper. So for a third party to add a ContainerServlet to Tomcat, they must either change Tomcat source (undesirable, it would be nicer to be able to drop such a webapp in any Tomcat install) or reimplement a bunch of things (extend StandardContext and override 'createWrapper()', use that Context's className in a Context tag in server.xml, have that Context return the custom Wrapper, have that Wrapper use the catalina class loader for its servlets, etc.). If anyone thinks this is wrong and there is an easier way to do it, please let me know it would make my life easier :) In order to execute a ContainerServlet that has access to the internals of Tomcat 4, the following rules must all be followed: * Your servlet must implement the org.apache.catalina.ContainerServlet interface. * Your servlet, and all the code it depends on, must be loaded from the server classloader. That means it needs to be installed as unpacked classes under $CATALINA_HOME/server/classes or in JAR files in $CATALINA_HOME/server/lib. (Classes in common/classes and common/lib are also visible to these components.) No changes to Tomcat code, or to standard server.xml settings, are required. Trying to load a Container servlet in a standard webapp will fail, because the org.apache.catalina.* classes cannot be loaded through the webapp class loader (for security reasons). -alan Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: nbio connector
On Fri, 11 Jan 2002, GOMEZ Henri wrote: Unix domain will be faster on systems running Apache and Tomcat on the same box, so faster network IO will still be fine for configuration with separate Webserver and Tomcat (security concerns or load-balancing) Of course, different issues. For 'lb' you have an extra layer of scalability - you can add more workers to better handle the load. Assuming a normal case, with servlets doing something besides helloworld, the benefits for NBIO on lb will remain small. As I said, I'm +1 on NBIO ( and I love the new java.nio package ), not because of possible improvements on tomcat's performance but because it's cool and the right ( or better ) way to do io. Regarding NBIO and Jk2 - I think the Channel abstraction could be enhanced to use poll() ( using APR ). Jk2 is really a whole new study for the good old mod_jk developpers, What I tried to do is make it easier to read and cleaner - for new and future 'old mod_jk developers'. There is a big change in code organization - but if anyone feels the code is harder to read and maintain then we need to start over again. I personally believe it's going in the right direction, so I'll continue moving. BTW, the new configuration ( based on Location instead of JkMount and without workers.properties ) needs review and feedback. ( the old stuff should still work, but I would like it deprecated ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: shell connector
thanks for your reply, I still feel there is a problem with ContainerServlets from arbitrary packages even when placed in $CATALINA_HOME/server/lib, see below... From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I committed some Ant custom tasks yesterday that talk to Manager ... they might be useful to you. I'll check them out, thanks. So that one can write servlet-based services that need access to Catalina internals. Existing examples include: * Manager servlet (needs to install, remove, and reload webapps) * Invoker servlet (needs to create new Wrapper instances on the fly) * Administration servlet (will provide web-based user interface for updating pretty much all of the things in server.xml). The third thing is in the admin webapp in the HEAD branch. That also sounds really useful, I'm going to have to take a close look at the HEAD branch :) Hopefully it's capable of persisting changes back into server.xml... In order to execute a ContainerServlet that has access to the internals of Tomcat 4, the following rules must all be followed: * Your servlet must implement the org.apache.catalina.ContainerServlet interface. * Your servlet, and all the code it depends on, must be loaded from the server classloader. That means it needs to be installed as unpacked classes under $CATALINA_HOME/server/classes or in JAR files in $CATALINA_HOME/server/lib. (Classes in common/classes and common/lib are also visible to these components.) No changes to Tomcat code, or to standard server.xml settings, are required. IF a servlet which implements ContainerServlet is loaded by the Catalina class loader, everything will work fine, i.e. it will have its 'setWrapper()' command called by StandardWrapper.load(). The problem is in the way StandardWrapper decides which classloader to use to load the servlet. It uses its private 'isContainerServlet(string)' method, which only looks at the String representation of the className and checks if it starts with 'org.apache.catalina'. So, if I have a servlet implementing ContainerServlet in some package, say 'com.foo.servlets', and put it in a jar $CATALINA_HOME/server/lib, and create some webapp with a web.xml with com.foo.servlets.SomeContainerServlet as a 'server-class' for a servlet, things will still fail. The StandardWrapper.isContainerServlet(string classname) method will return false, so the StandardWrapper.load() method will try to load the class from the webapp classloader, which of course will not find the class since it is not in the webapp classpath. You can put the com.foo.servlets.SomeContainerServlet in the common/lib folder and it will load correctly, but things will break because no catalina classes will be visible to it (an object instance cannot see other objects loaded in _child_ classloaders, only _parent_ classloaders). The solution to this isn't trivial -- you want all ContainerServlets to be loaded in the catalina classloader, but how do you know whether a servlet is a ContainerServlet by its classname alone, before actually loading it and doing something like 'instanceof' or 'isAssignableFrom()'? I'm sure this was why the StandardWrapper.isContainerServlet() method was written but it just doesn't do the right thing. I think the way to a nicer solution is through the 'privileged' attribute for a Context in servlet.xml (evaluated in ServletWrapper via the isServletAllowed() function). I suggest that if a Context is designated as privileged, the context's wrapper should attempt to load servlets via the catalina classloader. If the class isn't found, catch the exception and attempt to load it via the webapp classloader. If the class is loaded, check if it implements ContainerServlet; if so, call setWrapper() on it and continue, if not destroy the class object and attempt to load it in the webapp classloader. This is a bit more expensive way of loading classes than what is done now, but if only performed in Contexts marked 'privileged', most Context will be unaffected and privileged Contexts would actually work :) I'm fairly sure I'm right about this, I've read the code pretty carefully and tested out the above behavior (i.e. I've previously tried doing the two things you outline as necessary above and things failed, it was a mystery until I delved into StandardWrapper source). I'd be happy to code up these proposed changes into StandardWrapper if you're interested. -alan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 4.0.2 b multibyte issue.
Craig et.al. Recently I posted a vague question w.r.t. Multi-byte support in tomcat 4.0.2. Somewhat similar to the oracle at delphi, by asking a general question, I got a general answer. I now have a specific case where there appears to be a problem with multi-byte support in the latest tomcat. In the attached jsp, try cutting and pasting the double-byte chinese character displayed by the browser into the input field and hit the submit button. You should see that the character does not get displayed correctly. Is this a usage problem on my part or some problem with the character encoding? It appears to indicate that the somehow the byte stream is not being interpreted properly by tomcat. -Thom -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5814] New: - 401 error code could not be populated by error-page tag
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=5814. 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=5814 401 error code could not be populated by error-page tag Summary: 401 error code could not be populated by error-page tag Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] error-page in web.xml error-page error-code401/error-code location/401.jsp/location /error-page get exception when authentication failed. process.invoke java.lang.NullPointerException at org.apache.catalina.valves.ErrorDispatcherValve.status (ErrorDispatcherValve.java:291) at org.aapche.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:180) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5815] New: - Fatal error in Jakarta Tomcat service for NT
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=5815. 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=5815 Fatal error in Jakarta Tomcat service for NT Summary: Fatal error in Jakarta Tomcat service for NT Product: Tomcat 4 Version: 4.0 Beta 7 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After installation of Tomcat on NT4, the Jakart Tomcat service fails to load. It causes the following error when trying to start the service: Could not start the Jakarta Tomcat service on hostname. Error 2140: An internal Windows NT error occurred. An inspection of the event log showed that Tomcat failed to start the JVM. This led me to the registry, where I discovered the following: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Jakarta Tomcat\Parameters: JVM Library=C:\Program JVM Option Number 0=Files\Javasoft\jdk1.3.1\jre\bin\hotspot\jvm.dll As you can see, the installation crapped out on the space between Program Files. As I was not 100% sure about the second parameter, I fixed both to say the same thing: JVM Library=C:\Program Files\Javasoft\jdk1.3.1\jre\bin\hotspot\jvm.dll JVM Option Number 0=C:\Program Files\Javasoft\jdk1.3.1\jre\bin\hotspot\jvm.dll This fixed the problem. So, if you haven't done so already, you want to take a look at the installation script and correct the problem. -David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5820] New: - Undocumented restriction on inoking manager webapp
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=5820. 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=5820 Undocumented restriction on inoking manager webapp Summary: Undocumented restriction on inoking manager webapp Product: Tomcat 4 Version: 4.0.1 Final Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The ManagerServlet prevents invokation via the invoker, viz: ...snip... Dispatch Problem: javax.servlet.UnavailableException: Cannot invoke manager servlet through invoker at org.apache.catalina.servlets.ManagerServlet.doGet (ManagerServlet.java:259) ...snip... This should be documented in http://jakarta.apache.org/tomcat/tomcat-4.0- doc/manager-howto.html (or somewhere). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5814] - 401 error code could not be populated by error-page tag
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=5814. 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=5814 401 error code could not be populated by error-page tag [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 14:49 --- I already apologized multiple times for this bug. Note: It's not terribly useful anyway to set an error page for 401. *** This bug has been marked as a duplicate of 5197 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5197] - Error Page 401 redirection avoids web resource authorization
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=5197. 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=5197 Error Page 401 redirection avoids web resource authorization [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 14:49 --- *** Bug 5814 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5814] - 401 error code could not be populated by error-page tag
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=5814. 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=5814 401 error code could not be populated by error-page tag --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 15:05 --- I fixed it by check wrapper null on ErrorDispatcherValve.java:291. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5814] - 401 error code could not be populated by error-page tag
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=5814. 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=5814 401 error code could not be populated by error-page tag [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Additional Comments From [EMAIL PROTECTED] 2002-01-11 15:17 --- I fixed it that way too. 4.0.2 b1 already has the fix. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters IdentityOutputFilter.java
remm02/01/11 15:56:07
Modified:http11/src/java/org/apache/coyote/http11/filters
IdentityOutputFilter.java
Log:
- Fix incorrect handling of the number of bytes remaining on output.
Revision ChangesPath
1.4 +8 -11
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/IdentityOutputFilter.java
Index: IdentityOutputFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/IdentityOutputFilter.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- IdentityOutputFilter.java 4 Dec 2001 06:33:07 - 1.3
+++ IdentityOutputFilter.java 11 Jan 2002 23:56:07 - 1.4
@@ -102,7 +102,7 @@
/**
* Remaining bytes.
*/
-protected long remaining = -1;
+protected long remaining = 0;
/**
@@ -141,25 +141,23 @@
public int doWrite(ByteChunk chunk)
throws IOException {
-int result = chunk.getLength();
-
-if (result = 0) {
-return -1;
-}
+int result = 0;
if (contentLength 0) {
if (remaining 0) {
-if (chunk.getLength() remaining) {
+result = chunk.getLength();
+if (result remaining) {
// The chunk is longer than the number of bytes remaining
// in the body; changing the chunk length to the number
// of bytes remaining
chunk.setBytes(chunk.getBytes(), chunk.getStart(),
(int) remaining);
result = (int) remaining;
-remaining = -1;
+remaining = 0;
} else {
remaining = remaining - result;
}
+buffer.doWrite(chunk);
} else {
// No more bytes left to be written : return -1 and clear the
// buffer
@@ -168,8 +166,6 @@
}
}
-buffer.doWrite(chunk);
-
return result;
}
@@ -185,6 +181,7 @@
*/
public void setResponse(Response response) {
contentLength = response.getContentLength();
+remaining = contentLength;
}
@@ -215,7 +212,7 @@
*/
public void recycle() {
contentLength = -1;
-remaining = -1;
+remaining = 0;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems.
I checked in the change to LoaderInterceptor11 to allow it to optionally use the SimpleClassLoader (which is mostly the code from AdaptiveClassLoader) even under Java2. It should show up in tonight's nightly. To enable it, you set the use11Loader=true attribute on the LoaderInterceptor11 element in server.xml and re-start Tomcat. Hopefully this will be more jar-friendly on reloads. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 6:47 PM Subject: Possible Explanation - Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Hi Bill, I downloaded the 3.3 source code and did some sniffing. From what I can tell, here is why 3.2 works and 3.3 does not work with regards to jar files and it's classes. TC 3.2 - LoaderInterceptor uses new instances of the AdaptiveClassLoader (and subclasses for jdk12 support) to handle a context init. This classloader overrides classloader methods and does everything correctly. That's why it has no problem with loading classes from jar files using zip methods or jar file locking. It closes it's jar files after reading it's class files. TC 3.3 - LoaderInterceptor11 uses new instances of the jdk's URLClassloader. What more can I say. Tomcat has no control over URLClassloader and it's operations. The problems you and Bojan pointed out are out of Tomcat's control. I'd like to know what you think. If I'm correct, the question is whether or not you folks are going to punt to Sun. This will let me know what my course of action will be. Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 05, 2002 12:34 PM Subject: Re: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. Bill, Is this patch in the 1/4 nightly build of 3.3? Which .java file was it? Regards, Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 04, 2002 4:50 PM Subject: DO NOT REPLY [Bug 5684] - WEB-INF/lib jar file loading and operations problems. 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=5684. 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=5684 WEB-INF/lib jar file loading and operations problems. --- Additional Comments From [EMAIL PROTECTED] 2002-01-04 18:50 --- There was a missing close statement in the app-ClassLoader. I've added it in, so that the jar file shouldn't stay open. This may fix part 1 (since 3.3 typically does GC much less often then 3.2). It is possible (if very unlikely) that being able to delete the jar file may help with 2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[FAQ] jGuru FAQ Update
jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as many other Java topics). Here is an automated update on recent postings to Tomcat-related FAQs. Please direct flames and feedback to [EMAIL PROTECTED] . - Alex ++ Servlets FAQ: http://www.jguru.com/faq/Servlets How do I pass some servlet variable to javascript? http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=715231 ++ Tomcat FAQ: http://www.jguru.com/faq/Tomcat Cannot run Tomcat 4.0.1 under Linux (Suse 7.2)... getting Segmentation Fault. http://www.jguru.com/misc/faqtrampoline.jsp?src=notifyEID=715375 You can shut email notification off at the FAQ home page(s) or: http://www.jguru.com/guru/notifyprefs.jsp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0.2 b multibyte issue.
The JSP spec assumes a default character encoding of ISO-8859-1 for GET/POST parameters. You will need to convert the parameter strings received by servlets/JSP pages into bytes with their character encoding as ISO-8859-1 and convert them back to Java strings with your own favorite character encoding(s). - Original Message - From: Thom Park [EMAIL PROTECTED] To: tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 3:11 AM Subject: Tomcat 4.0.2 b multibyte issue. Craig et.al. Recently I posted a vague question w.r.t. Multi-byte support in tomcat 4.0.2. Somewhat similar to the oracle at delphi, by asking a general question, I got a general answer. I now have a specific case where there appears to be a problem with multi-byte support in the latest tomcat. In the attached jsp, try cutting and pasting the double-byte chinese character displayed by the browser into the input field and hit the submit button. You should see that the character does not get displayed correctly. Is this a usage problem on my part or some problem with the character encoding? It appears to indicate that the somehow the byte stream is not being interpreted properly by tomcat. -Thom -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr AprInputStream.java AprOutputStream.java AprSocketServer.java
costin 02/01/11 20:00:15
Added: jk/java/org/apache/jk/apr AprInputStream.java
AprOutputStream.java AprSocketServer.java
Log:
Abstractions for the apr is, os, socket. Initial version based on JFC's
unix socket ( which will eventually be part of the standard apr ).
Those are very early, and jk is using the AprImpl directly. In time
we should make them implement completely the java interfaces ( for
example use Socket, etc ).
Revision ChangesPath
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprInputStream.java
Index: AprInputStream.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.apr;
import java.io.*;
import java.net.*;
import java.util.*;
import org.apache.tomcat.util.buf.*;
import org.apache.tomcat.util.http.*;
import org.apache.tomcat.util.threads.*;
/**
* Provide an InputStream for the native socket.
*
*
* @author Jean-Frederic Clere
* @author Costin Manolache
*/
class AprInputStream extends InputStream {
int type; // right now only LOCAL
private int fd; // From openNative.
private AprImpl apr;
long pool;
/**
* Create an InputStream using apr for I/O. This can
* support multiple 'styles' ( unix socket, apr tcp socket,
* etc ). We could split it - the interfaces are highly
* experimental for now.
*/
public AprInputStream(AprImpl apr, long pool, int type, int fd) {
this.apr=apr;
this.fd = fd;
this.pool=pool;
this.type=type;
}
public int read() throws IOException {
byte buf [] = new byte[1];
if ( apr.unRead( pool, fd, buf, 0, 1) 0)
throw new IOException();
return 0xff buf[0];
}
}
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprOutputStream.java
Index: AprOutputStream.java
===
/*
*
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/apr AprImpl.java
costin 02/01/11 20:01:47
Modified:jk/java/org/apache/jk/apr AprImpl.java
Log:
Few more enhancements. Load libapr.so ( yes, I know - it works only on Unix
at this moment, .so is hardcoded and few other things ). This is
required to get it working without having to set LD_LIBRARY_PATH.
Also use the base dir to locate the library - the idea is that we can assume
a 'fixed' layout ( or a set of layouts ).
Revision ChangesPath
1.3 +48 -11jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java
Index: AprImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/apr/AprImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- AprImpl.java 6 Jan 2002 08:40:44 - 1.2
+++ AprImpl.java 12 Jan 2002 04:01:47 - 1.3
@@ -1,12 +1,16 @@
package org.apache.jk.apr;
+import java.io.*;
+
/** Implements the interface with the APR library. This is for internal-use
* only. The goal is to use 'natural' mappings for user code - for example
* java.net.Socket for unix-domain sockets, etc.
*
*/
public class AprImpl {
-
+String baseDir;
+String aprHome;
+
/** Initialize APR
*/
public native int initialize();
@@ -41,18 +45,51 @@
public native int unWrite( long pool, long unSocket,
byte buf[], int off, int len );
+/** Native libraries are located based on base dir.
+ * XXX Add platform, version, etc
+ */
+public void setBaseDir(String s) {
+baseDir=s;
+}
+
+// XXX maybe install the jni lib in apr-home ?
+public void setAprHome( String s ) {
+aprHome=s;
+}
+
+/** This method of loading the libs doesn't require setting
+ * LD_LIBRARY_PATH. Assuming a 'right' binary distribution,
+ * or a correct build all files will be in their right place.
+ *
+ * The burden is on our code to deal with platform specific
+ * extensions and to keep the paths consistent - not easy, but
+ * worth it if it avoids one extra step for the user.
+ *
+ * Of course, this can change to System.load() and putting the
+ * libs in LD_LIBRARY_PATH.
+ */
+public void loadNative() {
+if( aprHome==null )
+aprHome=baseDir;
+File dir=new File(aprHome);
+// XXX platform independent, etc...
+File apr=new File( dir, libapr.so);
+
+loadNative( apr.getAbsolutePath() );
+
+dir=new File(baseDir);
+File jniConnect=new File( dir, jni_connect.so);
+
+loadNative( jniConnect.getAbsolutePath() );
+}
+
+boolean ok=true;
+
public void loadNative(String libPath) {
try {
-if( libPath==null )
-libPath=jni_connect;
-// XXX use load() for full path
-if( libPath.indexOf( / ) =0 ||
-libPath.indexOf( \\ ) =0 ) {
-System.load( libPath );
-} else {
-System.loadLibrary( libPath );
-}
-} catch( RuntimeException ex ) {
+System.load( libPath );
+} catch( Throwable ex ) {
+ok=false;
ex.printStackTrace();
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelJni.java ChannelUn.java MsgAjp.java
costin 02/01/11 20:03:42
Modified:jk/java/org/apache/jk/common ChannelUn.java MsgAjp.java
Added: jk/java/org/apache/jk/common ChannelJni.java
Log:
Added the template for the jni channel. Work is underway on the C side as well.
Few fixes/enhancements for the Unix channel ( to locate the native libs with less
user intervention )
Revision ChangesPath
1.2 +14 -8
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelUn.java
Index: ChannelUn.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelUn.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ChannelUn.java6 Jan 2002 08:42:09 - 1.1
+++ ChannelUn.java12 Jan 2002 04:03:42 - 1.2
@@ -82,6 +82,7 @@
String file;
Worker worker;
ThreadPool tp=new ThreadPool();
+String jkHome;
/* Tcp socket options */
@@ -101,6 +102,13 @@
file=f;
}
+/** Set the base dir of the jk webapp. This is used to locate
+ * the (fixed) path to the native lib.
+ */
+public void setJkHome( String s ) {
+jkHome=s;
+}
+
/* */
long unixListenSocket;
int socketNote=1;
@@ -121,10 +129,10 @@
public void init() throws IOException {
apr=new AprImpl();
-File f=new File( ../jk2/jni/libapr.so );
-apr.loadNative( f.getAbsolutePath() );
-f=new File( ../jk2/jni/jni_connect.so );
-apr.loadNative( f.getAbsolutePath() );
+File f=new File( jkHome );
+File aprBase=new File( jkHome, /WEB-INF/jk2/jni );
+apr.setBaseDir( aprBase.getAbsolutePath() );
+apr.loadNative();
apr.initialize();
gPool=apr.poolCreate( 0 );
@@ -191,15 +199,13 @@
int pos = 0;
int got;
-if (dL 5) {
-d(reading # + b + + (b==null ? 0: b.length) + + offset +
+ len);
-}
while(pos len) {
got=apr.unRead( gPool, s.longValue(),
b, pos + offset, len - pos);
if (dL 5) {
-d(read got # + got);
+d(reading # + b + + (b==null ? 0: b.length) + +
+ offset + + len + got # + got);
}
// connection just closed by remote.
if (got = 0) {
1.3 +2 -3
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java
Index: MsgAjp.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MsgAjp.java 6 Jan 2002 08:46:10 - 1.2
+++ MsgAjp.java 12 Jan 2002 04:03:42 - 1.3
@@ -173,7 +173,8 @@
}
public void appendByteChunk(ByteChunk bc) throws IOException {
-if(bc==null || bc.isNull() ) {
+if(bc==null ) {
+System.out.println(XXX appending BC null + bc);
appendInt( 0);
appendByte(0);
return;
@@ -182,8 +183,6 @@
byte[] bytes = bc.getBytes();
int start=bc.getStart();
appendInt( bc.getLength() );
-System.out.println(XXX appending + bytes + + bc.getLength() +
- + new String( bytes, 0, bc.getLength()));
cpBytes(bytes, start, bc.getLength());
appendByte(0);
}
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelJni.java
Index: ChannelJni.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
*
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40 Ajp13Connector.java Ajp13InputStream.java Ajp13Logger.java Ajp13OutputStream.java Ajp13Processor.java Ajp13Request.java Ajp13Response.java
costin 02/01/11 20:05:54 Removed: jk/java/org/apache/jk/server/tomcat40 Ajp13Connector.java Ajp13InputStream.java Ajp13Logger.java Ajp13OutputStream.java Ajp13Processor.java Ajp13Request.java Ajp13Response.java Log: Remove the original Ajp connector. A modified version will follow ( next commit ), using Jk prefix ( most of the code is identical, but more agressive with recycling ) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40 JkConnector.java JkRequest40.java JkResponse40.java Worker40.java
costin 02/01/11 20:10:14
Added: jk/java/org/apache/jk/server/tomcat40 JkConnector.java
JkRequest40.java JkResponse40.java Worker40.java
Log:
Jk2-style connector for 4.0.
I couldn't find any way to make it work as a servlet ( class loader is a nightmare ),
so JkConnector must be added to server.xml and the jar files must be copied.
However we do use the JkServlet and web.xml for all the config - so configuration
will be identical and more importanly standard webapp tools ( and knowledge ) can be
used.
Of course, there are other options as well - server.xml settings, workers.properties
( I'll try this later - it would be a nice idea to jave a single file for both C and
java,
and set things like port only there ).
Webapp features like reloading ( or hot update, etc ) will probably not work with
4.0 ( probably not very usefull for most people anyway ).
Revision ChangesPath
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40/JkConnector.java
Index: JkConnector.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.server.tomcat40;
import java.io.*;
import java.net.*;
import java.security.*;
import java.util.*;
import org.apache.catalina.*;
import org.apache.catalina.core.*;
import org.apache.catalina.net.DefaultServerSocketFactory;
import org.apache.catalina.net.ServerSocketFactory;
import org.apache.catalina.util.LifecycleSupport;
import org.apache.catalina.util.StringManager;
import org.apache.jk.server.*;
import org.apache.catalina.jk.*;
/**
* Implementation of an Jk connector.
*
* @author Kevin Seguin
* @author Costin Manolache
*/
public final class JkConnector
implements Connector, Lifecycle {
/**
* The Container used for processing requests received by this Connector.
*/
protected Container container = null;
protected LifecycleSupport lifecycle = new LifecycleSupport(this);
private boolean started = false;
private boolean stopped = false;
private Service
cvs commit: jakarta-tomcat/proposals/StreamHandler - New directory
billbarker02/01/11 20:12:29 jakarta-tomcat/proposals/StreamHandler - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF - New directory
billbarker02/01/11 20:12:53 jakarta-tomcat/proposals/StreamHandler/WEB-INF - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes - New directory
billbarker02/01/11 20:13:27 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org - New directory
billbarker02/01/11 20:13:39 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache - New directory
billbarker02/01/11 20:13:50 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat - New directory
billbarker02/01/11 20:13:59 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules - New directory
billbarker02/01/11 20:14:18 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util - New directory
billbarker02/01/11 20:14:18 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util/net - New directory
billbarker02/01/11 20:14:32 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util/net - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40 JkConfig40.java
costin 02/01/11 20:14:53
Added: jk/java/org/apache/jk/server/tomcat40 JkConfig40.java
Log:
Add an initial config code to extract webapps ( I don't think autoconf will
happen very soon, but it's a small start ).
Revision ChangesPath
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat40/JkConfig40.java
Index: JkConfig40.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.server.tomcat40;
import org.apache.catalina.*;
import java.io.*;
import org.apache.jk.server.*;
import org.apache.jk.core.*;
/**
* Extract config information out of tomcat4.x.
*
* @author Bill Barker
* @author Costin Manolache
* @author Larry Isaacs
*/
public class JkConfig40 implements LifecycleListener {
JkMain jkMain;
// Tomcat callbacks
// Auto-config should be able to react to dynamic config changes,
// and regenerate the config.
/** Generate the configuration - only when the server is
* completely initialized ( before starting )
*/
public void lifecycleEvent(LifecycleEvent evt)
{
d( Event + evt );
if(Lifecycle.START_EVENT.equals(evt.getType())) {
Lifecycle who = evt.getLifecycle();
if( who instanceof Server ) {
executeServer((Server)who);
} else if ( who instanceof Host ) {
executeHost((Host)who);
} else if( who instanceof Context ) {
executeContext((Context)who);
}
}
}
public void loadExisting(Container ct) {
d(loadExisting);
while( !(ct instanceof Engine )
ct!=null ) {
d(Ct== + ct );
ct=ct.getParent();
}
if( ct==null ) {
d(Can't find the Server);
return;
}
executeEngine( ( Engine)ct );
}
// Deal with the various 4.0 Containers. We care about the Contexts,
//
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config - New directory
billbarker02/01/11 20:15:04 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat33 JkConfig33.java JkServlet33.java
costin 02/01/11 20:20:43
Modified:jk/java/org/apache/jk/server/tomcat33 JkServlet33.java
Added: jk/java/org/apache/jk/server/tomcat33 JkConfig33.java
Log:
Few fixes, added the template for the config extractor.
Revision ChangesPath
1.2 +21 -32
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat33/JkServlet33.java
Index: JkServlet33.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat33/JkServlet33.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JkServlet33.java 6 Jan 2002 08:52:38 - 1.1
+++ JkServlet33.java 12 Jan 2002 04:20:43 - 1.2
@@ -87,40 +87,29 @@
{
}
-public void init(ServletConfig conf) throws ServletException {
-d(init);
-}
-
-public void destroy() {
-d(Shuting down);
-}
-
public void initializeContainer(ServletConfig cfg) {
-d(Initializing 4.0 for jk requests);
-
-ServletContext sctx=cfg.getServletContext();
-Context ctx=(Context)sctx.getAttribute( Context.ATTRIB_REAL_CONTEXT );
-if( ctx==null ) {
-d(Untrusted app or error, ctx==null );
-return;
-}
-cm=ctx.getContextManager();
-
-// We now have control over the whole thing !
-
-// We could register an interceptor to be notified
-registerInterceptors();
-
-// start Jk
-JkMain jkMain=new JkMain();
-jkMain.setProperties( servletConfig2properties( cfg ));
-Worker33 worker=new Worker33();
-worker.setContextManager( cm );
-jkMain.setDefaultWorker( worker );
-
try {
-jkMain.start();
-} catch( Exception ex ) {
+ServletContext sctx=cfg.getServletContext();
+Context ctx=(Context)sctx.getAttribute( Context.ATTRIB_REAL_CONTEXT );
+if( ctx==null ) {
+d(Untrusted app or error, ctx==null );
+return;
+}
+cm=ctx.getContextManager();
+
+// We now have control over the whole thing !
+
+// We could register an interceptor to be notified
+registerInterceptors();
+
+Worker33 worker=new Worker33();
+worker.setContextManager( cm );
+
+d(Initializing tomcat3.3 for jk requests);
+
+// start Jk
+initJkMain(cfg, worker);
+} catch( Throwable ex ) {
ex.printStackTrace();
}
}
1.1
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/tomcat33/JkConfig33.java
Index: JkConfig33.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,
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java JkServlet.java
costin 02/01/11 20:25:14
Modified:jk/java/org/apache/jk/server JkMain.java JkServlet.java
Log:
Few fixes. 4.x can't be starte from a servlet ( I tried with 4.1 as well, no luck )
but it uses server.xml
Revision ChangesPath
1.4 +11 -2
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
Index: JkMain.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JkMain.java 6 Jan 2002 08:50:56 - 1.3
+++ JkMain.java 12 Jan 2002 04:25:14 - 1.4
@@ -82,7 +82,8 @@
Properties props;
Worker defaultWorker;
-
+String jkHome;
+
public JkMain()
{
}
@@ -104,10 +105,18 @@
public void setDefaultWorker( Worker w ) {
defaultWorker=w;
}
+
+public void setJkHome( String s ) {
+jkHome=s;
+}
public void start() throws IOException {
ChannelUn csocket=new ChannelUn();
-csocket.setFile( /tmp/tomcatApr );
+// if( jkHome==null )
+csocket.setFile( /tmp/tomcatUnixSocket );
+// else
+// csocket.setFile( jkHome + /WEB-INF/tomcatUnixSocket );
+csocket.setJkHome( jkHome );
/* ChannelSocket csocket=new ChannelSocket();
csocket.setPort( 8009 );
*/
1.3 +35 -7
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkServlet.java
Index: JkServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkServlet.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JkServlet.java6 Jan 2002 08:50:56 - 1.2
+++ JkServlet.java12 Jan 2002 04:25:14 - 1.3
@@ -85,7 +85,8 @@
/* Parameters for the ajp channel */
String port;
String host; /* If it starts with '/' we'll use ud */
-ServletContext sctx;
+protected ServletContext sctx;
+protected ServletConfig sconf;
public JkServlet()
{
@@ -93,6 +94,10 @@
protected Properties servletConfig2properties(ServletConfig conf ) {
Properties props=new Properties();
+if( conf==null ) {
+d(No config );
+return props;
+}
Enumeration paramNE=conf.getInitParameterNames();
while( paramNE.hasMoreElements() ){
String s=(String)paramNE.nextElement();
@@ -105,9 +110,14 @@
public void init(ServletConfig conf) throws ServletException {
-super.init(conf);
-sctx=conf.getServletContext();
-getServletAdapter();
+try {
+super.init(conf);
+sconf=conf;
+sctx=conf.getServletContext();
+getServletAdapter();
+} catch( Throwable t ) {
+t.printStackTrace();
+}
}
/* Ok, this is a bit hacky - there is ( or I couldn't find ) any clean
@@ -119,7 +129,7 @@
the internals.
*/
private void getServletAdapter() {
-try40();
+//try40();
try33();
}
@@ -132,8 +142,8 @@
return;
}
t33.initializeContainer( getServletConfig());
-} catch( Exception ex ) {
-ex.printStackTrace();
+} catch( Throwable ex ) {
+d(3.3 intialization failed + ex.toString());
}
}
@@ -159,6 +169,24 @@
ex.printStackTrace();
// ignore it - what would you expect, we pass dummy objects
}
+} catch( Exception ex ) {
+ex.printStackTrace();
+}
+}
+
+protected JkMain jkMain;
+
+protected void initJkMain(ServletConfig cfg, Worker defaultWorker) {
+jkMain=new JkMain();
+jkMain.setProperties( servletConfig2properties( cfg ));
+jkMain.setDefaultWorker( defaultWorker );
+
+String jkHome=cfg.getServletContext().getRealPath(/);
+d(Setting jkHome + jkHome );
+jkMain.setJkHome( jkHome );
+
+try {
+jkMain.start();
} catch( Exception ex ) {
ex.printStackTrace();
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_vm.h
costin 02/01/11 20:33:54 Added: jk/native2/include jk_vm.h Log: I did a bit of refactoring on the jni worker. This deals with starting the vm. There are 2 benefits of separating this: - the code gets much simpler and cleaner. We can now use different impl. for jni1.1 and jni1.2, add the required 'tricks' specific to each vm and os, even support some pluggability. This will also allow a clean addition for more different vms ( like kaffe, gcj ) - the vm code has general properties about the vm - it doesn't have to be in-process. The code and properties could also be used to start an out-of-process vm - and the 'auto start tomcat when apache starts', like jserv did. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/include/jk_vm.h Index: jk_vm.h === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 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 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, 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. * * * * = * *
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
costin 02/01/11 20:43:04
Modified:jk/native2/include jk_global.h
Log:
In global we have a lot of platform specific stuff, added some more.
There is absolutely no reason to ask the user to specify the file separator
and all those things when we already know them.
( workerEnv.init will add them automatically to the init properties. )
Revision ChangesPath
1.3 +19 -1 jakarta-tomcat-connectors/jk/native2/include/jk_global.h
Index: jk_global.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_global.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- jk_global.h 4 Dec 2001 18:33:50 - 1.2
+++ jk_global.h 12 Jan 2002 04:43:04 - 1.3
@@ -59,7 +59,7 @@
* Description: Global definitions and include files that should exist *
* anywhere *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.2 $ *
+ * Version: $Revision: 1.3 $ *
***/
#ifndef JK_GLOBAL_H
@@ -165,6 +165,20 @@
#define JK_SESSION_IDENTIFIER JSESSIONID
#define JK_PATH_SESSION_IDENTIFIER ;jsessionid
+#if defined(WIN32)
+#define SO_EXTENSION dll
+#else
+ #if defined(NETWARE)
+ #define SO_EXTENSION nlm
+ #else
+ #define SO_EXTENSION so
+ #endif
+#endif
+
+#ifndef ARCH
+#define ARCH i386
+#endif
+
#if defined(WIN32) || defined(NETWARE)
#define JK_METHOD __stdcall
#define C_LEVEL_TRY_START __try {
@@ -172,7 +186,9 @@
#define C_LEVEL_FINALLY_START __finally {
#define C_LEVEL_FINALLY_END }
#define PATH_SEPERATOR (';')
+#define PATH_SEPARATOR_STR (;)
#define FILE_SEPERATOR ('\\')
+#define FILE_SEPARATOR_STR (\\)
#define PATH_ENV_VARIABLE (PATH)
/* incompatible names... */
@@ -187,6 +203,8 @@
#define C_LEVEL_FINALLY_END
#define PATH_SEPERATOR (':')
#define FILE_SEPERATOR ('/')
+#define PATH_SEPARATOR_STR (:)
+#define FILE_SEPARATOR_STR (/)
#define PATH_ENV_VARIABLE (LD_LIBRARY_PATH)
#endif
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_map.h
costin 02/01/11 20:43:46 Modified:jk/native2/include jk_map.h Log: Small change in signature - the exact same code was duplicated in jni worker. Revision ChangesPath 1.8 +6 -5 jakarta-tomcat-connectors/jk/native2/include/jk_map.h Index: jk_map.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_map.h,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- jk_map.h 31 Dec 2001 19:15:12 - 1.7 +++ jk_map.h 12 Jan 2002 04:43:46 - 1.8 @@ -58,7 +58,7 @@ /*** * Description: Map object header file * * Author: Gal Shachor [EMAIL PROTECTED] * - * Version: $Revision: 1.7 $ * + * Version: $Revision: 1.8 $ * ***/ #ifndef JK_MAP_H @@ -137,7 +137,8 @@ const char *prop, const char *def); /** Get a string property, using the worker's style -for properties. +for properties. If objType is null, then objName.pname +will be used. Example worker.ajp13.host=localhost. */ char *jk_map_getStrProp(struct jk_env *env, jk_map_t *m, @@ -157,7 +158,7 @@ /* == Manipulating values == */ -/** Extract a String[] property. It'll split the value on +/** Extract a String[] property. If sep==NULL, it'll split the value on * ' ', tab, ',', '*'. * * @param pool Pool on which the result will be allocated. Defaults @@ -165,7 +166,7 @@ */ char **jk_map_split(struct jk_env *env, jk_map_t *m, struct jk_pool *pool, /* XXX will be removed */ -const char *listStr, unsigned *list_len ); +const char *listStr, const char *sep,unsigned *list_len ); int jk_map_str2int(struct jk_env *env, char *value); @@ -188,7 +189,7 @@ */ char *jk_map_replaceProperties(struct jk_env *env, jk_map_t *m, struct jk_pool *resultPool, - const char *value); + char *value); /** For multi-value properties, return the concatenation -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_workerEnv.h
costin 02/01/11 20:44:32
Modified:jk/native2/include jk_workerEnv.h
Log:
Pointer to the vm. ( not sure if this is the best place, or if it should
be a singleton - but different components will use the vm ).
Revision ChangesPath
1.8 +8 -1 jakarta-tomcat-connectors/jk/native2/include/jk_workerEnv.h
Index: jk_workerEnv.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_workerEnv.h,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_workerEnv.h16 Dec 2001 23:17:23 - 1.7
+++ jk_workerEnv.h12 Jan 2002 04:44:32 - 1.8
@@ -58,7 +58,7 @@
/***
* Description: Workers controller header file *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.7 $ *
+ * Version: $Revision: 1.8 $ *
***/
#ifndef JK_WORKERENV_H
@@ -72,6 +72,7 @@
#include jk_webapp.h
#include jk_handler.h
#include jk_service.h
+#include jk_vm.h
#ifdef __cplusplus
extern C {
@@ -196,6 +197,12 @@
*/
struct jk_handler **handlerTable;
int lastMessageId;
+
+/* The vm - we support a single instance per process
+ * ( i.e can't have both jdk1.1 and jdk1.2 at the same time,
+ * or 2 instances of the same vm. )
+ */
+struct jk_vm *vm;
/** Private data, associated with the 'real' server
* server_rec * in apache
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_vm_default.c
costin 02/01/11 20:48:20 Added: jk/native2/common jk_vm_default.c Log: This is the code extracted from jni worker. Few changes - we do now a lot of 'guessing' to avoid asking the user for things we can find for ourself. The defaults do work now fine - it required LD_LIBRARY_PATH to be set before starting apache ( that's required by jni ), and if you also set TOMCAT_HOME and JAVA_HOME ( that should be already set or easy to do ) jni will figure everything it needs. The old settings in worker.properties can be used to override the guessed values, but the nightmare of setting jni worker should be close to end. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/common/jk_vm_default.c Index: jk_vm_default.c === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 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 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, 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
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c
costin 02/01/11 20:59:19 Added: jk/native2/common jk_channel_jni.c Log: I'm changing the way the jni worker operates, to use the same code as ajp. Making enhancements to jni and ajp in parallel is too difficult, and the current jni code has some problems - it's using strings ( possible with the wrong encoding, the right one might be in the session or some headers ). It's also difficult to recycle, etc. In future we can go back to using method calls, but just sending buffers is much simpler and may be much faster too. ( not working yet ) Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c Index: jk_channel_jni.c === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 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 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, 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- *
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_run.c
costin 02/01/11 21:01:15 Added: jk/native2/common jk_worker_run.c Log: Initial template for run worker. This will start a java process ( it'll be the 'startup' part of the jni worker ). Revision ChangesPath 1.1 jakarta-tomcat-connectors/jk/native2/common/jk_worker_run.c Index: jk_worker_run.c === /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 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 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, 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 http://www.apache.org/. * * * * = */ /** * Run worker. It'll execute a process and monitor
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_ajp14_worker.c
costin 02/01/11 21:05:12
Modified:jk/native2/common jk_ajp14_worker.c
Log:
Make channel a configurable option.
Revision ChangesPath
1.13 +24 -12jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c
Index: jk_ajp14_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_ajp14_worker.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- jk_ajp14_worker.c 18 Dec 2001 22:51:55 - 1.12
+++ jk_ajp14_worker.c 12 Jan 2002 05:05:12 - 1.13
@@ -161,11 +161,15 @@
jk_worker_t *aw;
char * secret_key;
int proto=AJP14_PROTO;
-
+char *channelType;
+
aw = _this;
secret_key = jk_map_getStrProp( env, props,
worker, aw-name, secretkey, NULL );
-
+
+channelType = jk_map_getStrProp( env, props,
+ worker, aw-name, channel, socket );
+
if ((!secret_key) || (!strlen(secret_key))) {
proto=AJP13_PROTO;
aw-proto= AJP13_PROTO;
@@ -185,10 +189,12 @@
if( _this-channel == NULL ) {
/* Create a default channel */
- _this-channel=env-getInstance(env, _this-pool,channel, socket );
+ _this-channel=env-getInstance(env, _this-pool,channel,
+channelType );
if( _this-channel == NULL ) {
- env-l-jkLog(env, env-l, JK_LOG_ERROR, Error creating socket
channel\n);
+ env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ Error creating %s channel\n, channelType);
return JK_FALSE;
}
}
@@ -215,7 +221,8 @@
*/
static void jk_close_endpoint(jk_env_t *env, jk_endpoint_t *ae)
{
-env-l-jkLog(env, env-l, JK_LOG_INFO, endpoint.close() %s\n,
ae-worker-name);
+env-l-jkLog(env, env-l, JK_LOG_INFO, endpoint.close() %s\n,
+ ae-worker-name);
ae-reuse = JK_FALSE;
ae-worker-channel-close( env, ae-worker-channel, ae );
@@ -283,7 +290,8 @@
if( ( e== NULL )
|| ( s == NULL )
|| ! is_recoverable_error ) {
- env-l-jkLog(env, env-l, JK_LOG_ERROR, ajp14.service()
NullPointerException\n);
+ env-l-jkLog(env, env-l, JK_LOG_ERROR,
+ ajp14.service() NullPointerException\n);
return JK_FALSE;
}
@@ -323,7 +331,7 @@
* XXX JK_RETRIES could be replaced by the number of workers in
* a load-balancing configuration
*/
-for(attempt = 0 ; attempt e-worker-connect_retry_attempts ; attempt++) {
+for(attempt = 0 ; attempt e-worker-connect_retry_attempts ;attempt++) {
jk_channel_t *channel=e-worker-channel;
/* e-request-dump(env, e-request, Before sending ); */
@@ -383,7 +391,7 @@
/* the browser stop sending data, no need to recover */
e-recoverable = JK_FALSE;
env-l-jkLog(env, env-l, JK_LOG_ERROR,
- ajp14.service() Error receiving initial post data\n);
+ ajp14.service() Error receiving initial post \n);
return JK_FALSE;
}
@@ -407,7 +415,8 @@
if( err != JK_TRUE ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
- ajp14.service() ajpGetReply recoverable error %d\n, err);
+ ajp14.service() ajpGetReply recoverable error %d\n,
+ err);
}
return err;
@@ -427,7 +436,8 @@
int err=0;
err=w-endpointCache-put( env, w-endpointCache, e );
if( err==JK_TRUE ) {
-env-l-jkLog(env, env-l, JK_LOG_INFO, ajp14.done() return to pool
%s\n,
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ ajp14.done() return to pool %s\n,
w-name );
return JK_TRUE;
}
@@ -531,7 +541,8 @@
_this-endpointCache=jk_objCache_create( env, _this-pool );
if( _this-endpointCache != NULL ) {
-err=_this-endpointCache-init( env, _this-endpointCache, cache_sz );
+err=_this-endpointCache-init( env, _this-endpointCache,
+cache_sz );
if( err!= JK_TRUE ) {
_this-endpointCache=NULL;
}
@@ -546,7 +557,8 @@
if (_this-secret == NULL) {
/* No extra initialization for AJP13 */
-env-l-jkLog(env, env-l, JK_LOG_INFO, ajp14.init() ajp1x worker
name=%s\n,
+env-l-jkLog(env, env-l, JK_LOG_INFO,
+ ajp14.init() ajp1x worker name=%s\n,
_this-name);
return JK_TRUE;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_jni_worker.c
costin 02/01/11 21:06:06
Modified:jk/native2/common jk_jni_worker.c
Log:
Jni worker, with starting the vm removed, a bit of cleanup, etc.
Seems to work fine ( starting the vm, etc ) - need to get the rest working.
( and to start the real tomcats to do the work :-)
Revision ChangesPath
1.11 +260 -1021 jakarta-tomcat-connectors/jk/native2/common/jk_jni_worker.c
Index: jk_jni_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_jni_worker.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- jk_jni_worker.c 16 Dec 2001 23:18:11 - 1.10
+++ jk_jni_worker.c 12 Jan 2002 05:06:06 - 1.11
@@ -55,313 +55,110 @@
* *
* = */
-/***
- * Description: In process JNI worker *
- * Author: Gal Shachor [EMAIL PROTECTED] *
- * Based on: *
- * Version: $Revision: 1.10 $ *
- ***/
-
-#if !defined(WIN32) !defined(NETWARE)
-#include dlfcn.h
-#endif
-
-#include jni.h
-
-#include jk_pool.h
-#include jk_env.h
-
-#if defined LINUX defined APACHE2_SIGHACK
-#include pthread.h
-#include signal.h
-#include bits/signum.h
-#endif
-
-#ifdef NETWARE
-#include nwthread.h
-#include nwadv.h
-#endif
-#include jk_logger.h
-#include jk_service.h
-
-#ifndef JNI_VERSION_1_1
-#define JNI_VERSION_1_1 0x00010001
-#endif
-
-#define null_check(e) if ((e) == 0) return JK_FALSE
-
-jint (JNICALL *jni_get_default_java_vm_init_args)(void *) = NULL;
-jint (JNICALL *jni_create_java_vm)(JavaVM **, JNIEnv **, void *) = NULL;
-jint (JNICALL *jni_get_created_java_vms)(JavaVM **, int, int *) = NULL;
-
-#define JAVA_BRIDGE_CLASS_NAME (org/apache/tomcat/modules/server/JNIEndpoint)
-/* #define JAVA_BRIDGE_CLASS_NAME (org/apache/tomcat/service/JNIEndpoint)
+/**
+ * In process JNI worker
+ * @author: Gal Shachor [EMAIL PROTECTED]
+ * @author: Costin Manolache
*/
-static jk_worker_t *the_singleton_jni_worker = NULL;
-
-struct jni_worker {
-
-int was_verified;
-int was_initialized;
+#include jk_vm.h
+#include jk_registry.h
+#include jni.h
-jk_pool_t *pool;
+/* default only, is configurable now */
+#define JAVA_BRIDGE_CLASS_NAME (org/apache/jk/common/ChannelJni)
-/*
- * JVM Object pointer.
- */
-JavaVM *jvm;
-
-/*
- * [V] JNIEnv used for boostraping from validate - init w/o an attach
- */
-JNIEnv *tmp_env;
+struct jni_worker_data {
-/*
- * Web Server to Java bridge, instance and class.
- */
-jobject jk_java_bridge_object;
+jk_vm_t *vm;
+
jclass jk_java_bridge_class;
-/*
- * Java methods ids, to jump into the JVM
- */
jmethodID jk_startup_method;
jmethodID jk_service_method;
jmethodID jk_shutdown_method;
-/*
- * Command line for tomcat startup
- */
+char *className;
char *tomcat_cmd_line;
-
-/*
- * Classpath
- */
-char *tomcat_classpath;
-
-/*
- * Full path to the jni javai/jvm dll
- */
-char *jvm_dll_path;
-
-/*
- * Initial Java heap size
- */
-unsigned tomcat_ms;
-
-/*
- * Max Java heap size
- */
-unsigned tomcat_mx;
-
-/*
- * Java system properties
- */
-char **sysprops;
-
-#ifdef JNI_VERSION_1_2
-/*
- * Java 2 initialization options (-X... , -verbose etc.)
- */
-char **java2opts;
-
-/*
- * Java 2 lax/strict option checking (bool)
- */
-int java2lax;
-#endif
-
-/*
- * stdout and stderr file names for Java
- */
char *stdout_name;
char *stderr_name;
-
-char *name;
-jk_worker_t worker;
};
-typedef struct jni_worker jni_worker_t;
-
-struct jni_endpoint {
-int attached;
-JNIEnv *env;
-jni_worker_t *worker;
-
-jk_endpoint_t endpoint;
-};
-typedef struct jni_endpoint jni_endpoint_t;
-
-int JK_METHOD jk_worker_jni_factory(jk_env_t *env, jk_pool_t *pool,
-void **result,
-char *type, char *name);
-
-static int load_jvm_dll(jk_env_t *env, jni_worker_t *p);
-
-static int
Re: cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config - New directory
Could somebody who knows CVS better then I do explain why I can't ci files from here? The message is: cvs server: could not stub branch HEAD for /home/cvs/jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/ tomcat/util/net/Attic/StreamHandlerFactory.java,v - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 8:15 PM Subject: cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/mod ules/config - New directory billbarker02/01/11 20:15:04 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/mod ules/config - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_lb_worker.c jk_map.c
costin 02/01/11 21:08:57
Modified:jk/native2/common jk_lb_worker.c jk_map.c
Log:
Few fixes in jk_map. The 'split' code is now used for processing jni props too.
Revision ChangesPath
1.12 +2 -2 jakarta-tomcat-connectors/jk/native2/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_lb_worker.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_lb_worker.c6 Jan 2002 09:06:02 - 1.11
+++ jk_lb_worker.c12 Jan 2002 05:08:57 - 1.12
@@ -60,7 +60,7 @@
* several workers. *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Based on: *
- * Version: $Revision: 1.11 $ *
+ * Version: $Revision: 1.12 $ *
***/
#include jk_pool.h
@@ -305,7 +305,7 @@
}
worker_names=jk_map_split( env, props, props-pool,
- tmp, num_of_workers );
+ tmp, NULL, num_of_workers );
if( worker_names==NULL || num_of_workers==0 ) {
env-l-jkLog(env, env-l, JK_LOG_ERROR,
1.12 +29 -14jakarta-tomcat-connectors/jk/native2/common/jk_map.c
Index: jk_map.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_map.c,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jk_map.c 31 Dec 2001 22:25:03 - 1.11
+++ jk_map.c 12 Jan 2002 05:08:57 - 1.12
@@ -58,7 +58,7 @@
/***
* Description: General purpose map object *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.11 $ *
+ * Version: $Revision: 1.12 $ *
***/
#include jk_global.h
@@ -93,6 +93,7 @@
for(i = 0 ; i mPriv-size ; i++) {
if(0 == strcmp(mPriv-names[i], name)) {
+/*fprintf(stderr, jk_map.get found %s %s \n, name, mPriv-values[i]
); */
return mPriv-values[i];
}
}
@@ -138,6 +139,7 @@
mPriv-names[mPriv-size] = (char *)name;
*/
mPriv-names[mPriv-size] = m-pool-pstrdup(env,m-pool, name);
+/* fprintf(stderr, jk_map.set %s %s \n, name, value ); */
mPriv-size ++;
rc = JK_TRUE;
}
@@ -286,10 +288,13 @@
{
char buf[1024];
-if( m==NULL || objType==NULL || objName==NULL || pname==NULL ) {
+if( m==NULL || objName==NULL || pname==NULL ) {
return def;
}
-sprintf(buf, %s.%s.%s, objType, objName, pname);
+if( objType==NULL )
+sprintf(buf, %s.%s, objName, pname);
+else
+sprintf(buf, %s.%s.%s, objType, objName, pname);
return m-get(env, m, buf );
}
@@ -352,6 +357,7 @@
char **jk_map_split(jk_env_t *env, jk_map_t *m,
jk_pool_t *pool,
const char *listStr,
+const char *sep,
unsigned *list_len )
{
char **ar = NULL;
@@ -360,10 +366,14 @@
char *v;
char *l;
-if( pool == NULL )
-pool=m-pool;
+if( sep==NULL )
+sep= \t,*;
-*list_len = 0;
+if( pool == NULL m!=NULL )
+pool=m-pool;
+
+if( list_len != NULL )
+*list_len = 0;
if(listStr==NULL)
return NULL;
@@ -379,8 +389,9 @@
* strtok also by a *
*/
-for(l = strtok(v, \t,*) ; l ; l = strtok(NULL, \t,*)) {
-if(idex == capacity) {
+for(l = strtok(v, sep) ; l ; l = strtok(NULL, sep)) {
+/* We want at least one space after idex for the null*/
+if(idex+1 = capacity) {
ar = pool-realloc(env, pool,
sizeof(char *) * (capacity + 5),
ar,
@@ -393,8 +404,12 @@
ar[idex] = pool-pstrdup(env, pool, l);
idex ++;
}
-
-*list_len = idex;
+
+/* Append a NULL, we have space */
+ar[idex]=NULL;
+
+if( list_len != NULL )
+*list_len = idex;
return ar;
}
@@ -569,9 +584,9 @@
*/
char *jk_map_replaceProperties(jk_env_t *env, jk_map_t *m,
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_registry.c jk_registry.h
costin 02/01/11 21:09:50 Modified:jk/native2/common jk_registry.c jk_registry.h Log: Added the new entries. Revision ChangesPath 1.9 +9 -5 jakarta-tomcat-connectors/jk/native2/common/jk_registry.c Index: jk_registry.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- jk_registry.c 31 Dec 2001 22:25:03 - 1.8 +++ jk_registry.c 12 Jan 2002 05:09:50 - 1.9 @@ -63,7 +63,7 @@ #include jk_registry.h /*** * Description: Worker list* - * Version: $Revision: 1.8 $ * + * Version: $Revision: 1.9 $ * ***/ /** Static declarations for all 'hardcoded' modules. This is a hack, @@ -112,12 +112,15 @@ env-registerFactory( env, worker, ajp14, jk_worker_ajp14_factory ); env-registerFactory( env, worker, lb,jk_worker_lb_factory ); env-registerFactory( env, worker, status, jk_worker_status_factory ); + env-registerFactory( env, worker, run, jk_worker_run_factory ); #ifdef HAS_APR - env-registerFactory( env, channel, socket, jk_channel_apr_socket_factory ); -#else - env-registerFactory( env, channel, socket, jk_channel_socket_factory ); + env-registerFactory( env, channel, apr, +jk_channel_apr_socket_factory ); #endif - env-registerFactory( env, handler, response, jk_handler_response_factory ); + env-registerFactory( env, channel, socket, jk_channel_socket_factory ); + + env-registerFactory( env, handler, response, +jk_handler_response_factory ); env-registerFactory( env, handler, logon, jk_handler_logon_factory ); env-registerFactory( env, handler, discovery, jk_handler_discovery_factory ); @@ -126,6 +129,7 @@ #ifdef HAVE_JNI env-registerFactory( env, worker, jni, jk_worker_jni_factory ); + env-registerFactory( env, channel,jni, jk_channel_jni_factory ); #endif #ifdef AJP12 env-registerFactory( env, worker, ajp12, jk_worker_ajp12_factory ); 1.4 +5 -1 jakarta-tomcat-connectors/jk/native2/common/jk_registry.h Index: jk_registry.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_registry.h,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jk_registry.h 31 Dec 2001 22:25:03 - 1.3 +++ jk_registry.h 12 Jan 2002 05:09:50 - 1.4 @@ -62,7 +62,7 @@ /*** * Description: Worker list* - * Version: $Revision: 1.3 $ * + * Version: $Revision: 1.4 $ * ***/ /** Static declarations for all 'hardcoded' modules. This is a hack, @@ -99,6 +99,10 @@ const char *type, const char *name); int JK_METHOD jk_worker_status_factory(jk_env_t *env, jk_pool_t *pool, + void **result, + const char *type, const char *name); + +int JK_METHOD jk_worker_run_factory(jk_env_t *env, jk_pool_t *pool, void **result, const char *type, const char *name); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_workerEnv.c
costin 02/01/11 21:15:35
Modified:jk/native2/common jk_workerEnv.c
Log:
Add the things we know at compile time into the properties.
( when we build the library for windows or unix it's likely we'll figure the
path separator instead of asking the user to type it ).
( should probably use apr equivalent )
Revision ChangesPath
1.13 +15 -2 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.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- jk_workerEnv.c31 Dec 2001 19:18:48 - 1.12
+++ jk_workerEnv.c12 Jan 2002 05:15:35 - 1.13
@@ -59,7 +59,7 @@
* Description: Workers controller *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Author: Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.12 $ *
+ * Version: $Revision: 1.13 $ *
***/
#include jk_workerEnv.h
@@ -196,7 +196,7 @@
tmp = jk_map_getString(env, init_data, worker.list,
DEFAULT_WORKER );
worker_list=jk_map_split( env, init_data, init_data-pool,
- tmp, _this-num_of_workers );
+ tmp, NULL, _this-num_of_workers );
if(worker_list==NULL || _this-num_of_workers= 0 ) {
/* assert() - we pass default worker, we should get something back */
@@ -570,6 +570,19 @@
_this-init_data = NULL;
jk_map_default_create(env, _this-init_data, pool);
+/* Add 'compile time' settings. Those are defined in jk_global,
+ with the other platform-specific settings. No need to ask
+ the user what we can find ourself
+*/
+_this-init_data-put( env, _this-init_data, fs,
+ FILE_SEPARATOR_STR, NULL );
+_this-init_data-put( env, _this-init_data, ps,
+ PATH_SEPARATOR_STR, NULL );
+_this-init_data-put( env, _this-init_data, so,
+ SO_EXTENSION, NULL );
+_this-init_data-put( env, _this-init_data, arch,
+ ARCH, NULL );
+
_this-worker_file = NULL;
_this-log_file= NULL;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_status.c
costin 02/01/11 21:20:18
Modified:jk/native2/common jk_worker_status.c
Log:
More code to display status information on the jni worker. Very good for
debugging ( especially lb ).
Revision ChangesPath
1.2 +162 -30 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.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- jk_worker_status.c31 Dec 2001 20:37:01 - 1.1
+++ jk_worker_status.c12 Jan 2002 05:20:17 - 1.2
@@ -76,21 +76,167 @@
#define JK_BUF_SIZE 4096
-typedef struct {
+typedef struct jk_buff {
int pos;
int size;
char *buf;
+
+jk_ws_service_t *s;
+
+void (*jkprintf)( jk_env_t *env, struct jk_buff *buf, char *frm,... );
+void (*flush)( jk_env_t *env );
} jk_buff_t;
+static void jk_printf( jk_env_t *env, jk_buff_t *buf, char *fmt,... )
+{
+va_list vargs;
+int ret=0;
+
+va_start(vargs,fmt);
+buf-pos=0; /* Temp - we don't buffer */
+ret=apr_vsnprintf(buf-buf + buf-pos, buf-size - buf-pos, fmt, vargs);
+va_end(vargs);
+
+buf-s-write( env, buf-s, buf-buf, strlen(buf-buf) );
+fprintf(stderr, Writing %d %s \n, ret, buf-buf);
+}
+
+static void jk_worker_status_displayWorkers( jk_env_t *env, jk_buff_t *buf,
+ jk_workerEnv_t *wenv )
+{
+jk_map_t *map=wenv-worker_map;
+int i;
+
+jk_printf(env, buf, H2Workers/H2\n );
+jk_printf(env, buf, table border\n);
+
+jk_printf(env, buf, trthName/ththRetries/th
+ thErr/ththRecovery/th/tr);
+
+for( i=0; i map-size( env, map ) ; i++ ) {
+char *name=map-nameAt( env, map, i );
+jk_worker_t *worker=(jk_worker_t *)map-valueAt( env, map,i );
+
+jk_printf(env, buf, tr id='worker.%s', name );
+jk_printf(env, buf, td class='name'%s/td, name );
+jk_printf(env, buf, td class='connect_retry'%d/td,
+ worker-connect_retry_attempts );
+jk_printf(env, buf, td class='in_error'%d/td,
+ worker-in_error_state );
+jk_printf(env, buf, td class='in_error'%d/td,
+ worker-in_recovering );
+
+/* Endpoint cache ? */
+
+/* special case for status worker */
+
+jk_printf(env, buf, /tr );
+}
+jk_printf(env, buf, /table\n);
+}
+
+static void jk_worker_status_displayWorkerEnv( jk_env_t *env, jk_buff_t *buf,
+ jk_workerEnv_t *wenv )
+{
+jk_map_t *map=wenv-init_data;
+int i;
+
+jk_printf(env, buf, H2Worker Env Info/H2\n);
+
+jk_printf(env, buf, table border\n);
+jk_printf(env, buf, trthnum_workers/th
+ td id='workersCount'%d/td/tr\n,
+ wenv-num_of_workers);
+/* Could be modified dynamically */
+jk_printf(env, buf, trthLogLevel/th
+ td id='logLevel'%d/td/tr\n,
+ wenv-log_level);
+
+jk_printf(env, buf, /table\n);
+
+jk_printf(env, buf, H3Properties/H3\n);
+jk_printf(env, buf, table border\n);
+jk_printf(env, buf, trthName/ththValue/td/tr\n);
+for( i=0; i map-size( env, map ) ; i++ ) {
+char *name=map-nameAt( env, map, i );
+char *value=(char *)map-valueAt( env, map,i );
+
+jk_printf(env, buf, trtd%s/tdtd%s/td/tr, name,
+ value);
+}
+jk_printf(env, buf, /table\n);
+
+}
+
+static void jk_worker_status_displayWebapps( jk_env_t *env, jk_buff_t *buf,
+ jk_workerEnv_t *wenv )
+{
+jk_map_t *map=wenv-webapps;
+int i;
+
+jk_printf(env, buf, H2Webapps/H2\n);
+
+if( map==NULL ) {
+jk_printf(env, buf, None\n);
+return;
+}
+
+jk_printf(env, buf, table border\n);
+
+jk_printf(env, buf, trthName/ththDocBase/th
+ thMappings/th/tr);
+
+for( i=0; i map-size( env, map ) ; i++ ) {
+char *name=map-nameAt( env, map, i );
+jk_webapp_t *webapp=(jk_webapp_t *)map-valueAt( env, map,i );
+
+jk_printf(env, buf, tr id='webapp.%s', name );
+jk_printf(env, buf, td class='name'%s/td, name );
+jk_printf(env, buf, /tr );
+}
+
+
+jk_printf(env, buf, /table\n);
+}
+
+/* Channels and connections, including 'pooled' ones
+ */
+static void jk_worker_status_displayConnections( jk_env_t *env, jk_buff_t *buf,
+ jk_workerEnv_t *wenv )
+{
+jk_printf(env, buf, H2Active
cvs commit: jakarta-tomcat-connectors/jk/native2/jni jk_jni_aprImpl.c
costin 02/01/11 21:25:09
Modified:jk/native2 CHANGES.html build.xml
jk/native2/jni jk_jni_aprImpl.c
Log:
Document some of the changes. Move some of the code did by Jean-Francisc in
jk_jni_aprImpl.
The whole thing will disapear as soon as apr adds the support.
Revision ChangesPath
1.4 +26 -0 jakarta-tomcat-connectors/jk/native2/CHANGES.html
Index: CHANGES.html
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/CHANGES.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CHANGES.html 17 Dec 2001 07:17:08 - 1.3
+++ CHANGES.html 12 Jan 2002 05:25:08 - 1.4
@@ -18,6 +18,17 @@
efficient./li
li
/ul
+
+liJNI worker. Most options on the jni worker are now optional, jk can detect
+and set them automcatically. This reduce the effort needed to configure jni.
+It is _required_ that LD_LIBRARY_PATH or equivalent is set coreclty, otherwise
+java will not start and apache will crash. ( on windows this may not be needed ).
+The user must set either as environment variables or in httpd.conf ( using JkSet )
+or in workers.properties: JAVA_HOME, TOMCAT_HOME ( or CATALINA_HOME ). Jk must
+be installed in the standard location ( modules/ or webapps/. The output from
+the vm will go in apache's error.log ( like all other jk output ) unless
+a special file is requested.
+
/ul
h4Developer specific/h4
@@ -54,6 +65,21 @@
liMethod signatures. Jk2 uses the same 'patterns' as jni, with a jk_env as
first parameter, then 'this' (the pointer to the object ), then regular parameters.
The same pattern is used no consistently in all methods.
+
+liJNI has been refactored. On file, jk_vmutil deals with the creation of the
+vm and guessing of all properties needed to create a java vm. It could be possible
+to create specialized instances of jk_vmutil for different vms ( the default
+works for most ).
+
+liJNI now uses the channel abstraction to send/receive messages. In future we
+could refine this to use a special 'marshalling' that will map 'messages' into
+method invocations. One big benefit is that we can now reuse all objects, no
+longer need to use strings ( and thus enable the solving of most i18n problems ).
+The code is also more 'uniform' and easier to extend.
+
+liJNI worker is no longer singleton and can be used to start multiple java
+programms in the same process. Probably not very usefull for jk in particular,
+but the restriction was not needed.
li(not completed) Error handling. The env parameter will provide a mechanism to
pass error information up the stack ( eventually a stack trace ). It'll also
1.11 +7 -30 jakarta-tomcat-connectors/jk/native2/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/build.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- build.xml 6 Jan 2002 09:06:02 - 1.10
+++ build.xml 12 Jan 2002 05:25:08 - 1.11
@@ -43,7 +43,7 @@
!-- Targets --
- target name=main depends=init,apache20,jni,unixsocket
+ target name=main depends=init,apache20,jni
/target
target name=init
@@ -77,6 +77,9 @@
info=Use the MD5 implementation that is part of apache2 /
def name=HAS_APR
info=Allow APR specific extensions /
+ def name=HAVE_JNI
+info=Jni worker /
+ def name=HPUX11 if=hpux /
src dir=.
include name=server/apache2/*.c /
include name=common/*.c /
@@ -89,6 +92,7 @@
include name=${native.dir}/include /
include name=${java.home}/../include /
include name=${java.home}/../include/linux if=linux /
+include name=${java.home}/../include/hp-ux if=hpux /
/includes
depends
fileset dir=${native.dir}/common includes=*.h /
@@ -128,6 +132,7 @@
include name=${java.home}/../include/win32 if=win32 /
include name=${java.home}/../include/linux if=linux /
+include name=${java.home}/../include/linux if=linux /
/includes
depends
fileset dir=${native.dir}/common includes=*.h /
@@ -156,6 +161,7 @@
linkOpt value=-threadname quot;JK_JNI Threadquot; if=netware /
linkOpt value=-stacksize 64000 if=netware /
+ def name=HPUX11 if=hpux /
def name=WIN32 if=win32 /
def name=NDEBUG if=win32 /
def name=_WINDOWS if=win32 /
@@ -406,33 +412,4 @@
/delete
/target
- target name=unixsocket depends=init if=useunixsocket
-mkdir dir=${jk.build}/WEB-INF/jk2/unixsocket /
-so
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c
costin 02/01/11 21:27:39
Modified:jk/native build.xml
jk/native/common jk_lb_worker.c
Log:
Few changes to make it build on hpux.
A small fix in lb worker - try once more to connect to the host
where the session is located before giving up. This should solve
a lb bug which may happen in some cases.
Revision ChangesPath
1.27 +9 -1 jakarta-tomcat-connectors/jk/native/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/build.xml,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- build.xml 4 Jan 2002 05:13:31 - 1.26
+++ build.xml 12 Jan 2002 05:27:39 - 1.27
@@ -80,7 +80,8 @@
include name=${novellndk.dir}/include/nlm if=netware /
include name=${novellndk.dir}/include if=netware /
include name=${java.home}/../include/netware if=netware /
-
+include name=${java.home}/../include/hp-ux if=hpux /
+include name=${java.home}/../include/linux if=linux /
include name=${java.home}/../include/win32 if=win32 /
/includes
depends
@@ -109,6 +110,8 @@
linkOpt value=-threadname quot;JK_JNI Threadquot; if=netware /
linkOpt value=-stacksize 64000 if=netware /
+ def name=HPUX11 if=hpux /
+
def name=WIN32 if=win32 /
def name=DEBUG if=win32.debug /
def name=NDEBUG if=win32.release /
@@ -140,6 +143,7 @@
info=Reuse the worker endpoint, using per thread data /
def name=USE_APACHE_MD5
info=Use the MD5 implementation that is part of apache2 /
+ def name=HPUX11 if=hpux /
apacheConfig apxs=${apxs20} /
jniConfig /
src dir=.
@@ -153,6 +157,7 @@
include name=${apache2.include} /
include name=${java.home}/../include /
include name=${java.home}/../include/win32 if=win32 /
+include name=${java.home}/../include/hp-ux if=hpux /
/includes
depends
fileset dir=${native.dir}/common includes=*.h /
@@ -207,6 +212,7 @@
include name=${apache13.home}/os/win32 if=win32 /
include name=${java.home}/../include/win32 if=win32 /
+include name=${java.home}/../include/hp-ux if=hpux /
include name=${native.dir}/common if=win32 /
/includes
depends
@@ -223,6 +229,8 @@
def name=USE_SPRINTF if=netware
info=Use the sprintf function to build strings /
+ def name=HPUX11 if=hpux /
+
def name=WIN32 if=win32 /
def name=DEBUG if=win32.debug /
def name=NDEBUG if=win32.release /
1.8 +10 -5 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
Index: jk_lb_worker.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_lb_worker.c4 Dec 2001 19:44:23 - 1.7
+++ jk_lb_worker.c12 Jan 2002 05:27:39 - 1.8
@@ -60,7 +60,7 @@
* several workers. *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Based on: *
- * Version: $Revision: 1.7 $ *
+ * Version: $Revision: 1.8 $ *
***/
#include jk_pool.h
@@ -246,7 +246,7 @@
}
static worker_record_t *get_most_suitable_worker(lb_worker_t *p,
- jk_ws_service_t *s)
+ jk_ws_service_t *s, int attempt)
{
worker_record_t *rc = NULL;
double lb_min = 0.0;
@@ -256,7 +256,11 @@
if(session_route) {
for(i = 0 ; i p-num_of_workers ; i++) {
if(0 == strcmp(session_route, p-lb_workers[i].name)) {
-if(p-lb_workers[i].in_error_state) {
+/* First attempt will allways be to the
+ correct host. If this is indeed down and no
+ hope of recovery, we'll go to fail-over
+*/
+if(attempt0 p-lb_workers[i].in_error_state) {
break;
} else {
return (p-lb_workers[i]);
@@ -305,13 +309,14 @@
if(e e-endpoint_private s is_recoverable_error) {
lb_endpoint_t *p = e-endpoint_private;
jk_endpoint_t *end = NULL;
+int attempt=0;
/* you can not recover on
cvs commit: jakarta-tomcat-connectors/jk build.xml
costin 02/01/11 21:28:48
Modified:jk build.xml
Log:
Fix the build ( if only 3.3 is installed )
Revision ChangesPath
1.20 +2 -2 jakarta-tomcat-connectors/jk/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- build.xml 20 Dec 2001 19:30:25 - 1.19
+++ build.xml 12 Jan 2002 05:28:48 - 1.20
@@ -97,7 +97,7 @@
/target
target name=build-main
-depends=prepare,report,jkutil,jkjava,jkant /
+depends=prepare,report,jkutil,jkjava,jkant,install-t40 /
!-- Building --
@@ -114,6 +114,7 @@
exclude name=org/apache/jk/server/tomcat33/**
unless=tomcat33.detect/
exclude name=org/apache/jk/server/tomcat40/**
unless=tomcat40.detect/
exclude name=org/apache/jk/** unless=tomcat33.detect/
+ exclude name=org/apache/catalina/** unless=tomcat40.detect/
classpath refid=build-main.classpath/
/javac
@@ -186,7 +187,6 @@
file=${jk.build}/WEB-INF/lib/tomcat-util.jar/
copy todir=${tomcat40.home}/server/lib
file=${jk.build}/WEB-INF/lib/ajp.jar/
-echo message=Don't forget to add the connector to
${tomcat40.home}/conf/server.xml /
/target
target name=install-t41 if=tomcat41.detect
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/conf web.xml
costin 02/01/11 21:29:56 Modified:jk/conf web.xml Log: The config file Revision ChangesPath 1.3 +8 -13 jakarta-tomcat-connectors/jk/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/conf/web.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- web.xml 6 Jan 2002 08:58:31 - 1.2 +++ web.xml 12 Jan 2002 05:29:56 - 1.3 @@ -7,12 +7,16 @@ web-app servlet servlet-nameJkServlet/servlet-name +descriptionServlet implementing the jk connector. Make sure 'load-on-startup' is set if you +are using tomcat3.3 or 4.1. For 4.0 you must use JkServlet40./description servlet-classorg.apache.jk.server.JkServlet/servlet-class + init-param param-namelistenAddress/param-name param-value/param-value -descriptionAddress to listen on. Default to WEB-INF/work/tomcatSocket -for unix domain sockets and pipes and 8089 for TCP/description +descriptionAddress to listen on. Default to +WEB-INF/work/tomcatSocket for unix domain sockets and pipes and 8089 for + TCP/description /init-param init-param @@ -22,22 +26,13 @@ for unix sockets, org.apache.jk.common.ChannelSocket for TCP. XXX multi-value, multiple channels ?/description /init-param - load-on-startup1/load-on-startup /servlet -!-- Hack - this will be loaded if 4.0 is detected. It'll not be loaded at - startup, and 3.3 will just ignore it. We need JkServlet to be a 'plain' - servlet, with no dependencies ( so it loads and log messages in any - condition ). It'll use Class.forName or other means to load container - specific classes. In particular, for 4.0 the only way for a trusted - app to gain access to the container is by a servlet starting with 'o.a.catalina' - and implementing a specific interface. The servlet seem to need to be - declared here, so we can play our init tricks. In future we hope for - a cleaner mechanism. -- +!-- servlet servlet-nameJkServlet40/servlet-name servlet-classorg.apache.catalina.jk.JkServlet40/servlet-class /servlet - +-- /web-app -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/compilers CcCompiler.java CompilerAdapter.java LibtoolCompiler.java LibtoolLinker.java
costin 02/01/11 21:33:03
Modified:jk/jkant/java/org/apache/jk/ant/compilers CcCompiler.java
CompilerAdapter.java LibtoolCompiler.java
LibtoolLinker.java
Log:
Use 'cc' by default ( it works on both systems using gcc and cc, the reverse is
not true ).
Don't add the gcc warning options unless gcc is explicitely added.
Define the os automatically, since java knows it. This could simplify some
build files.
Revision ChangesPath
1.8 +25 -22
jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/compilers/CcCompiler.java
Index: CcCompiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/compilers/CcCompiler.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CcCompiler.java 12 Dec 2001 22:09:16 - 1.7
+++ CcCompiler.java 12 Jan 2002 05:33:03 - 1.8
@@ -84,18 +84,19 @@
return co_mapper.mapFileName( name );
}
-
+
+String cc;
+
/** Compile using 'standard' gcc flags. This assume a 'current' gcc on
* a 'normal' platform - no need for libtool
*/
-
public void compileSingleFile(Source sourceObj) throws BuildException {
File f=sourceObj.getFile();
String source=f.toString();
Commandline cmd = new Commandline();
- String cc=project.getProperty(build.native.cc);
- if(cc==null) cc=gcc;
+ cc=project.getProperty(build.native.cc);
+ if(cc==null) cc=cc;
cmd.setExecutable( cc );
@@ -123,24 +124,26 @@
if( optWgcc ) {
cmd.createArgument().setValue(-W);
-
-//cmd.createArgument().setValue(-Wall);
-cmd.createArgument().setValue(-Wimplicit);
-cmd.createArgument().setValue(-Wreturn-type);
-cmd.createArgument().setValue(-Wcomment);
-cmd.createArgument().setValue(-Wformat);
-cmd.createArgument().setValue(-Wchar-subscripts);
-cmd.createArgument().setValue(-O);
-cmd.createArgument().setValue(-Wuninitialized);
-
-// Non -Wall
-// cmd.createArgument().setValue(-Wtraditional);
-// cmd.createArgument().setValue(-Wredundant-decls);
- cmd.createArgument().setValue(-Wmissing-declarations);
- cmd.createArgument().setValue(-Wmissing-prototypes);
-// cmd.createArgument().setValue(-Wconversions);
- cmd.createArgument().setValue(-Wcast-align);
-// cmd.createArgument().setValue(-pedantic );
+
+if( cc!= null cc.indexOf( gcc ) = 0 ) {
+//cmd.createArgument().setValue(-Wall);
+cmd.createArgument().setValue(-Wimplicit);
+cmd.createArgument().setValue(-Wreturn-type);
+cmd.createArgument().setValue(-Wcomment);
+cmd.createArgument().setValue(-Wformat);
+cmd.createArgument().setValue(-Wchar-subscripts);
+cmd.createArgument().setValue(-O);
+cmd.createArgument().setValue(-Wuninitialized);
+
+// Non -Wall
+// cmd.createArgument().setValue(-Wtraditional);
+// cmd.createArgument().setValue(-Wredundant-decls);
+cmd.createArgument().setValue(-Wmissing-declarations);
+cmd.createArgument().setValue(-Wmissing-prototypes);
+// cmd.createArgument().setValue(-Wconversions);
+cmd.createArgument().setValue(-Wcast-align);
+// cmd.createArgument().setValue(-pedantic );
+}
}
}
protected void addOptimize( Commandline cmd ) {
1.8 +4 -1
jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/compilers/CompilerAdapter.java
Index: CompilerAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/jkant/java/org/apache/jk/ant/compilers/CompilerAdapter.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- CompilerAdapter.java 12 Dec 2001 22:09:16 - 1.7
+++ CompilerAdapter.java 12 Jan 2002 05:33:03 - 1.8
@@ -297,7 +297,10 @@
}
protected void addDefines( Commandline cmd ) {
- if( defines.size() 0 ) {
+// Define by default the OS ( as known to java )
+String os=System.getProperty(java.os);
+
+if( defines.size() 0 ) {
Enumeration defs=defines.elements();
while( defs.hasMoreElements() ) {
Def d=(Def)defs.nextElement();
1.8
cvs commit: jakarta-tomcat/proposals/URLStreamHandler - New directory
billbarker02/01/11 21:54:32 jakarta-tomcat/proposals/URLStreamHandler - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF - New directory
billbarker02/01/11 21:54:48 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes - New directory
billbarker02/01/11 21:55:04 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org - New directory
billbarker02/01/11 21:55:14 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache - New directory
billbarker02/01/11 21:55:24 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat - New directory
billbarker02/01/11 21:55:36 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util - New directory
billbarker02/01/11 21:55:47 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules - New directory
billbarker02/01/11 21:55:47 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net - New directory
billbarker02/01/11 21:55:55 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config - New directory
billbarker02/01/11 21:56:28 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net StreamHandlerFactory.java
billbarker02/01/11 22:37:58 Added: proposals/URLStreamHandler Tag: tomcat_33_final build.xml proposals/URLStreamHandler/WEB-INF Tag: tomcat_33_final interceptors.xml proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config Tag: tomcat_33_final StreamHandler.java proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net Tag: tomcat_33_final StreamHandlerFactory.java Log: Restoring StreamHandler functionality as a module. This does basically the same thing that was previously hard-coded into the Tomcat API. The only difference is that it is now optional. SOAP users et. al. only need to install the StreamHandler.war file in the modules directory to get the new behavior. Revision ChangesPath No revision No revision 1.1.2.1 +82 -0 jakarta-tomcat/proposals/URLStreamHandler/Attic/build.xml No revision No revision 1.1.2.1 +8 -0 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/Attic/interceptors.xml No revision No revision 1.1.2.1 +147 -0 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config/Attic/StreamHandler.java No revision No revision 1.1.2.1 +164 -0 jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net/Attic/StreamHandlerFactory.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net StreamHandlerFactory.java
billbarker02/01/11 22:43:03 Removed: proposals/URLStreamHandler Tag: tomcat_33_final build.xml proposals/URLStreamHandler/WEB-INF Tag: tomcat_33_final interceptors.xml proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config Tag: tomcat_33_final StreamHandler.java proposals/URLStreamHandler/WEB-INF/classes/org/apache/tomcat/util/net Tag: tomcat_33_final StreamHandlerFactory.java Log: Undoing a bad commit. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util/net StreamHandlerFactory.java
billbarker02/01/11 23:08:40 Added: proposals/StreamHandler build.xml proposals/StreamHandler/WEB-INF interceptors.xml proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config StreamHandler.java proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util/net StreamHandlerFactory.java Log: Restoring StreamHandler functionality as a module. This does basically the same thing that was previously hard-coded into the Tomcat API. The only difference is that it is now optional. SOAP users et. al. only need to install the StreamHandler.war file in the modules directory to get the new behavior. Revision ChangesPath 1.2 +82 -0 jakarta-tomcat/proposals/StreamHandler/build.xml 1.2 +8 -0 jakarta-tomcat/proposals/StreamHandler/WEB-INF/interceptors.xml 1.2 +147 -0 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/modules/config/StreamHandler.java 1.2 +164 -0 jakarta-tomcat/proposals/StreamHandler/WEB-INF/classes/org/apache/tomcat/util/net/StreamHandlerFactory.java -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
