/dev/urandom patch
Don't know if the patch for this was missed (since it was buried into a
long e-mail), you guys didn't like it or just didn't have time to
implement. Anyway, I'm doing it clean in this e-mail. Thanks to Doug
Barnes who explained the issues of random number generation...
Here is the patch (I had to move some of the code to engineInit,
hopefully without breaking too many things):
Cut -
---jakarta-tomcat-3.3-build/src/share/org/apache/tomcat/modules/session/SessionIdGenerator.java
Mon Apr 16 21:28:34 2001
+++jakarta-tomcat-3.3-src-cvs-debug/src/share/org/apache/tomcat/modules/session/SessionIdGenerator.java
+
Mon Apr 16 21:40:20 2001
@@ -96,6 +96,8 @@
String randomClassName=null;
Random randomSource=null;
DataInputStream randomIS=null;
+boolean beParanoid=false;
+boolean useDevRandom=false;
static Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
@@ -109,18 +111,26 @@
randomSource=createRandomClass( randomClassName );
}
-/** Use /dev/random special device. This is new code, but may
reduce the
- * big delay in generating the random
+/** When using special device random generator, be paranoid and
+ * use /dev/random. When this option is not set (default), the
+ * device /dev/urandom is used, which should be at least as safe
+ * as java.security.SecureRandom.
+ *
+ * Reads to /dev/random might block until additional environmental
+ * noise is gathered and this can cause problems (ie. Tomcat might
+ * hang until such noise is generated).
+ * USE WITH CAUTION!!!
+ */
+public void setBeParanoid( boolean p ) {
+beParanoid = p;
+}
+
+
+/** Use special device to generate random. This is new code,
+ * but may reduce the big delay in generating the random.
*/
public void setUseDevRandom( boolean u ) {
- if( ! u ) return;
- try {
- randomIS= new DataInputStream( new
FileInputStream("/dev/random"));
- randomIS.readLong();
- log( "Opening /dev/random");
- } catch( IOException ex ) {
- randomIS=null;
- }
+useDevRandom = u;
}
@@ -141,6 +151,23 @@
/** Init session management stuff for this context.
*/
public void engineInit(ContextManager cm) throws TomcatException {
+if( useDevRandom ){
+String device="/dev/urandom";
+
+if( beParanoid )
+device="/dev/random";
+
+ try {
+ randomIS= new DataInputStream( new FileInputStream(
device ));
+ randomIS.readLong();
+ log( "Opening " + device );
+ } catch( IOException ex ) {
+ randomIS=null;
+ }
+}
+
+ /* The following code gets executed even if randomIS is null due
to
+ IOException above, so we are covered */
if( randomSource==null randomIS==null ) {
String randomClass=(String)cm.getProperty("randomClass" );
if( randomClass==null ) {
@@ -261,7 +288,7 @@
if( devRandomIS!=null ) {
try {
n=devRandomIS.readLong();
- System.out.println("Getting /dev/random " + n );
+System.out.println( "Getting from random device " + n
);
} catch( IOException ex ) {
ex.printStackTrace();
}
Cut -
Bojan
cvs commit: jakarta-tomcat/proposals/jasper34 - Imported sources
melaquias01/04/18 03:37:23 Log: Initial submission of Jasper34 Refactoring proposal Status: Vendor Tag: jakarta Release Tags: proposal_0 N jakarta-tomcat/proposals/jasper34/JasperToolkit.html N jakarta-tomcat/proposals/jasper34/model/about.html N jakarta-tomcat/proposals/jasper34/model/help-doc.html N jakarta-tomcat/proposals/jasper34/model/index-all.html N jakarta-tomcat/proposals/jasper34/model/index.html N jakarta-tomcat/proposals/jasper34/model/navigation.jar N jakarta-tomcat/proposals/jasper34/model/overview-frame.html N jakarta-tomcat/proposals/jasper34/model/overview-summary.html N jakarta-tomcat/proposals/jasper34/model/overview-tree.html N jakarta-tomcat/proposals/jasper34/model/stylesheet.css N jakarta-tomcat/proposals/jasper34/model/model-tree/false.gif N jakarta-tomcat/proposals/jasper34/model/model-tree/model.tree N jakarta-tomcat/proposals/jasper34/model/model-tree/true.gif N jakarta-tomcat/proposals/jasper34/model/model-tree/tv-class.gif N jakarta-tomcat/proposals/jasper34/model/model-tree/tv-interface.gif N jakarta-tomcat/proposals/jasper34/model/model-tree/tv-physical-package.gif N jakarta-tomcat/proposals/jasper34/model/model-tree/tv-pkg-diagram.gif N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/jasper34.cl.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/package-frame.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/package-summary.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/package-tree.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/package-use.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/doc-files/jasper34.cl.gif N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/doc-files/jasper34.cl.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/package-frame.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/package-summary.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/package-tree.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/package-use.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/resources.cl.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/doc-files/resources.cl.gif N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/resources/doc-files/resources.cl.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/JspServlet.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/JspServletLoader.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/JspServletPageHandler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/JspServletRequestHandler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/JspServletToolkit.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/package-frame.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/package-summary.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/package-tree.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/package-use.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/servlet.cl.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/class-use/JspServlet.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/class-use/JspServletLoader.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/class-use/JspServletPageHandler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/class-use/JspServletRequestHandler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/class-use/JspServletToolkit.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/doc-files/servlet.cl.gif N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/servlet/doc-files/servlet.cl.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/JasperToolkit.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/JavaCompiler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/JspCompiler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/JspPageHandler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/JspRequestHandler.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/package-frame.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/package-summary.html N jakarta-tomcat/proposals/jasper34/model/org/apache/jasper34/toolkit/package-tree.html N
[PATCH] ParserController.java (jasper include bug)
I think I have found a little bug in jasper of TomCat-4.0.
When jsp-file (1) contains include-file (2)
and this include-file (2) contains another include-file (3), then
jasper does not find include-file (3) if all files are stored not in root
directory of current web application.
For example, I have following directories structure:
- myapp
|- file.jsp
|- include.jsp
|- include-for-include.jsp
|- subfolder
| |- subfolder-file.jsp
| |- subfolder-include.jsp
| |- subfolder-include-for-include.jsp
|- WEB-INF
Jasper can successfully compile "file.jsp" with all includes.
But it could not compile "subfolder-file.jsp" because it tries to
load file "subfolder-include-for-include.jsp" from path
"myapp/subfolder-include-for-include.jsp" against correct
path "myapp/subfolder/subfolder-include-for-include.jsp".
The source file which corresponds to this problem is
"jakarta-tomcat-4.0/src/jasper/src/share/org/apache/jasper/compiler/ParserController.java".
I have added one line to this file and all works fine now, new line is
marked with "NEW LINE" comment:
=== DIFF ===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.14
diff -w -i -r1.14 ParserController.java
428a429
(isAbsolute ? "" : (String)baseDirStack.peek()) + // NEW LINE
=== DIFF ===
The changed function is "resolveFileName":
=== ParserController.java, starting at line 422
===
private String resolveFileName(String inFileName) {
File file = new File(inFileName);
boolean isAbsolute = file.getPath().startsWith(File.separator);
String fileName =
isAbsolute ?
inFileName : (String)baseDirStack.peek() + inFileName;
String baseDir =
(isAbsolute ? "" : (String)baseDirStack.peek()) + // == NEW LINE
inFileName.substring(0, file.getPath().lastIndexOf(File.separator) + 1);
baseDirStack.push(baseDir);
return fileName;
}
=== ParserController.java ===
(I am using Tomcat-4.0 nightly build from 2001.04.16 under
Windows NT 4 and jdk-1.3)
Thank you for your time.
Best Regards,
Andrei Prygounkov,
[EMAIL PROTECTED] or [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/jasper34 - Imported sources
melaquias01/04/18 03:39:39 Log: Initial submission of Jasper34 Refactoring proposal source code Status: Vendor Tag: jakarta Release Tags: proposal_0 N jakarta-tomcat/src/jasper34/org/apache/jasper34/resources/Toolkit.properties N jakarta-tomcat/src/jasper34/org/apache/jasper34/servlet/JspServlet.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/servlet/JspServletLoader.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/servlet/JspServletPageHandler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/servlet/JspServletRequestHandler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/servlet/JspServletToolkit.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/toolkit/JasperToolkit.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/toolkit/JavaCompiler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/toolkit/JspCompiler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/toolkit/JspPageHandler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/toolkit/JspRequestHandler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/Cache.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/CacheDefaults.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/Expirable.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/JspMangler.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/JspManglerImpl.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/JspRecursiveModificationChecker.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/MapCache.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/ModificationChecker.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/PeriodicJspRecursiveModificationChecker.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/PeriodicModChecker.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/SimpleModificationChecker.java N jakarta-tomcat/src/jasper34/org/apache/jasper34/utils/TableCache.java No conflicts created by this import
Re: Jasper
--- [EMAIL PROTECTED] wrote: Hi, While Mel is working on the JspServlet proposal, I thought it would be a good idea to send my notes on jasper. I looked at both "branches" of jasper, with the idea of trying to merge them while preserving each "personality". As I expected, most of the code is still common, with only few variations that can be resolved by modularization. Unfortunately, the code requires some work in order to implement most of the optimizations I have in mind and before we can merge them. Some ideas are available at http://nagoya.apache.org/~costin/jasper.txt I don't know how much free time I'll have for that before 3.3 beta, but there are a lot of cool things that can be done in jasper ( and not only performance enhancements ). Costin, Thanks for the above thoughts (in jasper.txt). Very useful input. I'm going to more fully ingest that and merge aspects of it, where appropriate into my (really 'our') proposal. In the mean time, I've decided to get the current state of jasper34 checked in for you and others to start to take a look at it. Everything is checked in to CVS in two folders: jakarta-tomcat/proposals/jasper34 jakarta-tomcat/src/jasper34 Please peruse the above after you do an update and give me your feedback. Everything is in it's infancy and subject to change, so be kind :-) Cheers, Mel __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Jasper
--- Mel Martinez [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: Hi, While Mel is working on the JspServlet proposal, I thought it would be a good idea to send my notes on jasper. I looked at both "branches" of jasper, with the idea of trying to merge them while preserving each "personality". As I expected, most of the code is still common, with only few variations that can be resolved by modularization. Unfortunately, the code requires some work in order to implement most of the optimizations I have in mind and before we can merge them. Some ideas are available at http://nagoya.apache.org/~costin/jasper.txt I don't know how much free time I'll have for that before 3.3 beta, but there are a lot of cool things that can be done in jasper ( and not only performance enhancements ). Costin, Thanks for the above thoughts (in jasper.txt). Very useful input. I'm going to more fully ingest that and merge aspects of it, where appropriate into my (really 'our') proposal. In the mean time, I've decided to get the current state of jasper34 checked in for you and others to start to take a look at it. Everything is checked in to CVS in two folders: jakarta-tomcat/proposals/jasper34 jakarta-tomcat/src/jasper34 Please peruse the above after you do an update and give me your feedback. Everything is in it's infancy and subject to change, so be kind :-) FYI: for those who don't have or want to have tc3.3 checked out, you can also access the proposal via CVSWeb by using the link: http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/jasper34/JasperToolkit.html I expect this document to undergo rapid and dramatic changes, so check back occasionally on it. Mel __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/facade HttpServletResponseFacade.java
Marc,
In terms of connectors, I think request.isSecure() only works with ajp13.
So, if a user is connected via ajp12, and the web server tries to do a
url-rewriting of an https URL, I think this code will get it wrong. It
might be better to check the request url itself to see if it begins with
"https://" (case-insensitively).
-Dan
[EMAIL PROTECTED] wrote:
marcsaeg01/04/16 09:02:13
Modified:src/share/org/apache/tomcat/facade Tag: tomcat_32
HttpServletResponseFacade.java
Log:
Completes the fix for Bugzilla 578. In addtion to needing the protocol handler
for HTTPS, the URL encoder also needs to properly determine the default port for
secure connections in addition to normal HTTP connections.
PR: 578
Submitted by: [EMAIL PROTECTED] (Santiago Gala)
Revision ChangesPath
No revision
No revision
1.6.2.4 +10 -7
jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java
Index: HttpServletResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
retrieving revision 1.6.2.3
retrieving revision 1.6.2.4
diff -u -r1.6.2.3 -r1.6.2.4
--- HttpServletResponseFacade.java2001/03/06 17:38:13 1.6.2.3
+++ HttpServletResponseFacade.java2001/04/16 16:02:12 1.6.2.4
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
1.6.2.3 2001/03/06 17:38:13 marcsaeg Exp $
- * $Revision: 1.6.2.3 $
- * $Date: 2001/03/06 17:38:13 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
1.6.2.4 2001/04/16 16:02:12 marcsaeg Exp $
+ * $Revision: 1.6.2.4 $
+ * $Date: 2001/04/16 16:02:12 $
*
*
*
@@ -353,11 +353,14 @@
return (false);
if (!request.getServerName().equalsIgnoreCase(url.getHost()))
return (false);
-// Set the URL port to HTTP default if not available before comparing
-int urlPort = url.getPort();
-if (urlPort == -1) {
+// Set the URL port to the HTTP(S) default if not available before comparing
+int urlPort = url.getPort();
+if (urlPort == -1) {
+if(request.isSecure())
+urlPort = 443;
+else
urlPort = 80;
-}
+}
if (request.getServerPort() != urlPort)
return (false);
String contextPath = request.getContext().getPath();
--
Dan Milstein // [EMAIL PROTECTED]
Re: CVS / mod_webapp / web-connector sub-project
In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile -- specifically, mod_jk was built to handle a variety of protocols (ajp12, ajp13, etc.). So writing a protocol handler for the mod_webapp protocol would give a lot of benefits -- load-balancing, support for a variety of web servers, debugged C code. Pier had mentioned a while ago that the mod_jk code was completely incomprehensible. Gal Shachor basically wrote his own object system in C, which is very, very confusing at first. I've added a lot of comments in the 3.3 branch, particularly to common/jk_service.h, with the explicit goal of making it easier for people to write new protocol handlers and/or new web server plugins. One thing I can imagine being a problem right off the bat would be that the abstractions which allow mod_jk to deal with a variety of web servers may not support the fine-grained control over configuration which mod_webapp supports. Splitting off a connectors sub-project: I don't think I support this -- it was discussed on the list a few months ago, and my objections from then still hold. Sharing session-information around: feels way too complex -- I think there are better ways to get persistent sessions. Overloading the (already-complicated) web server/servlet container communication stream seems like asking for trouble we don't need. -Dan GOMEZ Henri wrote: Fine to see mod_webapp back to life :) 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- Dan Milstein // [EMAIL PROTECTED]
mod_webapp APR
Hi, I'm not too familiar with APR, so forgive me if this is a stupid question ;-) If APR is an Apache 2.0 feature, does this mean that mod_webapp will only work with Apache 2.0? If so - what then for Apache 1.3 connectivity to tomcat 4? -Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Re: /dev/urandom patch
Hi Bojan,
It's the third ( no time ), I am deep into some charset bugs and jasper
and most developers are busy with various projects.
You may file a feature request on bugzilla, attach you patch - this way
it'll be recorded.
Or send few more patches ( there are many open bugs, most of them are
easy to solve but require time to test and reproduce ), and you'll be
able to check in the patch yourself, as a commiter :-)
Costin
On Wed, 18 Apr 2001, Bojan Smojver wrote:
Don't know if the patch for this was missed (since it was buried into a
long e-mail), you guys didn't like it or just didn't have time to
implement. Anyway, I'm doing it clean in this e-mail. Thanks to Doug
Barnes who explained the issues of random number generation...
Here is the patch (I had to move some of the code to engineInit,
hopefully without breaking too many things):
Cut -
---jakarta-tomcat-3.3-build/src/share/org/apache/tomcat/modules/session/SessionIdGenerator.java
Mon Apr 16 21:28:34 2001
+++jakarta-tomcat-3.3-src-cvs-debug/src/share/org/apache/tomcat/modules/session/SessionIdGenerator.java
Mon Apr 16 21:40:20 2001
@@ -96,6 +96,8 @@
String randomClassName=null;
Random randomSource=null;
DataInputStream randomIS=null;
+boolean beParanoid=false;
+boolean useDevRandom=false;
static Jdk11Compat jdk11Compat=Jdk11Compat.getJdkCompat();
@@ -109,18 +111,26 @@
randomSource=createRandomClass( randomClassName );
}
-/** Use /dev/random special device. This is new code, but may
reduce the
- * big delay in generating the random
+/** When using special device random generator, be paranoid and
+ * use /dev/random. When this option is not set (default), the
+ * device /dev/urandom is used, which should be at least as safe
+ * as java.security.SecureRandom.
+ *
+ * Reads to /dev/random might block until additional environmental
+ * noise is gathered and this can cause problems (ie. Tomcat might
+ * hang until such noise is generated).
+ * USE WITH CAUTION!!!
+ */
+public void setBeParanoid( boolean p ) {
+beParanoid = p;
+}
+
+
+/** Use special device to generate random. This is new code,
+ * but may reduce the big delay in generating the random.
*/
public void setUseDevRandom( boolean u ) {
- if( ! u ) return;
- try {
- randomIS= new DataInputStream( new
FileInputStream("/dev/random"));
- randomIS.readLong();
- log( "Opening /dev/random");
- } catch( IOException ex ) {
- randomIS=null;
- }
+useDevRandom = u;
}
@@ -141,6 +151,23 @@
/** Init session management stuff for this context.
*/
public void engineInit(ContextManager cm) throws TomcatException {
+if( useDevRandom ){
+String device="/dev/urandom";
+
+if( beParanoid )
+device="/dev/random";
+
+ try {
+ randomIS= new DataInputStream( new FileInputStream(
device ));
+ randomIS.readLong();
+ log( "Opening " + device );
+ } catch( IOException ex ) {
+ randomIS=null;
+ }
+}
+
+ /* The following code gets executed even if randomIS is null due
to
+ IOException above, so we are covered */
if( randomSource==null randomIS==null ) {
String randomClass=(String)cm.getProperty("randomClass" );
if( randomClass==null ) {
@@ -261,7 +288,7 @@
if( devRandomIS!=null ) {
try {
n=devRandomIS.readLong();
- System.out.println("Getting /dev/random " + n );
+System.out.println( "Getting from random device " + n
);
} catch( IOException ex ) {
ex.printStackTrace();
}
Cut -
Bojan
Re: CVS / mod_webapp / web-connector sub-project
Henri, I think Dan is right on this one - improving the configuration of mod_jk is probably the most important thing, and merging with mod_webapp and porting it's protocol and config mechanism would be a good way to do that. I think the best way to do that would be a revolution ( like jasper34 ), and when it's ready propose it as either a replacement for both mod_jk and mod_webapp, or as a top level project ( if enough people will contribute on it ). Combining mod_jk and mod_webapp is likely to result in something better than both, so the vote to replace mod_jk and mod_webapp will be a formality :-) ( making it a top level project now is not a good idea right now, neither to do the development in the main tree - there are just few big bugs to be fixed before a 3.3 beta. ) Costin P.S. It's fun beeing a "revolutionar" ! On Wed, 18 Apr 2001, Dan Milstein wrote: In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile -- specifically, mod_jk was built to handle a variety of protocols (ajp12, ajp13, etc.). So writing a protocol handler for the mod_webapp protocol would give a lot of benefits -- load-balancing, support for a variety of web servers, debugged C code. Pier had mentioned a while ago that the mod_jk code was completely incomprehensible. Gal Shachor basically wrote his own object system in C, which is very, very confusing at first. I've added a lot of comments in the 3.3 branch, particularly to common/jk_service.h, with the explicit goal of making it easier for people to write new protocol handlers and/or new web server plugins. One thing I can imagine being a problem right off the bat would be that the abstractions which allow mod_jk to deal with a variety of web servers may not support the fine-grained control over configuration which mod_webapp supports. Splitting off a connectors sub-project: I don't think I support this -- it was discussed on the list a few months ago, and my objections from then still hold. Sharing session-information around: feels way too complex -- I think there are better ways to get persistent sessions. Overloading the (already-complicated) web server/servlet container communication stream seems like asking for trouble we don't need. -Dan GOMEZ Henri wrote: Fine to see mod_webapp back to life :) 1) You added many features interesting in building (autoconf, apr) which we could study to adapt to mod_jk (at least autoconf). 2) I plan to update the mod_webapp RPM and hope the code will compile under GCC (it wasn't the case with tc 4.0b2/b3) 3) You still didn't tell us what you think into merging mod_webapp and mod_jk. Why not use mod_webapp/mod_jk to start the web-connector sub-project allowing us to remove many question related to connectors from Tomcat user/dev lists ? The same web-connector project could be used against Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat. Any project understanding the concept of HTTP request/reply could use it. Much more what about using the connector to have the Apache store sessions (serialized) data from Tomcat. Here is the idea : - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB). - Each Tomcat have sessions related data which may be good to see available to other Tomcats in case of failure : ie: TomcatA create a session and data in that session. When replying to Apache (via mod_jk or mod_webapp) it also send the session datas (serialized) when they are created (or updated). Apache store that informations for possible future use (db1/gdb) TomcatA fail (stopped, restarted, jvm dumped...) and Apache (via at least mod_jk) decide to route the request to TomcatB. TomcatB miss the session datas allready generated by TomcatA but Apache could route the request ALONG WITH THE previously saved session informations. TomcatB could then recreate the session, set the session data and then serve the request in the same condition that TomcatA. You get a real fault-tolerant system (no need to resign in some case). What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: mod_webapp APR
On Wed, 18 Apr 2001, Thom Park wrote: Hi, I'm not too familiar with APR, so forgive me if this is a stupid question ;-) If APR is an Apache 2.0 feature, does this mean that mod_webapp will only work with Apache 2.0? If so - what then for Apache 1.3 connectivity to tomcat 4? APR (which stands for Apache Portable Runtime) has been split out from the web server development track into it's own project, because it is not really specific to a web server -- it's an abstraction layer over operating system features. Tomcat 4 will have connector support for Apache 1.3 as well as 2.0. -Thom Craig
Tester (was: cvs commit: ...etc)
[EMAIL PROTECTED] typed the following on 07:27 PM 4/17/2001 + craigmcc01/04/17 12:27:20 Restore the ability to save and reload active sessions across a web app restart. This was broken by the refactoring of the load() and unload() calls that was recently done in the session manager code. ... PLEASE run the entire "tester" suite, as well as the Watchdog 4.0 tests, to ensure that we do not introduce regressions like this on future changes. My apologies for this, I had done manual testing and thought it was OK, but should not have been so slipshod. I've now gotten the tester working, and will look into adding tests specific to PersistentManager's functionality, something I've been meaning to do for a while. I had problems getting the tester going (and gave up on it a few times previously), because it seems that, on win2k at least, there are some manual steps which must be carried out. In particular, tester.bat tells the code to expect tester.xml to be in %catalina_home%/bin, but the build process does not copy it there. The same is true for the tester webapp. Should this be handled by the build, or documented, or did I miss something? Kief
Re: Tester (was: cvs commit: ...etc)
On Wed, 18 Apr 2001, Kief Morris wrote: [EMAIL PROTECTED] typed the following on 07:27 PM 4/17/2001 + craigmcc01/04/17 12:27:20 Restore the ability to save and reload active sessions across a web app restart. This was broken by the refactoring of the load() and unload() calls that was recently done in the session manager code. ... PLEASE run the entire "tester" suite, as well as the Watchdog 4.0 tests, to ensure that we do not introduce regressions like this on future changes. My apologies for this, I had done manual testing and thought it was OK, but should not have been so slipshod. I've now gotten the tester working, and will look into adding tests specific to PersistentManager's functionality, something I've been meaning to do for a while. I had problems getting the tester going (and gave up on it a few times previously), because it seems that, on win2k at least, there are some manual steps which must be carried out. In particular, tester.bat tells the code to expect tester.xml to be in %catalina_home%/bin, but the build process does not copy it there. The same is true for the tester webapp. Should this be handled by the build, or documented, or did I miss something? Kief There are two manual steps involved - one documented, and one not (yet) documented: * To run the reload tests, tester relies on being able to log on to the "manager" web app with username "tomcat", which must be assigned role "manager" in the conf/tomcat-users.xml file. For obvious reasons, this is not the default -- you will need to add it yourself. * The default build target in the tester directory does not install tester -- it only compiles the code. To install it: cd tester ./build.sh deploy-main Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java ContextConfig.java EngineConfig.java HostConfig.java
craigmcc01/04/18 11:59:30
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
ContextConfig.java EngineConfig.java
HostConfig.java
Log:
Catalina: Restore the recognition of Logger, Realm, and Valve
elements nested inside a Context. They were only being recognized
inside a DefaultContext.
{Context,Engine,Host}Config: Inherit the debugging detail level of the
owning component to assist in debugging problems like this.
PR: Bugzilla #1370
Submitted by: Larry Karnowski [EMAIL PROTECTED]
Revision ChangesPath
1.20 +43 -37
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Catalina.java 2001/04/07 10:26:05 1.19
+++ Catalina.java 2001/04/18 18:59:22 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.19 2001/04/07 10:26:05 kief Exp $
- * $Revision: 1.19 $
- * $Date: 2001/04/07 10:26:05 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.20 2001/04/18 18:59:22 craigmcc Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/04/18 18:59:22 $
*
*
*
@@ -97,7 +97,7 @@
* /u
*
* @author Craig R. McClanahan
- * @version $Revision: 1.19 $ $Date: 2001/04/07 10:26:05 $
+ * @version $Revision: 1.20 $ $Date: 2001/04/18 18:59:22 $
*/
public class Catalina {
@@ -454,7 +454,9 @@
"configClass"));
mapper.addRule(prefix + "", mapper.addChild
("addChild", "org.apache.catalina.Container"));
+
createContextCommon(prefix, mapper);
+
}
@@ -474,28 +476,9 @@
mapper.addRule(prefix + "", mapper.setProperties());
mapper.addRule(prefix + "", mapper.addChild
("addDefaultContext",
"org.apache.catalina.core.DefaultContext"));
-mapper.addRule(prefix + "/Logger", mapper.objectCreate
- (null, "className"));
-mapper.addRule(prefix + "/Logger",
- mapper.setProperties());
-mapper.addRule(prefix + "/Logger", mapper.addChild
- ("setLogger", "org.apache.catalina.Logger"));
-
-mapper.addRule(prefix + "/Realm", mapper.objectCreate
- (null, "className"));
-mapper.addRule(prefix + "/Realm",
- mapper.setProperties());
-mapper.addRule(prefix + "/Realm", mapper.addChild
- ("setRealm", "org.apache.catalina.Realm"));
-
-mapper.addRule(prefix + "/Valve", mapper.objectCreate
- (null, "className"));
-mapper.addRule(prefix + "/Valve",
- mapper.setProperties());
-mapper.addRule(prefix + "/Valve", mapper.addChild
- ("addValve", "org.apache.catalina.Valve"));
createContextCommon(prefix, mapper);
+
}
@@ -507,19 +490,6 @@
* @param mapper The mapper we are updating
*/
protected void createContextCommon(String prefix, XmlMapper mapper) {
-mapper.addRule(prefix + "/ResourceParams", mapper.objectCreate
- ("org.apache.catalina.deploy.ResourceParams"));
-mapper.addRule(prefix + "/ResourceParams",
- mapper.setProperties());
-mapper.addRule(prefix + "/ResourceParams", mapper.addChild
- ("addResourceParams",
-"org.apache.catalina.deploy.ResourceParams"));
- mapper.addRule(prefix + "/ResourceParams/parameter",
-mapper.methodSetter("addParameter", 2));
- mapper.addRule(prefix + "/ResourceParams/parameter/name",
-mapper.methodParam(0));
- mapper.addRule(prefix + "/ResourceParams/parameter/value",
-mapper.methodParam(1));
mapper.addRule(prefix + "/Ejb", mapper.objectCreate
("org.apache.catalina.deploy.ContextEjb"));
@@ -557,6 +527,13 @@
mapper.addRule(prefix + "/Loader", mapper.addChild
("setLoader", "org.apache.catalina.Loader"));
+mapper.addRule(prefix + "/Logger", mapper.objectCreate
+ (null, "className"));
+mapper.addRule(prefix + "/Logger",
+ mapper.setProperties());
+mapper.addRule(prefix + "/Logger", mapper.addChild
+
Re: Tester (was: cvs commit: ...etc)
I had problems getting the tester going (and gave up on it a few times previously), because it seems that, on win2k at least, there are some manual steps which must be carried out. In particular, tester.bat tells the code to expect tester.xml to be in %catalina_home%/bin, but the build process does not copy it there. The same is true for the tester webapp. Should this be handled by the build, or documented, or did I miss something? Yeah, I initially had problems running tester as well since build itself doesn't copy files into %catalina_home%/bin (and manually doing it sucks). On Win2k, cd tester build deploy-main will copy the code into %catalina_home%/bin. It works great! Amy Kief
Re: Tester (was: cvs commit: ...etc)
On Wed, 18 Apr 2001, Amy Roh wrote: I had problems getting the tester going (and gave up on it a few times previously), because it seems that, on win2k at least, there are some manual steps which must be carried out. In particular, tester.bat tells the code to expect tester.xml to be in %catalina_home%/bin, but the build process does not copy it there. The same is true for the tester webapp. Should this be handled by the build, or documented, or did I miss something? Yeah, I initially had problems running tester as well since build itself doesn't copy files into %catalina_home%/bin (and manually doing it sucks). Feel free to fix the default build target :-) Craig
cvs commit: jakarta-tomcat-4.0/tester/src/bin tester.xml
craigmcc01/04/18 13:40:32
Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java
tester/src/bin tester.xml
Log:
Enhance the return value for the "Content-Language" header to include the
country code, if specified. Now, if you call
response.setLocale(new Locale("en", "US"));
the header that is created will be:
Content-Language: en-US
in accordance with the requirements of Section 3.10 of the HTTP/1.1 spec.
Revision ChangesPath
1.30 +13 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
Index: HttpResponseBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- HttpResponseBase.java 2001/03/28 05:15:14 1.29
+++ HttpResponseBase.java 2001/04/18 20:40:30 1.30
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.29 2001/03/28 05:15:14 remm Exp $
- * $Revision: 1.29 $
- * $Date: 2001/03/28 05:15:14 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
1.30 2001/04/18 20:40:30 craigmcc Exp $
+ * $Revision: 1.30 $
+ * $Date: 2001/04/18 20:40:30 $
*
*
*
@@ -99,7 +99,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.29 $ $Date: 2001/03/28 05:15:14 $
+ * @version $Revision: 1.30 $ $Date: 2001/04/18 20:40:30 $
*/
public class HttpResponseBase
@@ -778,8 +778,15 @@
super.setLocale(locale);
String language = locale.getLanguage();
- if ((language != null) (language.length() 0))
- setHeader("Content-Language", language);
+ if ((language != null) (language.length() 0)) {
+String country = locale.getCountry();
+StringBuffer value = new StringBuffer(language);
+if ((country != null) (country.length() 0)) {
+value.append('-');
+value.append(country);
+}
+ setHeader("Content-Language", value.toString());
+}
}
1.32 +2 -2 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- tester.xml2001/04/18 19:53:02 1.31
+++ tester.xml2001/04/18 20:40:31 1.32
@@ -650,12 +650,12 @@
tester host="${host}" port="${port}" protocol="${protocol}"
request="${context.path}/SetLocale01" debug="${debug}"
outContent="SetLocale01 PASSED"
- outHeaders="Content-Language:en"/
+ outHeaders="Content-Language:en-US"/
tester host="${host}" port="${port}" protocol="${protocol}"
request="${context.path}/WrappedSetLocale01" debug="${debug}"
outContent="SetLocale01 PASSED"
- outHeaders="Content-Language:en"/
+ outHeaders="Content-Language:en-US"/
/target
Re: Tester (was: cvs commit: ...etc)
btw, a few tests in the tester fail on my environment. I get "Unexpected end of file from server" under Authentication, Jndi, and HttpSession tests which result in failing a few of the tests with java.net.SocketException. Is this normal behavior? Amy On Wed, 18 Apr 2001, Amy Roh wrote: I had problems getting the tester going (and gave up on it a few times previously), because it seems that, on win2k at least, there are some manual steps which must be carried out. In particular, tester.bat tells the code to expect tester.xml to be in %catalina_home%/bin, but the build process does not copy it there. The same is true for the tester webapp. Should this be handled by the build, or documented, or did I miss something? Yeah, I initially had problems running tester as well since build itself doesn't copy files into %catalina_home%/bin (and manually doing it sucks). Feel free to fix the default build target :-) Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm JDBCRealm.java
craigmcc01/04/18 14:43:17
Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
Log:
Set the connection to non-auto-commit mode, so that some JDBC drivers (in particular
MM.MySql 2.0.4) do not complaing when commit() is called in the default (auto-commit)
mode.
PR: Bugzilla #1358
Submitted by: Jeff Hutchison [EMAIL PROTECTED]
Revision ChangesPath
1.14 +2 -1
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java
Index: JDBCRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/JDBCRealm.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JDBCRealm.java2001/04/13 19:57:45 1.13
+++ JDBCRealm.java2001/04/18 21:43:17 1.14
@@ -93,7 +93,7 @@
* @author Craig R. McClanahan
* @author Carson McDonald
* @author Ignacio Ortega
- * @version $Revision: 1.13 $ $Date: 2001/04/13 19:57:45 $
+ * @version $Revision: 1.14 $ $Date: 2001/04/18 21:43:17 $
*/
public class JDBCRealm
@@ -537,6 +537,7 @@
if (connectionPassword != null)
props.put("password", connectionPassword);
dbConnection = driver.connect(connectionURL, props);
+dbConnection.setAutoCommit(false);
return (dbConnection);
}
Re: Tester (was: cvs commit: ...etc)
On Wed, 18 Apr 2001, Amy Roh wrote: btw, a few tests in the tester fail on my environment. I get "Unexpected end of file from server" under Authentication, Jndi, and HttpSession tests which result in failing a few of the tests with java.net.SocketException. Is this normal behavior? Amy No it's not. I get 100% passing on Linux and Win98, for both JDK 1.2 and 1.3. What are the details of your environment? Which individual tests are failing? Have you added the "manager" role to the "tomcat" user in conf/tomcat-users.xml? Craig On Wed, 18 Apr 2001, Amy Roh wrote: I had problems getting the tester going (and gave up on it a few times previously), because it seems that, on win2k at least, there are some manual steps which must be carried out. In particular, tester.bat tells the code to expect tester.xml to be in %catalina_home%/bin, but the build process does not copy it there. The same is true for the tester webapp. Should this be handled by the build, or documented, or did I miss something? Yeah, I initially had problems running tester as well since build itself doesn't copy files into %catalina_home%/bin (and manually doing it sucks). Feel free to fix the default build target :-) Craig
setURLStreamHandlerFactory--why?
I'm working with the latest b4-dev from CVS. Is there a reason the StandardLoader establishes a URLStreamHandlerFactory (a precious resource, since you can set it only once) just for the "jndi:" protocol? If all it's used for is to find the protocol handler, that could be done less intrusively by using the built-in package-based mechanism. My reason for wanting to change this is that it makes using custom URL handlers just about impossible from within a webapp. The package-based mechanism fails for webapps because java.net.URL loads URLStreamHandlers only from the system classpath--so unless you put it in the very lowest-level CLASSPATH (edit catalina.sh or catalina.bat, add along with bootstrap.jar) it will not be able to instantiate the handler. Installing your own URLStreamHandlerFactory is a drastic solution, but in this case, the only (code-level) solution. I will submit a patch to replace the URLStreamHandlerFactory with the naming-pattern based mechanism, if you all consider this a bug rather than a feature. --kd
Re: setURLStreamHandlerFactory--why?
- Original Message - From: "Kyle F. Downey" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 18, 2001 6:25 PM Subject: setURLStreamHandlerFactory--why? I'm working with the latest b4-dev from CVS. Is there a reason the StandardLoader establishes a URLStreamHandlerFactory (a precious resource, since you can set it only once) just for the "jndi:" protocol? If all it's used for is to find the protocol handler, that could be done less intrusively by using the built-in package-based mechanism. My reason for wanting to change this is that it makes using custom URL handlers just about impossible from within a webapp. The package-based mechanism fails for webapps because java.net.URL loads URLStreamHandlers only from the system classpath--so unless you put it in the very lowest-level CLASSPATH (edit catalina.sh or catalina.bat, add along with bootstrap.jar) it will not be able to instantiate the handler. Installing your own URLStreamHandlerFactory is a drastic solution, but in this case, the only (code-level) solution. Fine, but I don't see what that would really solve, since all your webapps would have to use the same URLStreamHandler after it is set by one of the webapps, right ? If it has to be set somewhere, it's definitely in the container. And you can also create URLs using URL(URL context, String spec, URLStreamHandler handler). Of course, that won't work if you want to use JARs (which is why I set the stream handler factory). I just think the mechanism provided by the JDK totally sucks. I will submit a patch to replace the URLStreamHandlerFactory with the naming-pattern based mechanism, if you all consider this a bug rather than a feature. I don't consider that a bug, but if you can have the package-naming mechanism work nice, then we can use it. Remy
Re: setURLStreamHandlerFactory--why?
If you are concerned about security, allowing a web app to set the default URLStreamHandler is not a very secure thing to do because it gives the webapp the ability to see all URL streams globally in the JVM. When using Tomcat with the Java SecurityManager, web apps are not normally granted permission to set the URLStreamHandlerFactory. Regards, Glenn "Kyle F. Downey" wrote: I'm working with the latest b4-dev from CVS. Is there a reason the StandardLoader establishes a URLStreamHandlerFactory (a precious resource, since you can set it only once) just for the "jndi:" protocol? If all it's used for is to find the protocol handler, that could be done less intrusively by using the built-in package-based mechanism. My reason for wanting to change this is that it makes using custom URL handlers just about impossible from within a webapp. The package-based mechanism fails for webapps because java.net.URL loads URLStreamHandlers only from the system classpath--so unless you put it in the very lowest-level CLASSPATH (edit catalina.sh or catalina.bat, add along with bootstrap.jar) it will not be able to instantiate the handler. Installing your own URLStreamHandlerFactory is a drastic solution, but in this case, the only (code-level) solution. I will submit a patch to replace the URLStreamHandlerFactory with the naming-pattern based mechanism, if you all consider this a bug rather than a feature. --kd -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: mod_webapp APR
APR is not a feature of Apache 2.0, but a library/shared object/DLL that Apache 2.0 makes use to. It provides a bundle of functions like file I/O, sockets, IPC, threading, etc. While the API is in C, it is portable to almost all platforms, even the oddest OS/2 and BeOS. In C world, it is a very essential and critical component to build large piece of software (like DBMS) that support multiple platforms. Mozilla has NSPR that does the same stuff, and that's why you can see that Mozilla (and Apache of course) is available in most platforms. Punky Hi, I'm not too familiar with APR, so forgive me if this is a stupid question ;-) If APR is an Apache 2.0 feature, does this mean that mod_webapp will only work with Apache 2.0? If so - what then for Apache 1.3 connectivity to tomcat 4? -Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html
Re: /dev/urandom patch
[EMAIL PROTECTED] wrote: You may file a feature request on bugzilla, attach you patch - this way it'll be recorded. Done. Or send few more patches ( there are many open bugs, most of them are easy to solve but require time to test and reproduce ), and you'll be able to check in the patch yourself, as a commiter :-) Huh, I have a bit of learning to do before that. Tomcat internals are still a bit of a mystery to me. Bojan
