cvs commit: jakarta-commons/lang project.xml
psteitz 2003/11/17 23:03:38 Modified:lang project.xml Log: Inserted empty logo to elimninate broken image from maven site. Revision ChangesPath 1.20 +1 -1 jakarta-commons/lang/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/lang/project.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- project.xml 23 Oct 2003 21:10:01 - 1.19 +++ project.xml 18 Nov 2003 07:03:38 - 1.20 @@ -5,7 +5,7 @@ nameLang/name currentVersion2.0/currentVersion inceptionYear2001/inceptionYear - + logo/ description Commons.Lang, a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Formatting of dom4j digester tag
Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 7:06 PM To: Jakarta Commons Developers List Subject: Re: [Configuration] Formatting of dom4j digester tag Eric, I think you are right with that className attribute. I have only restored support for it (for in the actual implementation it was not even evaluated) because the examples in the overview.html all had a className attribute. And at this time this was the easiest possibility to include HierarchicalDOM4JConfiguration as a configuration source for ConfigurationFactory. From a user's point of view it is surely cleaner to have a separate XML element. Should I change the code in ConfigurationFactory to completely get rid off this attribute (in theory it can be set for all other elements as well, but this doesn't make much sense)? Which element name do you prefer? hierarchical, hierarchicalDom4j, hieraDom4j, ...? (I have always trouble with comming up with a meaningful name). Hey, I really would like to see commons configuration comming out of the sandbox! Oli Eric Pugh wrote: Oliver, I was looking through the docs, and the /examples.html was a great way to go! Something that kinda jumped out at me, having really looked at the examples is the case where we want to load up a HierarchicalDOM4JConfiguration: dom4j className=org.apache.commons.configuration.HierarchicalDOM4J Configuration fileName=tables.xml/ It looks a little weird to have this optional attribute className. I am thinking that we should change instead to: dom4j fileName=gui.xml/ !--normal dom4j -- hierarchicalDom4j fileName=gui.xml/ !--heriarchical dom4j -- or hierarchical fileName=gui.xml/ !--heriarchical dom4j -- I am thinking that this might be a little cleaner.. do you foresee ever havign multiple classes providing the dom4j implementation? The className makes sense if we had 3 or more, but with just two, where the attribute is optional, it seems a little confusing.. any opinons? I am hoping to work towards getting the polish done on commons-configuration and then push for a move out of commons sandbox... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[COLLECTIONS] Tests fail with JDK 1.4.2
Hi, I've been investigating collection's GUMP failure http://gump.covalent.net/log/commons-collections.html that we are seeing since you've refactored the test hierarchy. I added an e.getTargetException().printStackTrace(); to BulkTest#addBulk's catch block for InvocationTargetExceptions to see where the problem arises. What we get are a whole bunch of VerifyErrors as oacc.list.AbstractTestList$BulkTestSubList accesses protected methods and data that have been indirectly inherited from oacc.collection.AbstractTestCollection. I don't quite understand why the compiler allows this but the runtime fails, but that's the reason and it even occurs if I run java -cp JUNIT:COMMONS/collections/dist/classes/ org.apache.commons.collections.TestAllPackages with a completely empty CLASSPATH, so it is not Gump-only issue - I would have suspected a classloader problem otherwise. Access to protected methods is no longer a problem if you mirror the methods in oacc.list.AbstractTestList - but there is no way to make the verifier happy with the access of protected data (apart from protected and mirrored setters, that is). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Formatting of dom4j digester tag
Okay, then I will change the element name to hierarchicalDom4j, remove the support for the className attribute (well I'm not sure if I should really remove this or leave it as undocumented feature; it's about a view lines in ConfigurationFactory that won't hurt) and update the examples and the overview page. At the moment I am also working on the ConfigurationXMLDocument class that allows XML-like processing on Configuration objects including interaction with Digester. I will add a section about this to the examples page, too. Concerning the road map: Is there still interest for the configuration singleton? I think this would be a handy feature. The ConfigurationService class you have written for Turbine would do the major part, wouldn't it? Oh, and I unfortunately don't visit the javapolis conference. Oli Eric Pugh wrote: Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Formatting of dom4j digester tag
Um.. I would suggest just removing the code.. My fear when it comes to undocumented features is that the next committer won't have any idea what is going on, and will accidentally break something, especially if we don't have a unit test backing it up! Yeah, the question about a singleton is a good one.. There is so much opinon back and forth about the value of singletons.. I like them b/c they are easy.. I hate them because inevitably someone want's two configurations etc.. The singleton pattern can be implemented by many different containers if you start going the COP/IOC way.. Basically, I guess if someone wants to provide a good singleton implementation that has unit testing, then I'd be happy to have it. If you are deep and down working on ConfigurationXMLDocument, then would you like to wait for that before looking to move out of sandbox? Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 11:14 AM To: Jakarta Commons Developers List Subject: Re: [Configuration] Formatting of dom4j digester tag Okay, then I will change the element name to hierarchicalDom4j, remove the support for the className attribute (well I'm not sure if I should really remove this or leave it as undocumented feature; it's about a view lines in ConfigurationFactory that won't hurt) and update the examples and the overview page. At the moment I am also working on the ConfigurationXMLDocument class that allows XML-like processing on Configuration objects including interaction with Digester. I will add a section about this to the examples page, too. Concerning the road map: Is there still interest for the configuration singleton? I think this would be a handy feature. The ConfigurationService class you have written for Turbine would do the major part, wouldn't it? Oh, and I unfortunately don't visit the javapolis conference. Oli Eric Pugh wrote: Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Configuration] Formatting of dom4j digester tag
Eric Pugh wrote: Um.. I would suggest just removing the code.. My fear when it comes to undocumented features is that the next committer won't have any idea what is going on, and will accidentally break something, especially if we don't have a unit test backing it up! Sounds reasonable, I will remove it. Yeah, the question about a singleton is a good one.. There is so much opinon back and forth about the value of singletons.. I like them b/c they are easy.. I hate them because inevitably someone want's two configurations etc.. The singleton pattern can be implemented by many different containers if you start going the COP/IOC way.. Basically, I guess if someone wants to provide a good singleton implementation that has unit testing, then I'd be happy to have it. True. I think it won't be possible to come up with a solution everybody is happy with. My idea was to have a very easy way to access configuration properties without having to bother when and where they are loaded. But this raises a couple of questions, e.g. where to look for the configuration definition file, naming conventions, etc. If you are deep and down working on ConfigurationXMLDocument, then would you like to wait for that before looking to move out of sandbox? Eric ConfigurationXMLDocument is nearly finished. If nothing unexpected happens, I think I will need about two more days for updating the documentation. Then I can provide a final patch (including the other points on my todo list). Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24780] New: - java.lang.StringIndexOutOfBoundsException
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=24780. 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=24780 java.lang.StringIndexOutOfBoundsException Summary: java.lang.StringIndexOutOfBoundsException Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: CLI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.charAt(Unknown Source) at org.apache.commons.cli.HelpFormatter.rtrim(HelpFormatter.java:505) at org.apache.commons.cli.HelpFormatter.renderWrappedText(HelpFormatter.java:416) at org.apache.commons.cli.HelpFormatter.printWrapped(HelpFormatter.java:324) at org.apache.commons.cli.HelpFormatter.printWrapped(HelpFormatter.java:318) at org.apache.commons.cli.HelpFormatter.printHelp(HelpFormatter.java:212) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server - New directory
oglueck 2003/11/18 04:22:57 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server GenericResponse.java HttpRequestHandler.java SimpleHttpServer.java HttpRequestHandlerChain.java RequestLine.java ErrorResponse.java SimpleHttpServerConnection.java ResponseWriter.java
oglueck 2003/11/18 04:26:39 Added: httpclient/src/test/org/apache/commons/httpclient/server Tag: HTTPCLIENT_2_0_BRANCH GenericResponse.java HttpRequestHandler.java SimpleHttpServer.java HttpRequestHandlerChain.java RequestLine.java ErrorResponse.java SimpleHttpServerConnection.java ResponseWriter.java Log: Instrumentation for server based tests. Submitted by: Christian Kohlschütter Revision ChangesPath No revision No revision 1.1.2.1 +222 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/GenericResponse.java 1.1.2.1 +96 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/HttpRequestHandler.java 1.1.2.1 +243 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServer.java 1.1.2.1 +114 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/HttpRequestHandlerChain.java 1.1.2.1 +137 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/RequestLine.java 1.1.2.1 +111 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/ErrorResponse.java 1.1.2.1 +196 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java 1.1.2.1 +209 -0 jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/ResponseWriter.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] Proposed new version of ManualPoolingDriverExample.java, plus deprecation question
Hello, I had to implement some parameters that I found on http://jakarta.apache.org/commons/dbcp/configuration.html but the page did not tell me where these parameters can be placed. I finally got it to work and to let others know how to do the trick, I have edited the ManualPoolingDriverExample.java source. If you like it, feel free to add/update the examples section with it! -- Changes to the source - made it compile with dbcp 1.1 and pool 1.1 (PoolingDriver.getConnectionPool suddenly is protected) - gave an example of how to set the number of maxActive connections - note: compiles only with deprecation warnings, see below -- Note about the API: Please do NOT deprecate PoolingDriver.getPool - it's such a nice way to get pool statistics (see printDriverStats from the example) and to shutdown the pool. -- Note about the Parameters page: It is a great summary, but perhaps you could give a guide in each parameter section where this parameter can be actually set. Hope this helps, Gernot -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
I know for Jelly when I've rebuilt the site, I've never checked it in to CVS. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Noel J. Bergman [EMAIL PROTECTED] wrote on 18/11/2003 03:55:47 PM: It seems there are a large number of commons sites that do not exist in CVS. Is there a standard for this? Should the HttpClient entries in CVS be removed? As far as I know, they should all be checked into CVS, regardless of whether they are built with anakia, forrest or maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Noel J. Bergman [EMAIL PROTECTED] wrote on 18/11/2003 02:29:18 PM: I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COLLECTIONS] Tests fail with JDK 1.4.2
I am pretty sure that I ran the tests Sunday night (UK) and all was well. I know there was a point at which things didn't work but I fixed that. Can you confirm your JDK version? I'll look at it tonight if I can. Stephen from:Stefan Bodewig [EMAIL PROTECTED] I've been investigating collection's GUMP failure http://gump.covalent.net/log/commons-collections.html that we are seeing since you've refactored the test hierarchy. I added an e.getTargetException().printStackTrace(); to BulkTest#addBulk's catch block for InvocationTargetExceptions to see where the problem arises. What we get are a whole bunch of VerifyErrors as oacc.list.AbstractTestList$BulkTestSubList accesses protected methods and data that have been indirectly inherited from oacc.collection.AbstractTestCollection. I don't quite understand why the compiler allows this but the runtime fails, but that's the reason and it even occurs if I run java -cp JUNIT:COMMONS/collections/dist/classes/ org.apache.commons.collections.TestAllPackages with a completely empty CLASSPATH, so it is not Gump-only issue - I would have suspected a classloader problem otherwise. Access to protected methods is no longer a problem if you mirror the methods in oacc.list.AbstractTestList - but there is no way to make the verifier happy with the access of protected data (apart from protected and mirrored setters, that is). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COLLECTIONS] Tests fail with JDK 1.4.2
On Tue, 18 Nov 2003, [EMAIL PROTECTED] wrote: Can you confirm your JDK version? I'll look at it tonight if I can. [EMAIL PROTECTED] jsps]$ java -fullversion java full version 1.4.2-b28 on my Linux box (Sun's SDK) and bash-2.05$ /usr/j2sdk1.4.1_02/bin/java -fullversion java full version 1.4.1_02-b06 on gump.covalent.net which runs Solaris 9. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JELLY-80) GbcTag doesn't compile
Message: The following issue has been closed. Resolver: dion gillard Date: Tue, 18 Nov 2003 8:20 AM I believe I fixed this ages ago - View the issue: http://jira.codehaus.org/secure/ViewIssue.jspa?key=JELLY-80 Here is an overview of the issue: - Key: JELLY-80 Summary: GbcTag doesn't compile Type: Bug Status: Closed Priority: Major Resolution: FIXED Original Estimate: 1 minute Time Spent: Unknown Remaining: 1 minute Project: jelly Components: taglib.swing Fix Fors: 1.0-beta-4 Assignee: Reporter: Sean Ferguson Created: Thu, 4 Sep 2003 12:16 PM Updated: Tue, 18 Nov 2003 8:20 AM Environment: Windows XP Java 1.4.2 Description: GbcTag doesn't compile because it doesn't include imports for Tag and Insets. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
Ditto. But in the case of Latka and HttpClient, I expect anything checked into CVS to be using CVS. Still need to sort them out. The HttpClient cvs diffs could just be something daft like a bad line ending, but if so then it's confusing cvs enough to suggest everything is different. I'll mess around with the -b options to diff etc to see if it's just dos/unix formatting. Hen On Wed, 19 Nov 2003 [EMAIL PROTECTED] wrote: Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Noel J. Bergman [EMAIL PROTECTED] wrote on 18/11/2003 02:29:18 PM: I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/stat BivariateRegression.java
mdiggory2003/11/18 07:07:12
Modified:math/src/test/org/apache/commons/math/stat
BivariateRegressionTest.java
math/src/java/org/apache/commons/math/special Beta.java
math/src/java/org/apache/commons/math/stat
BivariateRegression.java
Log:
fix for wrong results and stack overflow error from BivariateRegression
PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24747
Obtained from:
Submitted by: Sergei Skarupo, Brent Worden
Reviewed by: Mark Diggory
Revision ChangesPath
1.9 +34 -3
jakarta-commons/math/src/test/org/apache/commons/math/stat/BivariateRegressionTest.java
Index: BivariateRegressionTest.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/test/org/apache/commons/math/stat/BivariateRegressionTest.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- BivariateRegressionTest.java 14 Nov 2003 22:22:18 - 1.8
+++ BivariateRegressionTest.java 18 Nov 2003 15:07:12 - 1.9
@@ -53,6 +53,8 @@
*/
package org.apache.commons.math.stat;
+import java.util.Random;
+
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
@@ -258,6 +260,35 @@
;
}
-}
+}
+
+public void testPerfect() {
+BivariateRegression regression = new BivariateRegression();
+int n = 100;
+for (int i = 0; i n; i++) {
+regression.addData(((double) i) / (n - 1), i);
+}
+assertEquals(0.0, regression.getSignificance(), 1.0e-5);
+assertTrue(regression.getSlope() 0.0);
+}
+
+public void testPerfectNegative() {
+BivariateRegression regression = new BivariateRegression();
+int n = 100;
+for (int i = 0; i n; i++) {
+regression.addData(-((double) i) / (n - 1), i);
+}
+assertEquals(0.0, regression.getSignificance(), 1.0e-5);
+assertTrue(regression.getSlope() 0.0);
+}
+
+public void testRandom() {
+BivariateRegression regression = new BivariateRegression();
+Random random = new Random(1);
+int n = 100;
+for (int i = 0; i n; i++) {
+regression.addData(((double) i) / (n - 1), random.nextDouble());
+}
+assertTrue(0.0 regression.getSignificance()
regression.getSignificance() 1.0);
+}
}
-
1.13 +5 -2
jakarta-commons/math/src/java/org/apache/commons/math/special/Beta.java
Index: Beta.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/special/Beta.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Beta.java 14 Nov 2003 22:22:17 - 1.12
+++ Beta.java 18 Nov 2003 15:07:12 - 1.13
@@ -151,8 +151,11 @@
double ret;
if (Double.isNaN(x) || Double.isNaN(a) || Double.isNaN(b) || (x 0) ||
-(x 1) || (a = 0.0) || (b = 0.0)) {
+(x 1) || (a = 0.0) || (b = 0.0))
+{
ret = Double.NaN;
+} else if (x (a + 1.0) / (a + b + 1.0)) {
+ret = 1.0 - regularizedBeta(1.0 - x, b, a, epsilon, maxIterations);
} else {
ContinuedFraction fraction = new ContinuedFraction() {
protected double getB(int n, double x) {
1.10 +8 -6
jakarta-commons/math/src/java/org/apache/commons/math/stat/BivariateRegression.java
Index: BivariateRegression.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/stat/BivariateRegression.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- BivariateRegression.java 15 Nov 2003 16:01:38 - 1.9
+++ BivariateRegression.java 18 Nov 2003 15:07:12 - 1.10
@@ -133,11 +133,13 @@
xbar = x;
ybar = y;
} else {
-sumXX += ((double) n / (double) (n + 1)) * (x - xbar) * (x - xbar);
-sumYY += ((double) n / (double) (n + 1)) * (y - ybar) * (y - ybar);
-sumXY += ((double) n / (double) (n + 1)) * (x - xbar) * (y - ybar);
-xbar += (1d / (double) (n + 1)) * (x - xbar);
-ybar += (1d / (double) (n + 1)) * (y - ybar);
+double dx = x - xbar;
+double dy = y - ybar;
+sumXX += dx * dx * (double) n / (double) (n + 1.0);
+sumYY += dy * dy * (double) n / (double) (n + 1.0);
+sumXY += dx * dy * (double) n / (double) (n +
DO NOT REPLY [Bug 24747] - [math] wrong results and stack overflow error from BivariateRegression
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=24747. 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=24747 [math] wrong results and stack overflow error from BivariateRegression [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 15:07 --- Applied and Tested - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
I only came across JRat[1] yesterday evening. I haven't experimented
with it yet but its on my todo list.
-John K
[1] http://jrat.sourceforge.net
On 17 Nov 2003, at 18:04, Mark R. Diggory wrote:
Very true, but are there any Open Source projects or initiatives to
standardize this sort of approach already? For example, here is a
project, I'm not sure of its current state (is about a year since
anything was done to it).
http://jiapi.sourceforge.net/
Also, does JMX relate at all to this use case?
http://java.sun.com/products/JavaManagement/
In other words is there any sort of standardized approach to
managing runtime event debugging in Java?
-Mark
Inger, Matthew wrote:
Not really a runtime dependency. You would merely use
a class loader which would have BCEL instrument your code.
Your code would have have no clue about anything that's
being done to it, and you could easily write your code
generically enough to plug in an arbitrary classloader.
Here's a main program which replaces the classloader,
and calls another main program. Think of it as a wrapper
script.
public static void main(String[] args)
throws Exception
{
// This is where you would construct your class loader
// Done generically enough, you could specify a classloader
// on the command line, and construct it here using
reflection.
ClassLoader myClassLoader =
Thread.currentThread().getContextClassLoader();
final int realClassNameIndex = 0;
String realClassName = args[realClassNameIndex];
int realArgsLength = args.length - realClassNameIndex - 1;
String realClassArgs [] = new String[realArgsLength];
System.arraycopy(args, realClassNameIndex + 1,
realClassArgs, 0,
realArgsLength);
Class clazz = myClassLoader.loadClass(realClassName);
Method m = clazz.getDeclaredMethod(main,
new Class[] { args.getClass() });
m.invoke(null, new Object[] { realClassArgs });
}
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:03 PM
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote:
I know there were a means to setup logging for debugging without
actually having to bury your code in logging lines... I've actually
seen packages like BCEL used to transform the classes in such a way
as to inject logging lines into bytecode, its a pretty slick idea,
but also has the overhead of learning how to use BCEL to manipulate
the bytecode base without screwing with the actual algorithm
behavior.
AspectJ?
But it introduces another runtime dependency...
Tomek
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
On 18 Nov 2003, at 04:55, Noel J. Bergman wrote: It seems there are a large number of commons sites that do not exist in CVS. Is there a standard for this? Should the HttpClient entries in CVS be removed? As far as I know, they should all be checked into CVS, regardless of whether they are built with anakia, forrest or maven. Is it not enough to have the source of the site in CVS? For example, the xdocs (and associated artifacts) for a maven generated site. Is there an added benefit to having the generated HTML in CVS also? -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24780] - java.lang.StringIndexOutOfBoundsException
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=24780. 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=24780 java.lang.StringIndexOutOfBoundsException [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|commons-|jakarta- |[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 16:58 --- The stack trace is useful, but please supply at least some context around this bug report. The content being printed would help too. Or some string which can lead to this problem if the actual content is proprietary. There's not much here from which to recreate the error. Unless it fails all the time? In which case, please add a note to that effect! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: [general] screwed up Commons site
Noel wrote: As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. Martin Cooper wrote: This makes a great deal of sense. Unfortunately, as far as I'm aware, none of the Maven generated sites are checked in. That's probably because Maven does so much (e.g. site:deploy) that it doesn't occur to people (including myself) to take the extra step and check in the generated site. I'm not aware of an actual policy that requires this, but it wouldn't be a bad idea. Perhaps I'll bring that up on [EMAIL PROTECTED] In the meantime, it would be a good policy for us to introduce to Commons, at least, while we're in the process of sorting out our own web site infrastructure. Dion Gillard asked: Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. It is part of the official documentation maintained in the Apache site module by the infrastructure team: - Every project also has a proj-www module that corresponds to the public website specific to that project. This module appears when one goes to the web site http://proj.apache.org;. ref: http://www.apache.org/dev/svc-name-template.html - All CVS modules are in the form $project[-$codebase], where $codebase is an optional extension for subclassing the project into a couple separate parts. Decide which CVS modules you want to create. There should be at least one for the web site, $project-site. Create /www/$project.apache.org directory, chmod g+w, chgrp'd to $project. Do a cvs checkout $project-site into that directory ref: http://www.apache.org/dev/project-creation.html - The websites are served from directories under /www on daedalus. But you usually do not edit any content in those directories. Each website is an anonymous CVS checkout of a repository on icarus. ref: http://www.apache.org/dev/committers.html#web That last one goes into more detail. Obviously, the documentation needs a bit of tidying, but the concept is still the same. I am cc'ing infrastructure@, so if there is any change from this infrastructure policy, the team can let everyone know. Otherwise, I think that this remains policy. John Keys asked: Is it not enough to have the source of the site in CVS? For example, the xdocs (and associated artifacts) for a maven generated site. Is there an added benefit to having the generated HTML in CVS also? In the event of some sort of failure, e.g., an accidental deletion or some other problem, the infrastructure team cannot be assumed to have access to the tools, nor knowledge to use them. Plus it would take much longer to restore by re-building than by doing an update from CVS. There is also an oversight issue. If there were some sort of defacement (there was a perceived one last year), it can be checked against CVS records (turned out that it was not a hack, just an ill-advised comment that a Commiter had checked in). And those CVS records can be checked against replicated copies. Those are just a few things that occur to me off-hand. I am sure that those who developed the policy in the first place have even more reasons, and experiences behind them. Mark R. Diggory wrote: I'm of the opinion that a proper backup system is the appropriate solution here, this is not an ideal usage of cvs and is just going to bloat the cvs contents. Those are issues for the infrastructure team, which issued the policy documented above, to deal with. As for the latter, apparently it has not been considered an issue to date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Still need to sort them out. The HttpClient cvs diffs could just be something daft like a bad line ending, but if so then it's confusing cvs enough to suggest everything is different. I'll mess around with the -b options to diff etc to see if it's just dos/unix formatting. The HttpClient docs in CVS have not been updated for at least a year I believe. We've just been pushing the content using maven site:deploy. If it turns out that we should be using CVS for site documentation I will update CVS, if not I will delete HttpClient from CVS and stick with site:deploy. I'm just waiting for a definitive answer from infrastructure, or whomever else wants to make the official judgment. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Anyone from Latka got a clue what's screwed up with their docs/CVS? Lots of clashes if I attempt to cvs update those. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
I'm just waiting for a definitive answer from infrastructure, or whomever else wants to make the official judgment. Unless infrastructure replies otherwise to the e-mail I sent this morning, I think you should assume that the currently posted policy stands. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sandbox] Karma request
I plan to do some updating of scaffold. Could someone please grant karma to sraeburn for sandbox? TIA Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons-logging classloading (continued)
So, I'm coming into this a bit late and all, and I know a few others have
been looking at this over the past few weeks... hope this does more than
just add fuel to the fire.
commons-discovery was created to address the classloader usage patterns
being discussed : how to discover an implemention for a given interface.
Commons-discovery was explicitly designed to be a general replacement for
LogFactory - I'd like to see LogFactory eliminated entirely from
commons-logging.
On the surface, you may not find that commons-discovery does anything more
than LogFactory. Underneath, it's a set of tools that let you setup your
own patterns.
That said:
LogFactory was designed to work in a J2EE environment by dropping it into
the Server level. It also functions quite well embedded into the
application.
As is being discovered, it doesn't work so well if you want some hybrid of
that. It's a known problem, and I'm sorry to say I simply don't see ANY
straight forward fix available - particularly by working with the
ClassLoaders. The following was proposed:
if (!Log.class.isAssignableFrom(logClass)) {
// Plan B. Bend over backwards to continue
Class logInterface =
LoadClass(org.apache.commons.logging.Log);
if (logInterface == null) {
throw new LogConfigurationException
(Log interface can not be found);
}
if (!logInterface.isAssignableFrom(logClass))
throw new LogConfigurationException
(Class + logClassName + does not implement Log);
}
The situation:
- logClass bundled into a webapp.
- commons-logging bundled into a webapp, with local configuration
settings.
- commons-logging bundled into the webserver, with global configuration
settings.
Clearly logClass, which implemented the local copy of Log, failed to
load because it doesn't implement the (expected) global copy of Log.
Calling LoadClass(org.apache.commons.logging.Log) will only return the
global copy - classloaders (by design) always defer to parent
classloaders. In this case, the web-app classloader gives the server
classloader first crack at loading Log. You simply don't have anyway to
see the local copy that's the fundamental problem.
***
Richard A. Sitze
IBM WebSphere WebServices Development
It's a kind of growing pain with the success of Commons.
Some servers have some commons jars while others not. In the
application you always include jars you needed. At the end of
day, situation like that seems inevitable, not just logging,
not mention the version problem.
Is it possible some standard be set or a classloader component
in Commons?
- sean
--- Ojares Rami EINT [EMAIL PROTECTED] wrote:
Well put Norbert.
I think that since classloading and threads are such complex
issues there should be a way to not use the pattern
of loading the implementation from thread's context classloader.
(Hint to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3. My own webapp i'm working on also uses commons-logging,
so i include a copy of the jar file into the WEB-INF/lib
directory to be protable to other servlet containers that does
not include the commons-logging package. I found some
discussions in the mail archive that is about commons-logging
and its class loading strategy. But as i could not found an
anwser to my problem, i post my problem here again, hoping to
get a hint for a solution (or maybe to settle on a new consens).
The problem is, that when tomcat wants to anser a HTTPS
request it instantiates a Http11ConnectionHandler which
processes the connection.
The Http11ConnectionHandler instance itself instantiates a
JSSE14Support class which itself instantiates a
org.apache.commons.logging.Log implementation class. Because
the thread that runs the Http11ConnectionHandler has the
WebappClassloader of my web application as its
context class loader (which ist used by commons-logging to
load the Log implementation (logClass)), BUT the
org.apache.commons.logging.Log interface itself was loaded
from the Common StandardClassLoader, the predicate in
LogFactoryImpl.getLogConstructor()
(!Log.class.isAssignableFrom(logClass))
is false, so that LogFactoryImpl.getLogConstructor() throws a
LogConfigurationException. Because both classes are loaded
from different classloaders.
IMHO what commons-logging MUST ensure to work correctly is,
that the logClass is loaded from the same classloader than the
Log.class is and this is not guaranteed by the current
implementation! For example
protected static ClassLoader getContextClassLoader()
throws
Re: [Math] common-math and bloated 3rd party libraries
A few more:
http://pharos.inria.fr/Java/query.jsp?cids=c_2203hist=cids%3Dc_2154
Mark R. Diggory wrote:
Good documentation, good project activity. Documentation for how to plug
it in under tomcat and other application servers. Nice separation of
hooks, logging and monitoring into separate layers...
worth a try I think :-)
thanks
John Keyes wrote:
I only came across JRat[1] yesterday evening. I haven't experimented
with it yet but its on my todo list.
-John K
[1] http://jrat.sourceforge.net
On 17 Nov 2003, at 18:04, Mark R. Diggory wrote:
Very true, but are there any Open Source projects or initiatives to
standardize this sort of approach already? For example, here is a
project, I'm not sure of its current state (is about a year since
anything was done to it).
http://jiapi.sourceforge.net/
Also, does JMX relate at all to this use case?
http://java.sun.com/products/JavaManagement/
In other words is there any sort of standardized approach to
managing runtime event debugging in Java?
-Mark
Inger, Matthew wrote:
Not really a runtime dependency. You would merely use
a class loader which would have BCEL instrument your code.
Your code would have have no clue about anything that's
being done to it, and you could easily write your code
generically enough to plug in an arbitrary classloader.
Here's a main program which replaces the classloader,
and calls another main program. Think of it as a wrapper
script.
public static void main(String[] args)
throws Exception
{
// This is where you would construct your class loader
// Done generically enough, you could specify a classloader
// on the command line, and construct it here using reflection.
ClassLoader myClassLoader =
Thread.currentThread().getContextClassLoader();
final int realClassNameIndex = 0;
String realClassName = args[realClassNameIndex];
int realArgsLength = args.length - realClassNameIndex - 1;
String realClassArgs [] = new String[realArgsLength];
System.arraycopy(args, realClassNameIndex + 1,
realClassArgs, 0,
realArgsLength);
Class clazz = myClassLoader.loadClass(realClassName);
Method m = clazz.getDeclaredMethod(main,
new Class[] { args.getClass() });
m.invoke(null, new Object[] { realClassArgs });
}
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:03 PM
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote:
I know there were a means to setup logging for debugging without
actually having to bury your code in logging lines... I've actually
seen packages like BCEL used to transform the classes in such a way
as to inject logging lines into bytecode, its a pretty slick
idea, but also has the overhead of learning how to use BCEL to
manipulate the bytecode base without screwing with the actual
algorithm behavior.
AspectJ?
But it introduces another runtime dependency...
Tomek
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[chain] Researching Dynamic Proxy Commands
It might be better to bring this up on Commons Chain, Peter, since these questions seem to transcend our implementation of the Request Processor (aka Struts Chain). -Ted. Peter A. Pilgrim wrote: I am investigating the possibility of commands that can branch dynamically. Why was the ChainBase frozen in the execute() method? What is the design decision or intention of NonDelegatingCommand.java? What do you need to successfully compile and build the chain module? -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections BulkTest.java
scolebourne2003/11/18 13:28:17
Modified:collections/src/test/org/apache/commons/collections
BulkTest.java
Log:
Report more helpfully when errors occur
Revision ChangesPath
1.7 +6 -4
jakarta-commons/collections/src/test/org/apache/commons/collections/BulkTest.java
Index: BulkTest.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/BulkTest.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- BulkTest.java 5 Oct 2003 20:48:29 - 1.6
+++ BulkTest.java 18 Nov 2003 21:28:16 - 1.7
@@ -398,9 +398,11 @@
try {
bulk2 = (BulkTest)m.invoke(bulk, null);
if (bulk2 == null) return;
-} catch (InvocationTargetException e) {
+} catch (InvocationTargetException ex) {
+ex.getTargetException().printStackTrace();
throw new Error(); // FIXME;
-} catch (IllegalAccessException e) {
+} catch (IllegalAccessException ex) {
+ex.printStackTrace();
throw new Error(); // FIXME;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/plugins PluginCreateRule.java
rdonkin 2003/11/18 14:14:22 Modified:digester/src/java/org/apache/commons/digester/plugins PluginCreateRule.java Log: Small correction to the javadocs. Submitted by Simon Kitching. Revision ChangesPath 1.9 +5 -5 jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java Index: PluginCreateRule.java === RCS file: /home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- PluginCreateRule.java 16 Nov 2003 22:37:35 - 1.8 +++ PluginCreateRule.java 18 Nov 2003 22:14:22 - 1.9 @@ -301,8 +301,8 @@ * associated with the specified pattern. Check all configuration data is * valid and remember the pattern for later. * - * @param pattern is the digester match pattern that is associated with - * this rule instance, eg root/widget. + * @param matchPattern is the digester match pattern that is associated + * with this rule instance, eg root/widget. * @exception PluginConfigurationException */ public void postRegisterInit(String matchPattern) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-logging classloading (continued)
Forgive me for jumping in with a comment, I have the interest if not the
experience (at least not of the rest of this thread.) I'm wondering ... is
the issue loading the local webapp's version of commons logging, or getting
to it's configuration? Assuming a robust/stable interface/implementation of
CL, I have to assume the latter. Having a copy of CL bundled with the webapp
ought be just a fallback.
So, does that change the problem from class loading to resource loading? Is
it possible to get to the webapp's resource, [whereas getting to the webapps
classes might lead to a Link error.] I don't know the details of resource
loading, but I wonder if it is less of a rats nest than class loading. I
wonder if one could as for local-commonslogging.properties and if not found
go for commonslogging.properties [shipped with CL or whatever.] Unlike
classloading, I assume one can have multiple resources in memory more
easily.
That said, I don't know if one can teach the log load to detect that a
webapp was just loaded (if the Log class is already in memory). I assume
this is doable though.
Just a random thought...
regards
Adam
- Original Message -
From: Richard Sitze [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 12:51 PM
Subject: RE: commons-logging classloading (continued)
So, I'm coming into this a bit late and all, and I know a few others have
been looking at this over the past few weeks... hope this does more than
just add fuel to the fire.
commons-discovery was created to address the classloader usage patterns
being discussed : how to discover an implemention for a given interface.
Commons-discovery was explicitly designed to be a general replacement for
LogFactory - I'd like to see LogFactory eliminated entirely from
commons-logging.
On the surface, you may not find that commons-discovery does anything more
than LogFactory. Underneath, it's a set of tools that let you setup your
own patterns.
That said:
LogFactory was designed to work in a J2EE environment by dropping it into
the Server level. It also functions quite well embedded into the
application.
As is being discovered, it doesn't work so well if you want some hybrid of
that. It's a known problem, and I'm sorry to say I simply don't see ANY
straight forward fix available - particularly by working with the
ClassLoaders. The following was proposed:
if (!Log.class.isAssignableFrom(logClass)) {
// Plan B. Bend over backwards to continue
Class logInterface =
LoadClass(org.apache.commons.logging.Log);
if (logInterface == null) {
throw new LogConfigurationException
(Log interface can not be found);
}
if (!logInterface.isAssignableFrom(logClass))
throw new LogConfigurationException
(Class + logClassName + does not implement Log);
}
The situation:
- logClass bundled into a webapp.
- commons-logging bundled into a webapp, with local configuration
settings.
- commons-logging bundled into the webserver, with global configuration
settings.
Clearly logClass, which implemented the local copy of Log, failed to
load because it doesn't implement the (expected) global copy of Log.
Calling LoadClass(org.apache.commons.logging.Log) will only return the
global copy - classloaders (by design) always defer to parent
classloaders. In this case, the web-app classloader gives the server
classloader first crack at loading Log. You simply don't have anyway to
see the local copy that's the fundamental problem.
***
Richard A. Sitze
IBM WebSphere WebServices Development
It's a kind of growing pain with the success of Commons.
Some servers have some commons jars while others not. In the
application you always include jars you needed. At the end of
day, situation like that seems inevitable, not just logging,
not mention the version problem.
Is it possible some standard be set or a classloader component
in Commons?
- sean
--- Ojares Rami EINT [EMAIL PROTECTED] wrote:
Well put Norbert.
I think that since classloading and threads are such complex
issues there should be a way to not use the pattern
of loading the implementation from thread's context classloader.
(Hint to Craig :)
- rami
-Original Message-
From: Norbert Klose [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2003 12:21 PM
To: [EMAIL PROTECTED]
Subject: commons-logging classloading (continued)
Hello,
i currently use Tomcat 4.1.27 bundled with commons-logging
1.0.3. My own webapp i'm working on also uses commons-logging,
so i include a copy of the jar file into the WEB-INF/lib
directory to be protable to other servlet containers that does
not include the commons-logging package. I found some
discussions in the mail archive that is about
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/plugins PluginRules.java
rdonkin 2003/11/18 14:32:16
Modified:digester/src/java/org/apache/commons/digester/plugins
PluginRules.java
Log:
Corrects patterns that begin with a leading slash. Submitted by Simon Kitching.
Revision ChangesPath
1.7 +12 -4
jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginRules.java
Index: PluginRules.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginRules.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- PluginRules.java 16 Nov 2003 22:37:35 - 1.6
+++ PluginRules.java 18 Nov 2003 22:32:16 - 1.7
@@ -224,7 +224,9 @@
/**
* Register a new Rule instance matching the specified pattern.
*
- * @param pattern Nesting pattern to be matched for this Rule
+ * @param pattern Nesting pattern to be matched for this Rule.
+ * This parameter treats equally patterns that begin with and without
+ * a leading slash ('/').
* @param rule Rule instance to be registered
*/
public void add(String pattern, Rule rule) {
@@ -234,6 +236,12 @@
if (debug) {
log.debug(add entry + : mapping pattern [ + pattern + ] +
to rule of type [ + rule.getClass().getName() + ]);
+}
+
+// allow patterns with a leading slash character
+if (pattern.startsWith(/))
+{
+pattern = pattern.substring(1);
}
decoratedRules.add(pattern, rule);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] two very simple plugins patches
hi simon i've committed both patches. would you be willing to knock up a test case for the second? - robert On 17 Nov 2003, at 09:43, Simon Kitching wrote: Hi, The first attached patch is just a fix for a minor javadoc problem introduced in an earlier patch. The second patch is perhaps more controversial: it allows a leading slash on patterns for the PluginRules class. ie /root/item is treated just like root/item. This is useful because plugin classes usually do something like this: digester.add(basePattern + /mychildtag); If the base pattern is , then the pattern ends up with a leading slash, which is not good. This patch definitely does *not* alter the behaviour of any code outside plugins (though I think it would be nice for all the Rules classes to allow leading slashes anyway). Regards, Simon plugins-javadoc.patchplugins- slash.patch--- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java
scolebourne2003/11/18 14:37:18 Modified:collections/src/test/org/apache/commons/collections/iterators TestUnmodifiableMapIterator.java AbstractTestListIterator.java AbstractTestMapIterator.java AbstractTestIterator.java collections/src/test/org/apache/commons/collections/list TestSetUniqueList.java TestTransformedList.java TestFixedSizeList.java TestUnmodifiableList.java AbstractTestList.java TestPredicatedList.java collections/src/test/org/apache/commons/collections/bag TestTypedSortedBag.java TestTypedBag.java TestTransformedBag.java AbstractTestBag.java TestPredicatedBag.java TestPredicatedSortedBag.java TestTransformedSortedBag.java collections/src/test/org/apache/commons/collections TestDoubleOrderedMap.java TestLinkedList.java TestSequencedHashMap.java TestLRUMap.java TestCursorableLinkedList.java TestBoundedFifoBuffer.java TestBeanMap.java AbstractTestObject.java TestReferenceMap.java TestUnboundedFifoBuffer.java TestTreeBag.java TestStaticBucketMap.java TestFlat3Map.java TestMultiHashMap.java TestCircularFifoBuffer.java TestBinaryHeap.java TestHashBag.java BulkTest.java collections/src/test/org/apache/commons/collections/buffer TestBlockingBuffer.java collections/src/test/org/apache/commons/collections/bidimap TestDualHashBidiMap.java TestDualTreeBidiMap.java TestTreeBidiMap.java AbstractTestBidiMap.java AbstractTestSortedBidiMap.java collections/src/test/org/apache/commons/collections/observed TestObservableCollection.java TestObservableSet.java TestObservableSortedSet.java TestObservableSortedBag.java TestObservableBuffer.java TestObservableList.java TestObservableBag.java collections/src/test/org/apache/commons/collections/map TestUnmodifiableMap.java TestLazySortedMap.java TestFixedSizeMap.java TestPredicatedMap.java TestFixedSizeSortedMap.java TestListOrderedMap.java TestTransformedMap.java AbstractTestMap.java AbstractTestSortedMap.java TestPredicatedSortedMap.java TestLazyMap.java collections/src/test/org/apache/commons/collections/set TestPredicatedSet.java AbstractTestSet.java TestListOrderedSet.java TestTransformedSet.java TestUnmodifiableSortedSet.java AbstractTestSortedSet.java TestTransformedSortedSet.java collections/src/test/org/apache/commons/collections/comparators TestNullComparator.java TestComparableComparator.java AbstractTestComparator.java TestBooleanComparator.java TestComparatorChain.java TestReverseComparator.java collections/src/test/org/apache/commons/collections/collection TestPredicatedCollection.java TestTransformedCollection.java AbstractTestCollection.java TestCompositeCollection.java collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java Removed: collections/src/test/org/apache/commons/collections/primitives/adapters TestCollectionDoubleCollection.java TestAll.java TestByteListIteratorListIterator.java TestLongListIteratorListIterator.java TestIteratorLongIterator.java TestDoubleListList.java TestListIteratorFloatListIterator.java TestListDoubleList.java TestListCharList.java TestListIteratorShortListIterator.java TestFloatIteratorIterator.java TestFloatListList.java TestIteratorCharIterator.java TestIntCollectionCollection.java TestCollectionLongCollection.java TestListLongList.java TestFloatListIteratorListIterator.java
Re: cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java
We should start keeping records -- this looks to be the longest commit ever. ;) [EMAIL PROTECTED] wrote: scolebourne2003/11/18 14:37:18 Modified:collections/src/test/org/apache/commons/collections/iterators TestUnmodifiableMapIterator.java AbstractTestListIterator.java AbstractTestMapIterator.java AbstractTestIterator.java collections/src/test/org/apache/commons/collections/list TestSetUniqueList.java TestTransformedList.java TestFixedSizeList.java TestUnmodifiableList.java AbstractTestList.java TestPredicatedList.java collections/src/test/org/apache/commons/collections/bag TestTypedSortedBag.java TestTypedBag.java TestTransformedBag.java AbstractTestBag.java TestPredicatedBag.java TestPredicatedSortedBag.java TestTransformedSortedBag.java collections/src/test/org/apache/commons/collections TestDoubleOrderedMap.java TestLinkedList.java TestSequencedHashMap.java TestLRUMap.java TestCursorableLinkedList.java TestBoundedFifoBuffer.java TestBeanMap.java AbstractTestObject.java TestReferenceMap.java TestUnboundedFifoBuffer.java TestTreeBag.java TestStaticBucketMap.java TestFlat3Map.java TestMultiHashMap.java TestCircularFifoBuffer.java TestBinaryHeap.java TestHashBag.java BulkTest.java collections/src/test/org/apache/commons/collections/buffer TestBlockingBuffer.java collections/src/test/org/apache/commons/collections/bidimap TestDualHashBidiMap.java TestDualTreeBidiMap.java TestTreeBidiMap.java AbstractTestBidiMap.java AbstractTestSortedBidiMap.java collections/src/test/org/apache/commons/collections/observed TestObservableCollection.java TestObservableSet.java TestObservableSortedSet.java TestObservableSortedBag.java TestObservableBuffer.java TestObservableList.java TestObservableBag.java collections/src/test/org/apache/commons/collections/map TestUnmodifiableMap.java TestLazySortedMap.java TestFixedSizeMap.java TestPredicatedMap.java TestFixedSizeSortedMap.java TestListOrderedMap.java TestTransformedMap.java AbstractTestMap.java AbstractTestSortedMap.java TestPredicatedSortedMap.java TestLazyMap.java collections/src/test/org/apache/commons/collections/set TestPredicatedSet.java AbstractTestSet.java TestListOrderedSet.java TestTransformedSet.java TestUnmodifiableSortedSet.java AbstractTestSortedSet.java TestTransformedSortedSet.java collections/src/test/org/apache/commons/collections/comparators TestNullComparator.java TestComparableComparator.java AbstractTestComparator.java TestBooleanComparator.java TestComparatorChain.java TestReverseComparator.java collections/src/test/org/apache/commons/collections/collection TestPredicatedCollection.java TestTransformedCollection.java AbstractTestCollection.java TestCompositeCollection.java collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java Removed: collections/src/test/org/apache/commons/collections/primitives/adapters TestCollectionDoubleCollection.java TestAll.java TestByteListIteratorListIterator.java TestLongListIteratorListIterator.java TestIteratorLongIterator.java TestDoubleListList.java TestListIteratorFloatListIterator.java TestListDoubleList.java TestListCharList.java TestListIteratorShortListIterator.java TestFloatIteratorIterator.java TestFloatListList.java TestIteratorCharIterator.java TestIntCollectionCollection.java TestCollectionLongCollection.java
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/decorators UnmodifiableBoundedCollection.java
scolebourne2003/11/18 14:50:44
Modified:collections/src/java/org/apache/commons/collections
BoundedCollection.java CollectionUtils.java
BoundedFifoBuffer.java
collections/src/java/org/apache/commons/collections/collection
UnmodifiableBoundedCollection.java
collections/src/java/org/apache/commons/collections/decorators
UnmodifiableBoundedCollection.java
Added: collections/src/java/org/apache/commons/collections/collection
BoundedCollection.java
Log:
Move BoundedCollection to new collection subpackage
Revision ChangesPath
1.5 +4 -19
jakarta-commons/collections/src/java/org/apache/commons/collections/BoundedCollection.java
Index: BoundedCollection.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BoundedCollection.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- BoundedCollection.java7 Sep 2003 08:48:46 - 1.4
+++ BoundedCollection.java18 Nov 2003 22:50:44 - 1.5
@@ -57,8 +57,6 @@
*/
package org.apache.commons.collections;
-import java.util.Collection;
-
/**
* A BoundedCollection is a collection that is bounded in size.
* p
@@ -66,26 +64,13 @@
* maximum number of elements. This interface allows the querying of details
* associated with the maximum number of elements.
*
+ * @deprecated TO BE DELETED BEFORE v3.0, moved to collection subpackage
* @since Commons Collections 3.0
* @version $Revision$ $Date$
*
* @author Herve Quiroz
* @author Stephen Colebourne
*/
-public interface BoundedCollection extends Collection {
+public interface BoundedCollection extends
org.apache.commons.collections.collection.BoundedCollection {
-/**
- * Returns true if this collection is full and no new elements can be added.
- *
- * @return codetrue/code if the collection is full
- */
-boolean isFull();
-
-/**
- * Gets the maximum size of the collection (the bound).
- *
- * @return the maximum number of elements the collection can hold
- */
-int maxSize();
-
}
1.47 +3 -2
jakarta-commons/collections/src/java/org/apache/commons/collections/CollectionUtils.java
Index: CollectionUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/CollectionUtils.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- CollectionUtils.java 16 Nov 2003 00:05:44 - 1.46
+++ CollectionUtils.java 18 Nov 2003 22:50:44 - 1.47
@@ -69,6 +69,7 @@
import java.util.Map;
import java.util.Set;
+import org.apache.commons.collections.collection.BoundedCollection;
import org.apache.commons.collections.collection.PredicatedCollection;
import org.apache.commons.collections.collection.SynchronizedCollection;
import org.apache.commons.collections.collection.TransformedCollection;
1.11 +4 -2
jakarta-commons/collections/src/java/org/apache/commons/collections/BoundedFifoBuffer.java
Index: BoundedFifoBuffer.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BoundedFifoBuffer.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- BoundedFifoBuffer.java7 Sep 2003 08:48:46 - 1.10
+++ BoundedFifoBuffer.java18 Nov 2003 22:50:44 - 1.11
@@ -63,6 +63,8 @@
import java.util.Iterator;
import java.util.NoSuchElementException;
+import org.apache.commons.collections.collection.BoundedCollection;
+
/**
* The BoundedFifoBuffer is a strongvery/strong efficient implementation of
* Buffer that does not alter the size of the buffer at runtime.
1.2 +2 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/collection/UnmodifiableBoundedCollection.java
Index: UnmodifiableBoundedCollection.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/collection/UnmodifiableBoundedCollection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- UnmodifiableBoundedCollection.java16 Nov 2003 00:05:47 - 1.1
+++ UnmodifiableBoundedCollection.java18 Nov 2003 22:50:44 - 1.2
@@ -59,8 +59,6 @@
import java.util.Collection;
-import org.apache.commons.collections.BoundedCollection;
-
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections TestBoundedFifoBuffer2.java
scolebourne2003/11/18 14:51:19 Modified:collections/src/test/org/apache/commons/collections TestBoundedFifoBuffer2.java Log: Move BoundedCollection to new collection subpackage Revision ChangesPath 1.7 +4 -2 jakarta-commons/collections/src/test/org/apache/commons/collections/TestBoundedFifoBuffer2.java Index: TestBoundedFifoBuffer2.java === RCS file: /home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestBoundedFifoBuffer2.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- TestBoundedFifoBuffer2.java 5 Oct 2003 21:03:44 - 1.6 +++ TestBoundedFifoBuffer2.java 18 Nov 2003 22:51:19 - 1.7 @@ -62,6 +62,8 @@ import junit.framework.Test; +import org.apache.commons.collections.collection.BoundedCollection; + /** * Runs tests against a full BoundedFifoBuffer, since many of the algorithms * differ depending on whether the fifo is full or not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/sql project.xml
matth 2003/11/18 15:19:14 Modified:sql project.xml Log: Updated maven build to newest jelly version (was broken otehrwise) and updated code samples in docs to display correctly. Revision ChangesPath 1.13 +27 -19jakarta-commons-sandbox/sql/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/sql/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 30 Apr 2003 11:15:42 - 1.12 +++ project.xml 18 Nov 2003 23:19:13 - 1.13 @@ -1,6 +1,6 @@ ?xml version=1.0? project - + version3/version namecommons-sql/name idcommons-sql/id @@ -9,7 +9,7 @@ organization nameApache Software Foundation/name urlhttp://www.apache.org/url -logo/images/jakarta-logo-blue.gif/logo +logohttp://jakarta.apache.org/images/jakarta-logo-blue.gif/logo /organization logo/images/logo.jpg/logo @@ -74,12 +74,21 @@ /developers + repository +connection +scm:cvs:pserver:[EMAIL PROTECTED]:/home/cvspublic:jakarta-commons-sandbox/sql +/connection + +urlhttp://cvs.apache.org/viewcvs/jakarta-commons-sandbox/sql/url + /repository + + !-- Need to mark these as compile-time/run-time -- dependencies dependency idcommons-logging/id - version1.0.2/version + version1.0.3/version /dependency dependency @@ -98,18 +107,17 @@ dependency idcommons-digester/id - version1.3/version + version1.5/version /dependency - - dependency +dependency idcommons-betwixt/id - version1.0-alpha-1/version + version1.0-beta-1-dev/version /dependency dependency idcommons-jelly/id - version1.0-beta-4/version + versionSNAPSHOT/version /dependency dependency @@ -138,12 +146,12 @@ idxml-apis/id version1.0.b2/version /dependency - + dependency idxerces/id - version2.0.2/version + version2.5.0/version /dependency - + !-- database used for testing -- dependency idaxion/id @@ -156,8 +164,8 @@ /dependencies - - + + build nagEmailAddress[EMAIL PROTECTED]/nagEmailAddress @@ -173,18 +181,18 @@ /includes /unitTest - + !-- Integration unit test classes -- integrationUnitTestPatterns/integrationUnitTestPatterns !-- J A R R E S O U R C E S -- !-- Resources that are packaged up inside the JAR file -- resources - directorysrc/java/directory - includes - include**/*.properties/include - include**/*.betwixt/include - /includes +directorysrc/java/directory +includes +include**/*.properties/include +include**/*.betwixt/include +/includes /resources /build /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/sql/xdocs index.xml
matth 2003/11/18 15:19:51 Modified:sql/xdocs index.xml Log: Updated maven build to newest jelly version (was broken otehrwise) and updated code samples in docs to display correctly. Revision ChangesPath 1.8 +76 -84jakarta-commons-sandbox/sql/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons-sandbox/sql/xdocs/index.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- index.xml 17 Sep 2002 10:19:07 - 1.7 +++ index.xml 18 Nov 2003 23:19:50 - 1.8 @@ -17,16 +17,16 @@ based on experiences and ideas from the Turbine and Torque projects. /p p -Commons SQL contains a simple set of -a href=apidocs/org/apache/commons/sql/model/package-summary.htmlbeans/a +Commons SQL contains a simple set of +a href=apidocs/org/apache/commons/sql/model/package-summary.htmlbeans/a that represent a relational database schema such as a Database, Table, Column etc. -These beans can be read from XML or written to XML using -a href=http://jakarta.apache.org/commons/betwixt/;Betwixt/a via the -a href=apidocs/org/apache/commons/sql/io/DatabaseReader.htmlDatabaseReader/a and -a href=apidocs/org/apache/commons/sql/io/DatabaseWriter.htmlDatabaseWriter/a classes. +These beans can be read from XML or written to XML using +a href=http://jakarta.apache.org/commons/betwixt/;Betwixt/a via the +a href=apidocs/org/apache/commons/sql/io/DatabaseReader.htmlDatabaseReader/a and +a href=apidocs/org/apache/commons/sql/io/DatabaseWriter.htmlDatabaseWriter/a classes. /p p -There is an example XML document +There is an example XML document a href=http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/sql/src/test-input/datamodel.xml?rev=HEAD;here/a /p p @@ -37,7 +37,7 @@ /p p -Then the SQL beans can be used by code generation tools like +Then the SQL beans can be used by code generation tools like a href=http://jakarta.apache.org/velocity/;Velocity/a or a href=http://jakarta.apache.org/commons/sandbox/jelly/;Jelly/a @@ -46,28 +46,23 @@ repository files and so forth. /p /section - + section name=Using Commons SQL in Ant or Maven p -There's also an Ant task to generate the DDL for a physical database. Here's an example of it in use. +There's also an Ant task to generate the DDL for a physical database. Here's an example of it in use. /p -pre - lt;taskdef -name=ddl -classname=org.apache.commons.sql.task.DDLTaskgt; - lt;classpath refid=some.classpath/gt; - lt;/taskdefgt; - - lt;ddl -xmlFile=src/conf/myschema.xml -targetDatabase=oracle -output=target/myschema-oracle.sql/gt; -/pre +source![CDATA[taskdef name=ddl classname=org.apache.commons.sql.task.DDLTask +classpath refid=some.classpath/ +/taskdef + +ddl xmlFile=src/conf/myschema.xml targetDatabase=oracle +output=target/myschema-oracle.sql/]] +/source p -It is hoped that Commons SQL can be used to create a -a href=http://jakarta.apache.org/turbine/maven/;Maven/a +It is hoped that Commons SQL can be used to create a +a href=http://jakarta.apache.org/turbine/maven/;Maven/a plugin for projects wishing to create beans or OJB files from some logical relational schema. /p /section @@ -75,69 +70,66 @@ section name=Using DynaBeans to access and change data in a database p - There's a simple API for querying and inserting, updating and deleting data via - a href=DynaBeans/a - It essentially binds the commons-sql model beans - (Database, Table, Column) to DyanClass, DynaBean and DynaProperty instances. +There's a simple API for querying and inserting, updating and deleting data via +a href=DynaBeans/a +It essentially binds the commons-sql model beans +(Database, Table, Column) to DyanClass, DynaBean and DynaProperty instances. + /p + p +So you can do things like /p - p - So you can do things like - /p - -pre - // lets parser the model from XML - DatabaseReader reader = new DatabaseReader(); - Database model = (Database) reader.parse( mymodel.xml ); - - // JDBC connection pool, maybe using DBCP and Pool from commons - DataSource source = ...; - - // now lets add
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map Flat3Map.java package.html
scolebourne2003/11/18 15:23:05 Modified:collections/src/test/org/apache/commons/collections MapPerformance.java collections/src/test/org/apache/commons/collections/map TestAll.java collections/src/java/org/apache/commons/collections/map package.html Added: collections/src/test/org/apache/commons/collections/map TestFlat3Map.java collections/src/java/org/apache/commons/collections/map Flat3Map.java Removed: collections/src/test/org/apache/commons/collections TestFlat3Map.java collections/src/java/org/apache/commons/collections Flat3Map.java Log: Move Flat3Map to map subpackage Revision ChangesPath 1.2 +3 -1 jakarta-commons/collections/src/test/org/apache/commons/collections/MapPerformance.java Index: MapPerformance.java === RCS file: /home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/MapPerformance.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- MapPerformance.java 2 Nov 2003 23:43:00 - 1.1 +++ MapPerformance.java 18 Nov 2003 23:23:05 - 1.2 @@ -65,6 +65,8 @@ import java.util.Set; import java.util.TreeMap; +import org.apache.commons.collections.map.Flat3Map; + /** * codeTestMapPerformance/code is designed to perform basic Map performance tests. * 1.2 +3 -2 jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestAll.java Index: TestAll.java === RCS file: /home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestAll.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- TestAll.java 16 Nov 2003 00:05:46 - 1.1 +++ TestAll.java 18 Nov 2003 23:23:05 - 1.2 @@ -85,6 +85,7 @@ suite.addTest(TestFixedSizeMap.suite()); suite.addTest(TestFixedSizeSortedMap.suite()); +suite.addTest(TestFlat3Map.suite()); suite.addTest(TestLazyMap.suite()); suite.addTest(TestLazySortedMap.suite()); suite.addTest(TestListOrderedMap.suite()); 1.1 jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestFlat3Map.java Index: TestFlat3Map.java === /* * $Header: /home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/map/TestFlat3Map.java,v 1.1 2003/11/18 23:23:05 scolebourne Exp $ * * * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2003 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 acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names The Jakarta Project, Commons, 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
Re: cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/pairs AbstractTestMapEntry.java
We should start keeping records -- this looks to be the longest commit ever. ;) Lots of protected to public, very fun to do Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [COLLECTIONS] Tests fail with JDK 1.4.2
Should be sorted now. I made all relevant methods public. (Tests suceeded in Eclipse, but failed using ant) Stephen - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] On Tue, 18 Nov 2003, [EMAIL PROTECTED] wrote: Can you confirm your JDK version? I'll look at it tonight if I can. [EMAIL PROTECTED] jsps]$ java -fullversion java full version 1.4.2-b28 on my Linux box (Sun's SDK) and bash-2.05$ /usr/j2sdk1.4.1_02/bin/java -fullversion java full version 1.4.1_02-b06 on gump.covalent.net which runs Solaris 9. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] new rule SetNestedPropertiesRule
hi simon just to let you know that i would have committed your patch but there's a broken lock in cvs :( - robert On 17 Nov 2003, at 09:34, Simon Kitching wrote: On Tue, 2003-11-18 at 11:32, Simon Kitching wrote: Hi, Attached is a rule which behaves like a cross between SetPropertiesRule and BeanPropertySetterRule-with-trailing-wildcard-match. I should mention that this rule comes in very useful when using the Plugins module. That module does not permit any wildcards in patterns below plugin mount points. So the BeanPropertySetterRule + trailing wildcards solution cannot be used, but this solution can. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Updating 'whoweare.html'
Thanks Henri :) Steven Caswell Sun Certified Java Programmer [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving One ring to rule them all, one ring to find them... -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 11:06 PM To: Jakarta General List Cc: Jakarta Commons Developers List Subject: Re: [general] Updating 'whoweare.html' These changes are now made. About 17 people took me up on the offer and they ought to now all be on the whoweare.html page. If I messed anything up, please let me know. Some people on the PMC may be listed as Committers currently. I don't think I missed anyone, but I'll do a sweep of the PMC list and the whoweare to compare tomorrow night. This marks the end of this special limited offer. Hen On Mon, 10 Nov 2003, Henri Yandell wrote: [in case it's not obvious, this email pertains only to Jakarta committers] http://jakarta.apache.org/site/whoweare.html is the informal way for Jakarta to let the users know who we are. When you become a Jakarta committer, it is hoped that you will add your name and even a description if you so wish, but it can be a pain as jakarta-site2 is a bit of a barrier to build and you have to get access to the web-server directory, though I believe that now they are the same machine it is easier. That said, I am offering a one-time, no rainchecks, by the end of the week, no-refunds, no-smallprint, service to add either your name, or your name and a description. Please either mail from your apache account or include your apache username so I can doublecheck. I'll also remove names and/or move them to 'Alumni' or some other suggested section if anyone would like. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/map Flat3Map.java
scolebourne2003/11/18 15:34:47
Modified:collections/src/java/org/apache/commons/collections/map
Flat3Map.java
Log:
Fix puAll method to return correctly
Revision ChangesPath
1.2 +3 -2
jakarta-commons/collections/src/java/org/apache/commons/collections/map/Flat3Map.java
Index: Flat3Map.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/map/Flat3Map.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Flat3Map.java 18 Nov 2003 23:23:05 - 1.1
+++ Flat3Map.java 18 Nov 2003 23:34:47 - 1.2
@@ -370,6 +370,7 @@
}
if (iMap != null) {
iMap.putAll(map);
+return;
}
if (size 4) {
for (Iterator it = map.entrySet().iterator(); it.hasNext();) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [CLI] contribution
Sorry for the slow response - I know I've been taken away from open source for the last couple of weeks and I guess John's been busy too. We are certainly open to contributions from non-committers but seeing a patch makes it much easier to judge :)Personally I'd prefer patches against cli2 but that's because I'm aiming to have that codebase adopted for release sometime soon - by no means a certain thing. Proposing / discussing possible improvements on the list would be a good start and if things look interesting then someone should create a bugzilla entry to stop things being lost (sorry if you've entered one already - I'll check those tomorrow). Whether you need to supply a prototype probably depends on whether we understand your idea properly so I'd recommend chatting first and supplying code later unless you have things ready to go. Looking forward to your ideas, Rob - Original Message - From: John Kristian [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, November 13, 2003 8:15 PM Subject: [CLI] contribution Dear CLI Developers, Are you receptive to contributions from non-committers? For example: If one sent a patch to add some minor improvement, could it conceivably get into CVS soon? (Assuming it's a real improvement.) What baseline would you prefer, for such a patch? jakarta-commons/cli or jakarta-commons-sandbox/cli/src/java/org/apache/commons/cli2? Some branch or MAIN? Should one send it via this mailing list, or bugzilla? If one had an idea for new stuff (not closely connected to the fine work you're doing now), would you entertain a proposal? (I have some such ideas, I confess.) Do you want to review rough ideas? Not be bothered until a working prototype is available? It appears (from skimming jakarta-commons-sandbox/cli) you're in the middle of a big rewrite; perhaps you don't have time for this sort of thing. - John Kristian P.S. If the answers are already in a FAQ somewhere, please tell me where. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestHttpConnectionManager.java
mbecke 2003/11/18 16:10:45
Modified:httpclient/src/java/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH
MultiThreadedHttpConnectionManager.java
httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH
TestHttpConnectionManager.java
Log:
Changed MultiThreadedHttpConnectionManager to move to a single GC thread.
Fixes memory and thread leaks.
PR: 24309
Submitted by: Michael Becke
Reviewed by: Eric Johnson
Revision ChangesPath
No revision
No revision
1.17.2.5 +153 -61
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java
Index: MultiThreadedHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java,v
retrieving revision 1.17.2.4
retrieving revision 1.17.2.5
diff -u -r1.17.2.4 -r1.17.2.5
--- MultiThreadedHttpConnectionManager.java 1 Sep 2003 18:05:51 -
1.17.2.4
+++ MultiThreadedHttpConnectionManager.java 19 Nov 2003 00:10:45 -
1.17.2.5
@@ -103,6 +103,79 @@
/** The default maximum number of connections allowed overall */
public static final int DEFAULT_MAX_TOTAL_CONNECTIONS = 20;
+/**
+ * A mapping from Reference to ConnectionSource. Used to reclaim resources
when connections
+ * are lost to the garbage collector.
+ */
+public static final Map REFERENCE_TO_CONNECTION_SOURCE;
+
+/**
+ * The reference queue used to track when HttpConnections are lost to the
+ * garbage collector
+ */
+private static final ReferenceQueue REFERENCE_QUEUE;
+
+/**
+ * The thread responsible for handling lost connections.
+ */
+private static ReferenceQueueThread REFERENCE_QUEUE_THREAD;
+
+
+static {
+REFERENCE_TO_CONNECTION_SOURCE = Collections.synchronizedMap(new HashMap());
+REFERENCE_QUEUE = new ReferenceQueue();
+REFERENCE_QUEUE_THREAD = new ReferenceQueueThread();
+REFERENCE_QUEUE_THREAD.start();
+}
+
+/**
+ * Stores the reference to the given connection along with the hostConfig and
connection pool.
+ * These values will be used to reclaim resources if the connection is lost to
the garbage
+ * collector. This method should be called before a connection is released
from the connection
+ * manager.
+ *
+ * pA static reference to the connection manager will also be stored. To
ensure that
+ * the connection manager can be GCed [EMAIL PROTECTED]
#removeReferenceToConnection(HttpConnection)}
+ * should be called for all connections that the connection manager is storing
a reference
+ * to./p
+ *
+ * @param connection the connection to create a reference for
+ * @param hostConfiguration the connection's host config
+ * @param connectionPool the connection pool that created the connection
+ *
+ * @see #removeReferenceToConnection(HttpConnection)
+ */
+private static void storeReferenceToConnection(
+HttpConnectionWithReference connection,
+HostConfiguration hostConfiguration,
+ConnectionPool connectionPool
+) {
+
+ConnectionSource source = new ConnectionSource();
+source.connectionPool = connectionPool;
+source.hostConfiguration = hostConfiguration;
+
+REFERENCE_TO_CONNECTION_SOURCE.put(
+connection.reference,
+source
+);
+}
+
+/**
+ * Removes the reference being stored for the given connection. This method
should be called
+ * when the connection manager again has a direct reference to the connection.
+ *
+ * @param connection the connection to remove the reference for
+ *
+ * @see #storeReferenceToConnection(HttpConnection, HostConfiguration,
ConnectionPool)
+ */
+private static void removeReferenceToConnection(HttpConnectionWithReference
connection) {
+
+synchronized (REFERENCE_TO_CONNECTION_SOURCE) {
+REFERENCE_TO_CONNECTION_SOURCE.remove(connection.reference);
+}
+}
+
// - Instance Variables
/** Maximum number of connections allowed per host */
private int maxHostConnections = DEFAULT_MAX_HOST_CONNECTIONS;
@@ -116,26 +189,11 @@
/** Connection Pool */
private ConnectionPool connectionPool;
-/** mapping from reference to hostConfiguration */
-private Map referenceToHostConfig;
-
-/**
-
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server SimpleHttpServer.java SimpleHttpServerConnection.java
mbecke 2003/11/18 16:23:30
Modified:httpclient/src/test/org/apache/commons/httpclient/server
Tag: HTTPCLIENT_2_0_BRANCH SimpleHttpServer.java
SimpleHttpServerConnection.java
Log:
Fixed pre 1.4 compile errors.
Revision ChangesPath
No revision
No revision
1.1.2.2 +14 -11
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServer.java
Index: SimpleHttpServer.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServer.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- SimpleHttpServer.java 18 Nov 2003 12:26:38 - 1.1.2.1
+++ SimpleHttpServer.java 19 Nov 2003 00:23:30 - 1.1.2.2
@@ -82,7 +82,7 @@
* @author Christian Kohlschuetter
*/
public class SimpleHttpServer implements Runnable {
-private static final Log log = LogFactory.getLog(SimpleHttpServer.class);
+private static final Log LOG = LogFactory.getLog(SimpleHttpServer.class);
private ServerSocket server = null;
private Thread t;
@@ -110,8 +110,8 @@
*/
public SimpleHttpServer(int port) throws IOException {
server = new ServerSocket(port);
-if(log.isInfoEnabled()) {
-log.info(New SimpleHttpServer on port + getLocalPort());
+if(LOG.isInfoEnabled()) {
+LOG.info(New SimpleHttpServer on port + getLocalPort());
}
tg = new ThreadGroup(SimpleHttpServer group);
t = new Thread(tg, this, SimpleHttpServer connection handler);
@@ -149,8 +149,8 @@
}
stopped = true;
-if(log.isInfoEnabled()) {
-log.info(Stopping SimpleHttpServer on port + getLocalPort());
+if(LOG.isInfoEnabled()) {
+LOG.info(Stopping SimpleHttpServer on port + getLocalPort());
}
tg.interrupt();
@@ -225,17 +225,20 @@
t.setDaemon(true);
t.start();
} catch (IOException e) {
-throw new RuntimeException(e);
+LOG.error(SimpleHttpServer error, e);
+throw new RuntimeException(e.getMessage());
}
Thread.sleep(100);
}
} catch (InterruptedException accept) {
} catch (SocketException e) {
if (!stopped) {
-throw new RuntimeException(e);
+LOG.error(SimpleHttpServer error, e);
+throw new RuntimeException(e.getMessage());
}
} catch (IOException e) {
-throw new RuntimeException(e);
+LOG.error(SimpleHttpServer error, e);
+throw new RuntimeException(e.getMessage());
} finally {
destroy();
}
1.1.2.2 +10 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java
Index: SimpleHttpServerConnection.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/server/Attic/SimpleHttpServerConnection.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- SimpleHttpServerConnection.java 18 Nov 2003 12:26:38 - 1.1.2.1
+++ SimpleHttpServerConnection.java 19 Nov 2003 00:23:30 - 1.1.2.2
@@ -71,6 +71,8 @@
import org.apache.commons.httpclient.Header;
import org.apache.commons.httpclient.HttpParser;
import org.apache.commons.httpclient.HttpStatus;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
/**
* A connection to the SimpleHttpServer.
@@ -78,6 +80,9 @@
* @author Christian Kohlschuetter
*/
public class SimpleHttpServerConnection implements Runnable {
+
+private static final Log LOG =
LogFactory.getLog(SimpleHttpServerConnection.class);
+
private SimpleHttpServer server;
private Socket socket;
private InputStream in;
@@ -120,7 +125,8 @@
} while(keepAlive);
} catch (SocketException ignore) {
} catch (IOException e) {
-throw new RuntimeException(e);
+LOG.error(ServerConnection read error, e);
+throw new RuntimeException(e.getMessage());
} finally {
destroy();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestHttpConnectionManager.java
mbecke 2003/11/18 16:43:12
Modified:httpclient/src/java/org/apache/commons/httpclient
MultiThreadedHttpConnectionManager.java
httpclient/src/test/org/apache/commons/httpclient
TestHttpConnectionManager.java
Log:
Changed MultiThreadedHttpConnectionManager to move to a single GC thread.
Fixes memory and thread leaks.
PR: 24309
Submitted by: Michael Becke
Reviewed by: Eric Johnson
Revision ChangesPath
1.28 +153 -62
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java
Index: MultiThreadedHttpConnectionManager.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/MultiThreadedHttpConnectionManager.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- MultiThreadedHttpConnectionManager.java 26 Oct 2003 09:49:16 - 1.27
+++ MultiThreadedHttpConnectionManager.java 19 Nov 2003 00:43:12 - 1.28
@@ -73,7 +73,6 @@
import java.net.SocketException;
import java.util.Collections;
import java.util.HashMap;
-import java.util.Iterator;
import java.util.LinkedList;
import java.util.Map;
@@ -105,6 +104,79 @@
/** The default maximum number of connections allowed overall */
public static final int DEFAULT_MAX_TOTAL_CONNECTIONS = 20;
+/**
+ * A mapping from Reference to ConnectionSource. Used to reclaim resources
when connections
+ * are lost to the garbage collector.
+ */
+public static final Map REFERENCE_TO_CONNECTION_SOURCE;
+
+/**
+ * The reference queue used to track when HttpConnections are lost to the
+ * garbage collector
+ */
+private static final ReferenceQueue REFERENCE_QUEUE;
+
+/**
+ * The thread responsible for handling lost connections.
+ */
+private static ReferenceQueueThread REFERENCE_QUEUE_THREAD;
+
+
+static {
+REFERENCE_TO_CONNECTION_SOURCE = Collections.synchronizedMap(new HashMap());
+REFERENCE_QUEUE = new ReferenceQueue();
+REFERENCE_QUEUE_THREAD = new ReferenceQueueThread();
+REFERENCE_QUEUE_THREAD.start();
+}
+
+/**
+ * Stores the reference to the given connection along with the hostConfig and
connection pool.
+ * These values will be used to reclaim resources if the connection is lost to
the garbage
+ * collector. This method should be called before a connection is released
from the connection
+ * manager.
+ *
+ * pA static reference to the connection manager will also be stored. To
ensure that
+ * the connection manager can be GCed [EMAIL PROTECTED]
#removeReferenceToConnection(HttpConnection)}
+ * should be called for all connections that the connection manager is storing
a reference
+ * to./p
+ *
+ * @param connection the connection to create a reference for
+ * @param hostConfiguration the connection's host config
+ * @param connectionPool the connection pool that created the connection
+ *
+ * @see #removeReferenceToConnection(HttpConnection)
+ */
+private static void storeReferenceToConnection(
+HttpConnectionWithReference connection,
+HostConfiguration hostConfiguration,
+ConnectionPool connectionPool
+) {
+
+ConnectionSource source = new ConnectionSource();
+source.connectionPool = connectionPool;
+source.hostConfiguration = hostConfiguration;
+
+REFERENCE_TO_CONNECTION_SOURCE.put(
+connection.reference,
+source
+);
+}
+
+/**
+ * Removes the reference being stored for the given connection. This method
should be called
+ * when the connection manager again has a direct reference to the connection.
+ *
+ * @param connection the connection to remove the reference for
+ *
+ * @see #storeReferenceToConnection(HttpConnection, HostConfiguration,
ConnectionPool)
+ */
+private static void removeReferenceToConnection(HttpConnectionWithReference
connection) {
+
+synchronized (REFERENCE_TO_CONNECTION_SOURCE) {
+REFERENCE_TO_CONNECTION_SOURCE.remove(connection.reference);
+}
+}
+
// - Instance Variables
/**
* Collection of parameters associated with this connection manager.
@@ -114,26 +186,11 @@
/** Connection Pool */
private ConnectionPool connectionPool;
-/** mapping from reference to hostConfiguration */
-private Map referenceToHostConfig;
-
-/**
- * the reference queue
[codec] message digest code
Apologies if I've mentioned this before. I have a similar class to DigestUtils but with a few differences: http://www.osjava.org/genjava-core/xref/com/generationjava/security/Securer.html 1) It treats it as an object not a static. 2) It hides CRC32 and Adler32 'digests'. 3) It does some basic help on comparing hashes. Partly this is due to my habit of turning all such byte[]'s into hexascii 0-F notation so it can easily go in databases. Please ignore Constant, and ByteArray ideas went into Hex I think so Hex should support anything it does. I think I read that the static was preferred to instance, but has anyone considered the CRC32 and Adler32 checksums that are hidden away in the util.zip code? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
By the way, are the people involved in WordWrapUtils aware of ICU's (http://oss.software.ibm.com/icu/) code to do this? (LineBreakIterator, etc.). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] new rule SetNestedPropertiesRule
On Wed, 2003-11-19 at 12:30, robert burrell donkin wrote:
hi simon
just to let you know that i would have committed your patch but there's
a broken lock in cvs :(
Thanks Robert.
Since the new rule is considered acceptable, here's a patch that adds
the tests to build.xml. Hope that CVS issue doesn't cause you too much
headache..
Cheers,
Simon
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-commons/digester/build.xml,v
retrieving revision 1.48
diff -u -r1.48 build.xml
--- build.xml 18 Oct 2003 13:40:46 - 1.48
+++ build.xml 19 Nov 2003 03:09:15 -
@@ -272,6 +272,7 @@
test.factory,
test.regex,
test.wdrules,
+ test.setnestedprops,
test.plugins
description=Run all unit test cases
@@ -477,6 +478,20 @@
classpath refid=test.classpath/
/java
/target
+
+ target name=test.setnestedprops depends=compile.tests
+ description=Run SetNestedPropertiesRule tests ...
+echo message=Running SetNestedPropertiesRule tests .../
+condition property=logopt value=${log.factoryopt}=${log.class}
+ istrue value=${suppressLogOutputDuringTests}/
+/condition
+java classname=${test.runner} fork=yes
+failonerror=${test.failonerror}
+ jvmarg value=-D${logopt}/
+ arg value=org.apache.commons.digester.SetNestedPropertiesRuleTestCase/
+ classpath refid=test.classpath/
+/java
+ /target
target name=test.plugins depends=compile.tests
description=Run Plugins tests ...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] two very simple plugins patches
On Wed, 2003-11-19 at 11:35, robert burrell donkin wrote:
hi simon
i've committed both patches.
would you be willing to knock up a test case for the second?
You're keeping me honest here :-)
Test case attached.
Index: org/apache/commons/digester/plugins/TestInline.java
===
RCS file: /home/cvspublic/jakarta-commons/digester/src/test/org/apache/commons/digester/plugins/TestInline.java,v
retrieving revision 1.3
diff -u -r1.3 TestInline.java
--- org/apache/commons/digester/plugins/TestInline.java 9 Oct 2003 21:09:49 - 1.3
+++ org/apache/commons/digester/plugins/TestInline.java 19 Nov 2003 03:18:22 -
@@ -142,4 +142,51 @@
assertEquals(L1, label2.getId());
assertEquals(2, label2.getLabel());
}
+
+public void testLeadingSlash() throws Exception {
+// Tests that PluginRules handles patterns with a leading slash.
+//
+// This test doesn't really belong in this class. If a separate test
+// case class is created for PluginRules, then this method should be
+// moved there.
+
+Digester digester = new Digester();
+PluginRules rc = new PluginRules();
+digester.setRules(rc);
+
+PluginCreateRule pcr = new PluginCreateRule(Widget.class);
+digester.addRule(/root/widget, pcr);
+digester.addSetNext(/root/widget, addChild);
+
+Container root = new Container();
+digester.push(root);
+
+try {
+digester.parse(
+TestAll.getInputStream(this, test1.xml));
+}
+catch(Exception e) {
+throw e;
+}
+
+Object child;
+List children = root.getChildren();
+assertTrue(children != null);
+assertEquals(2, children.size());
+
+child = children.get(0);
+assertTrue(child != null);
+assertEquals(TextLabel.class, child.getClass());
+TextLabel label1 = (TextLabel) child;
+assertEquals(anonymous, label1.getId());
+assertEquals(1, label1.getLabel());
+
+child = children.get(1);
+assertTrue(child != null);
+assertEquals(TextLabel.class, child.getClass());
+TextLabel label2 = (TextLabel) child;
+assertEquals(L1, label2.getId());
+assertEquals(2, label2.getLabel());
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/distribution FDistributionTest.java GammaDistributionTest.java BinomialDistributionTest.java ExponentialDistributionTest.java TDistributionTest.java ChiSquareDistributionTest.java HypergeometricDistributionTest.java
mdiggory2003/11/18 19:22:54 Modified:math/src/java/org/apache/commons/math/distribution FDistributionImpl.java DistributionFactoryImpl.java ContinuousDistribution.java AbstractDiscreteDistribution.java AbstractContinuousDistribution.java TDistributionImpl.java GammaDistributionImpl.java BinomialDistributionImpl.java DiscreteDistribution.java HypergeometricDistributionImpl.java ExponentialDistributionImpl.java ChiSquaredDistributionImpl.java math/src/test/org/apache/commons/math/stat TestStatisticTest.java BivariateRegressionTest.java math/src/java/org/apache/commons/math/stat TestStatisticImpl.java TestStatistic.java BivariateRegression.java math/src/test/org/apache/commons/math/distribution FDistributionTest.java GammaDistributionTest.java BinomialDistributionTest.java ExponentialDistributionTest.java TDistributionTest.java ChiSquareDistributionTest.java HypergeometricDistributionTest.java Log: Exposed MathException handling in Distributions by adding thows MathException to methods where MathExceptions are caught and replaced with Double.NaN. Added Serialization Interface to Distributions, BivariateRegression and TestStatistic Revision ChangesPath 1.11 +8 -10 jakarta-commons/math/src/java/org/apache/commons/math/distribution/FDistributionImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/FDistributionImpl.java.diff?r1=1.10r2=1.11 1.16 +4 -2 jakarta-commons/math/src/java/org/apache/commons/math/distribution/DistributionFactoryImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/DistributionFactoryImpl.java.diff?r1=1.15r2=1.16 1.9 +6 -4 jakarta-commons/math/src/java/org/apache/commons/math/distribution/ContinuousDistribution.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/ContinuousDistribution.java.diff?r1=1.8r2=1.9 1.8 +5 -3 jakarta-commons/math/src/java/org/apache/commons/math/distribution/AbstractDiscreteDistribution.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/AbstractDiscreteDistribution.java.diff?r1=1.7r2=1.8 1.16 +29 -27 jakarta-commons/math/src/java/org/apache/commons/math/distribution/AbstractContinuousDistribution.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/AbstractContinuousDistribution.java.diff?r1=1.15r2=1.16 1.11 +15 -18 jakarta-commons/math/src/java/org/apache/commons/math/distribution/TDistributionImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/TDistributionImpl.java.diff?r1=1.10r2=1.11 1.14 +6 -8 jakarta-commons/math/src/java/org/apache/commons/math/distribution/GammaDistributionImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/GammaDistributionImpl.java.diff?r1=1.13r2=1.14 1.8 +25 -22 jakarta-commons/math/src/java/org/apache/commons/math/distribution/BinomialDistributionImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/BinomialDistributionImpl.java.diff?r1=1.7r2=1.8 1.7 +6 -4 jakarta-commons/math/src/java/org/apache/commons/math/distribution/DiscreteDistribution.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/DiscreteDistribution.java.diff?r1=1.6r2=1.7 1.7 +6 -3 jakarta-commons/math/src/java/org/apache/commons/math/distribution/HypergeometricDistributionImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/HypergeometricDistributionImpl.java.diff?r1=1.6r2=1.7 1.10 +9 -5 jakarta-commons/math/src/java/org/apache/commons/math/distribution/ExponentialDistributionImpl.java http://cvs.apache.org/viewcvs/jakarta-commons/math/src/java/org/apache/commons/math/distribution/ExponentialDistributionImpl.java.diff?r1=1.9r2=1.10 1.11 +7 -3 jakarta-commons/math/src/java/org/apache/commons/math/distribution/ChiSquaredDistributionImpl.java
cvs commit: jakarta-commons/math/src/java/org/apache/commons/math/stat/univariate StorelessUnivariateStatistic.java
mdiggory2003/11/18 19:28:25
Modified:math/src/java/org/apache/commons/math/analysis
SplineInterpolator.java BrentSolver.java
BisectionSolver.java PolynomialFunction.java
CubicSplineFunction.java SecantSolver.java
UnivariateRealSolverFactoryImpl.java
UnivariateRealSolverImpl.java
math/src/java/org/apache/commons/math/stat
DescriptiveStatisticsImpl.java
DescriptiveStatistics.java Frequency.java
StorelessDescriptiveStatisticsImpl.java
math/src/java/org/apache/commons/math/util
TransformerMap.java FixedDoubleArray.java
ContractableDoubleArray.java
ExpandableDoubleArray.java ContinuedFraction.java
DefaultTransformer.java
math/src/java/org/apache/commons/math/stat/univariate/summary
SumOfSquares.java Product.java SumOfLogs.java
Sum.java
math/src/java/org/apache/commons/math/random
ValueServer.java RandomDataImpl.java
EmpiricalDistributionImpl.java
math/src/java/org/apache/commons/math/stat/univariate/rank
Min.java Max.java Percentile.java Median.java
math/src/java/org/apache/commons/math/stat/univariate/moment
FirstMoment.java ThirdMoment.java Variance.java
Kurtosis.java Mean.java FourthMoment.java
SecondMoment.java GeometricMean.java
StandardDeviation.java Skewness.java
math/src/java/org/apache/commons/math
MathConfigurationException.java
ConvergenceException.java MathException.java
math/src/java/org/apache/commons/math/special Gamma.java
Beta.java
math/src/java/org/apache/commons/math/complex Complex.java
math/src/java/org/apache/commons/math/stat/univariate
StorelessUnivariateStatistic.java
Log:
Added Serialization Interface to all Implementations
Revision ChangesPath
1.10 +4 -2
jakarta-commons/math/src/java/org/apache/commons/math/analysis/SplineInterpolator.java
Index: SplineInterpolator.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/analysis/SplineInterpolator.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- SplineInterpolator.java 14 Nov 2003 22:22:17 - 1.9
+++ SplineInterpolator.java 19 Nov 2003 03:28:23 - 1.10
@@ -53,13 +53,15 @@
*/
package org.apache.commons.math.analysis;
+import java.io.Serializable;
+
/**
* Computes a natural spline interpolation for the data set.
*
* @version $Revision$ $Date$
*
*/
-public class SplineInterpolator implements UnivariateRealInterpolator {
+public class SplineInterpolator implements UnivariateRealInterpolator, Serializable
{
/** the natural spline coefficients. */
private double[][] c = null;
1.9 +4 -2
jakarta-commons/math/src/java/org/apache/commons/math/analysis/BrentSolver.java
Index: BrentSolver.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/analysis/BrentSolver.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- BrentSolver.java 14 Nov 2003 22:22:17 - 1.8
+++ BrentSolver.java 19 Nov 2003 03:28:23 - 1.9
@@ -53,6 +53,8 @@
*/
package org.apache.commons.math.analysis;
+import java.io.Serializable;
+
import org.apache.commons.math.MathException;
/**
@@ -63,7 +65,7 @@
*
* @version $Revision$ $Date$
*/
-public class BrentSolver extends UnivariateRealSolverImpl {
+public class BrentSolver extends UnivariateRealSolverImpl implements Serializable {
/**
* Construct a solver for the given function.
* @param f function to solve.
1.8 +4 -2
jakarta-commons/math/src/java/org/apache/commons/math/analysis/BisectionSolver.java
Index: BisectionSolver.java
===
RCS file:
/home/cvs/jakarta-commons/math/src/java/org/apache/commons/math/analysis/BisectionSolver.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- BisectionSolver.java 14 Nov 2003 22:22:17 - 1.7
+++ BisectionSolver.java 19 Nov 2003 03:28:23 - 1.8
@@ -53,6 +53,8 @@
*/
package
Re: commons-logging classloading (continued)
hi richard
On 18 Nov 2003, at 19:51, Richard Sitze wrote:
So, I'm coming into this a bit late and all, and I know a few others
have
been looking at this over the past few weeks... hope this does more
than
just add fuel to the fire.
commons-discovery was created to address the classloader usage patterns
being discussed : how to discover an implemention for a given
interface.
Commons-discovery was explicitly designed to be a general replacement
for
LogFactory - I'd like to see LogFactory eliminated entirely from
commons-logging.
i don't think that there's any chance of that. (i also suspect that
there's very little chance of adding a core dependency upon a discovery
replacement.)
On the surface, you may not find that commons-discovery does anything
more
than LogFactory. Underneath, it's a set of tools that let you setup
your
own patterns.
i think that the problems reported with classloaders mostly fall into a
few distinct categories. some are due to misguided administration
policies (and we can do very little about that). some are down to the
conflict between the behaviour required for correct function when
logging in modern servlet containers and different classloader
environments. other are down to the need for hybrid uses (to borrow
your phrase from later in the email - i have the advantage of being
able to read it all before replying :)
we can do very little about misguided administration policies but there
are things we can do about the others.
i think that offer different LogFactory implementations are part of the
solution. a user operating in an unusual environment would then be able
to choose to run another implementation by adding the appropriate -D
switch on the command line. i'd support an optional discovery based
LogFactory implementation (but not a core one). even if users didn't
use it directly, it would give them a positive example they could based
more sophisticated discovery-based solutions on. fancy giving this a
go?
That said:
LogFactory was designed to work in a J2EE environment by dropping it
into
the Server level. It also functions quite well embedded into the
application.
As is being discovered, it doesn't work so well if you want some
hybrid of
that. It's a known problem, and I'm sorry to say I simply don't see
ANY
straight forward fix available - particularly by working with the
ClassLoaders. The following was proposed:
if (!Log.class.isAssignableFrom(logClass)) {
// Plan B. Bend over backwards to continue
Class logInterface =
LoadClass(org.apache.commons.logging.Log);
if (logInterface == null) {
throw new LogConfigurationException
(Log interface can not be found);
}
if (!logInterface.isAssignableFrom(logClass))
throw new LogConfigurationException
(Class + logClassName + does not implement Log);
}
The situation:
- logClass bundled into a webapp.
- commons-logging bundled into a webapp, with local configuration
settings.
- commons-logging bundled into the webserver, with global
configuration
settings.
Clearly logClass, which implemented the local copy of Log, failed to
load because it doesn't implement the (expected) global copy of Log.
Calling LoadClass(org.apache.commons.logging.Log) will only return
the
global copy - classloaders (by design) always defer to parent
classloaders. In this case, the web-app classloader gives the server
classloader first crack at loading Log. You simply don't have anyway
to
see the local copy that's the fundamental problem.
i'm not sure that it is in this case. i have a feeling that some of the
reports came from containers which used other (older?) classloading
strategies. that's why some people have reported some success when
loading from the LogFactory.getClassloader.loadClass(). i agree that
it's not a proper solution but it'd probably make life a little easier
for people using containers with odd (or older) classloading
strategies.
BTW one of my person bugbears is that commons-logging throws exceptions
when logging configuration fails. there is no technical reason why we
could not give the user an system property that suppresses all
exceptions and uses a very simple default logger. comments anyone?
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[math] A little on serialization
I've been wiring in place some testing for the serialization of objects to disk and the deserialization back to objects. I'll be adding it and a a Unit test example shortly, I'm hoping that others will join in and write some simple tests to verify that their code is properly serializable. Another interesting point is that serialization can be customized to optimize it for storage considerations, for instance, if a large matrix were symetric, serialization could be written such that only one side of its data need be stored and the other side could be simple filed in with the stored data on recovery. Not really my idea... http://java.sun.com/j2se/1.4.2/docs/guide/serialization/examples/custom/index3.html -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24699] - [MATH] Repetitive Permutations
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=24699. 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=24699 [MATH] Repetitive Permutations [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-11-19 04:40 --- I'm going to assume this is resolved - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24699] - [MATH] Repetitive Permutations
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=24699. 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=24699 [MATH] Repetitive Permutations --- Additional Comments From [EMAIL PROTECTED] 2003-11-19 05:02 --- Yes, thank you. Was I supposed to verify it or do anything else as the reporter of the bug? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
For my part, I'd never heard of it in this context. Did come across it the other day when trying to build jikes and not having some GNU api [iconv]. ICU [C variant] was the alternative. http://oss.software.ibm.com/icu4j/ looks interesting. Hen On Wed, 19 Nov 2003, Bill Keese wrote: By the way, are the people involved in WordWrapUtils aware of ICU's (http://oss.software.ibm.com/icu/) code to do this? (LineBreakIterator, etc.). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24699] - [MATH] Repetitive Permutations
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=24699. 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=24699 [MATH] Repetitive Permutations --- Additional Comments From [EMAIL PROTECTED] 2003-11-19 05:36 --- No, as long as the issue was addressed, then I just need to close the Bug. Thanks for reporting. Keep looking :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: commons-messenger query
Hi, I'm currently looking for a JMS bridging solution and before I started re-inventing wheels I decided to look at what's out there and so I stumbled upon commons-messenger: Is there any active development still taking place on this component? What is the status of this project currently? And secondly, besides the Javadoc docos are there any other resource available (either FAQ's, newsgroups, whitepapers etc) on the topic? Thanks in advance, Alex Arana CPRS MNPP Project - CrimTrac Tel: (02) 6245 7770 Fax: (02) 6230 1696 Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
re: commons-messenger query
On Wed, 19 Nov 2003, Alex Arana wrote: Hi, I'm currently looking for a JMS bridging solution and before I started re-inventing wheels I decided to look at what's out there and so I stumbled upon commons-messenger: Going by other answers to the list on the same subject: Is there any active development still taking place on this component? No. What is the status of this project currently? It appears to be slumbering. And secondly, besides the Javadoc docos are there any other resource available (either FAQ's, newsgroups, whitepapers etc) on the topic? Unless an article out there mentions it, not as far as I know. It's the source and the javadocs. Sorry for the lack of positive answers, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: [general] screwed up Commons site
Noel J. Bergman [EMAIL PROTECTED] wrote on 19/11/2003 04:52:48 AM: Noel wrote: As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. Martin Cooper wrote: This makes a great deal of sense. Unfortunately, as far as I'm aware, none of the Maven generated sites are checked in. That's probably because Maven does so much (e.g. site:deploy) that it doesn't occur to people (including myself) to take the extra step and check in the generated site. I'm not aware of an actual policy that requires this, but it wouldn't be a bad idea. Perhaps I'll bring that up on [EMAIL PROTECTED] In the meantime, it would be a good policy for us to introduce to Commons, at least, while we're in the process of sorting out our own web site infrastructure. Dion Gillard asked: Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. It is part of the official documentation maintained in the Apache site module by the infrastructure team: - Every project also has a proj-www module that corresponds to the public website specific to that project. This module appears when one goes to the web site http://proj.apache.org;. ref: http://www.apache.org/dev/svc-name-template.html Yep, I've seen this before, but it doesn't seem to be used in practice. - All CVS modules are in the form $project[-$codebase], where $codebase is an optional extension for subclassing the project into a couple separate parts. Decide which CVS modules you want to create. There should be at least one for the web site, $project-site. Create /www/$project.apache.org directory, chmod g+w, chgrp'd to $project. Do a cvs checkout $project-site into that directory ref: http://www.apache.org/dev/project-creation.html - The websites are served from directories under /www on daedalus. But you usually do not edit any content in those directories. Each website is an anonymous CVS checkout of a repository on icarus. ref: http://www.apache.org/dev/committers.html#web That last one goes into more detail. Obviously, the documentation needs a bit of tidying, but the concept is still the same. I am cc'ing infrastructure@, so if there is any change from this infrastructure policy, the team can let everyone know. Otherwise, I think that this remains policy. John Keys asked: Is it not enough to have the source of the site in CVS? For example, the xdocs (and associated artifacts) for a maven generated site. Is there an added benefit to having the generated HTML in CVS also? In the event of some sort of failure, e.g., an accidental deletion or some other problem, the infrastructure team cannot be assumed to have access to the tools, nor knowledge to use them. Plus it would take much longer to restore by re-building than by doing an update from CVS. Shouldn't this be covered by some sort of backup, rather than having CVS as the placeholder? Or by zipping the current site and storing it in an archives directory. Since the sites are almost always generated from tools, having the source and the result in CVS seems overkill. If a project site was to be down due to hardware issues, a small wait while the project team brought it back up shouldn't be too bad. There is also an oversight issue. If there were some sort of defacement (there was a perceived one last year), it can be checked against CVS records (turned out that it was not a hack, just an ill-advised comment that a Commiter had checked in). And those CVS records can be checked against replicated copies. It's far easier to oversee the source than the resulting HTML. In my experience, limited though it is, almost noone read the HTML commits, as they were assumed to be generated from the source. Those are just a few things that occur to me off-hand. I am sure that those who developed the policy in the first place have even more reasons, and experiences behind them. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
Michael Becke wrote: Odi, Eric, I think a combination of these techniques would be great. One level to handle the socket management(as Odi outlined) and another to handle the content creation/validation (Eric's idea). These two methods in tandem should be sufficient to mimic any combination of servers/configurations. Mike I will still use real Sockets. Mimicking a socket is just too an unreal test. I will take Chris Kohlschütters Code as a starting point. I would also love to have a test suite running against a local Tomcat SSL connector. But for the moment the proxy implementation will eat up all my free time... Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does HttpClient decompress compressed HTTP transfers?
It'd be rather easy to wrap the streams in a DeflaterOutputStream or an InflaterInputStream. Of course, due to limitations in Java's deflate compression, one must extend DeflaterOutputStream to allow true stream deflation. The problem with the current implementation is that there is no way to flush a partially deflated stream -- deflate waits until it reaches an optimal spot to actually perform the deflation and do the flush. I was talking about decompression downloads. flush() would only be needed to compress POST or PUT requests and that may be poorly supported. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line
On Monday 17 November 2003 21:05, Oleg Kalnichevski wrote: I have not found any mentioning of unexpected content in the RFC, so this is another reason why I would be a bit cautious about throwing a protocol exception. It would suffice to spit out a warning, drop the connection and move on. Alright. I can live with that. :-) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
On Monday 17 November 2003 20:33, Oleg Kalnichevski wrote: [Disregard my previous post. I responded to a wrong message by mistake] Odi, That would be REALLY cool! A simple authenticating proxy (or a proxy that could effectively 'fake' popular authentication schemes) would be a very much appreciated contribution. By the way, have a look at the Christian Kohlschütter's SimpleHttpServer: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9066 I think that can be a good starting point for a better framework than SimpleHttpconnection. Please have a look at the latest version (see http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093 ). It is more abstract than the BadHTTPServer example for Bug 24560 and truly test independent. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
Christian Kohlschütter wrote: Please have a look at the latest version (see http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093 ). It is more abstract than the BadHTTPServer example for Bug 24560 and truly test independent. What sort of file is that? It seems binary... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line
Christian, Feel free to make changes to the patch that you deem necessary. Once you think it is ready, I suggest we once again ask all the interested parties to raise their objections and express concerns. If there's no significant opposition to the final revision of the patch, and it is OKed by at least by two committers, I'll consider it good to be checked in. Oleg -Original Message- From: Christian Kohlschütter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 11:13 To: Commons HttpClient Project Subject: Re: DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line On Monday 17 November 2003 21:05, Oleg Kalnichevski wrote: I have not found any mentioning of unexpected content in the RFC, so this is another reason why I would be a bit cautious about throwing a protocol exception. It would suffice to spit out a warning, drop the connection and move on. Alright. I can live with that. :-) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
On Tuesday 18 November 2003 11:26, Ortwin Glück wrote: Christian Kohlschütter wrote: Please have a look at the latest version (see http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093 ). It is more abstract than the BadHTTPServer example for Bug 24560 and truly test independent. What sort of file is that? It seems binary... tar.gz Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
Christian Kohlschütter wrote: On Tuesday 18 November 2003 11:26, Ortwin Glück wrote: Christian Kohlschütter wrote: Please have a look at the latest version (see http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093 ). It is more abstract than the BadHTTPServer example for Bug 24560 and truly test independent. What sort of file is that? It seems binary... tar.gz Thanks. I am gonna check your server package in in a minute. Please confirm that the code in attachment 9093 is meant to be published under the Apache License and is not copyright by any third party. I will then include the Apache License. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
On Tuesday 18 November 2003 11:53, Ortwin Glück wrote: Christian Kohlschütter wrote: On Tuesday 18 November 2003 11:26, Ortwin Glück wrote: Christian Kohlschütter wrote: Please have a look at the latest version (see http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9093 ). It is more abstract than the BadHTTPServer example for Bug 24560 and truly test independent. What sort of file is that? It seems binary... tar.gz Thanks. I am gonna check your server package in in a minute. Please confirm that the code in attachment 9093 is meant to be published under the Apache License and is not copyright by any third party. I will then include the Apache License. Odi I own the copyright for this code and I am willing to contribute / publish it under the conditions of the Apache License. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24352] - NLTM Proxy and basic host authorization
Christian Kohlschütter wrote: I own the copyright for this code and I am willing to contribute / publish it under the conditions of the Apache License. Thanks a lot! I will check it in on the 2.0 branch since it is related to a 2.0 bug. As soon as it is ready we can promote it to CVS HEAD. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
read timeout with persistent connection
Greetings,
With HttpClient, I'm using the MultiThreadedHttpConnectionManager, with
all timeout values set to 30s, and I'm seeing a problem against a server
that discards unused connections after several minutes. It seems the
connection close isn't detected by the HttpConnection.isStale() method,
which causes a delay in processing as stream reading blocks waiting for
the socket timeout.
In HttpConnection.isStale, the stream read throws a
SocketTimeoutException which indicates the socket is still alive, so the
connection is reused in HttpMethodBase.processRequest without closing
the socket first.
The request is successfully written via writeRequest, but readResponse
throws a java.net.SocketTimeoutException, after delaying for 30s.
private void processRequest(HttpState state, HttpConnection
connection)
throws HttpException, IOException {
LOG.trace(enter HttpMethodBase.processRequest(HttpState,
HttpConnection));
...
if (!connection.isOpen()) {
// returns true
LOG.debug(Opening the connection.);
connection.open();
}
writeRequest(state, connection);
requestSent = true;
readResponse(state, connection);
// the response read times out
// the method has successfully executed
used = true;
break;
There is a pattern - this happens only after connections have not been
used for a certain period of time, where I presume the origin server is
closing the unused persistent connection. If connections are reused
frequently, then there are no problems - the timeout occurs only when
connections lay idle for a few minutes.
The externally visible behavior to users is that the request takes at
least 30s to execute - the request is retried, so it eventually
succeeds.
Any ideas how I go about fixing this? I'm not entirely sure if this is a
problem with HTTPClient or with the origin server (which is running MS
IIS 4.0, not under my control.)
I've included below a simple test case to demonstrate the problem.
Thanks for any help!
mat mcgowan
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.httpclient.*;
import java.io.IOException;
import junit.framework.TestCase;
public class TestJakartaHttpClient extends TestCase
{
public void testNorgeNo() throws InterruptedException,
IOException
{
httpServer(http://norge.no;, 5*1000*60);
}
public void httpServer(String uri, int delay) throws
IOException, InterruptedException
{
HttpClient client = new HttpClient(new
MultiThreadedHttpConnectionManager());
int timeout = 30*1000;
client.setConnectionTimeout(timeout);
client.setHttpConnectionFactoryTimeout(timeout) ;
client.setTimeout(timeout);
GetMethod m = new GetMethod(uri);
m.setStrictMode(false);
m.setFollowRedirects(false);
m.setDoAuthentication(false);
m.setHttp11(true);
// read data
client.executeMethod(m);
m.getResponseBody();
Thread.sleep(delay);
try
{
m = new GetMethod(uri);
m.setStrictMode(false);
m.setFollowRedirects(false);
m.setDoAuthentication(false);
m.setHttp11(true);
client.executeMethod(m);
m.getResponseBody();
}
catch (HttpRecoverableException ex)
{
fail(ex.toString());
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: read timeout with persistent connection
There is an option to disable stale checking. Matthew McGowan wrote: Any ideas how I go about fixing this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24504] - Cannot create a document that has accent characters (Latin) in it's name
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=24504.
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=24504
Cannot create a document that has accent characters (Latin) in it's name
--- Additional Comments From [EMAIL PROTECTED] 2003-11-18 16:34 ---
Hi Oleg.
Yes, I'am using a multipart post.
In our application we want to upload files to a file server from a java
application via HTTP. We use multipart because we have to include extra
information for the server application to be able to handle the data (ie : link
the file to a database object etc ...). We also want to be able to upload
multiple files (wichi works well as long as we have no accent in the filenames)
--
Here is the code that buids the file parts
HttpClient client = new HttpClient();
MultipartPostMethod httpsPost = new MultipartPostMethod ( m_docServer );
//Set header information
httpsPost.setRequestHeader(Content-Type, multipart/form-data;
boundary=+BOUNDS);
//Adding the main parts.
StringPart partToAdd = new StringPart(ClassUID, classUID);
partToAdd.setTransferEncoding(null);
partToAdd.setContentType(null);
httpsPost.addPart( partToAdd );
partToAdd = new StringPart(MethodName, methodName);
partToAdd.setTransferEncoding(null);
partToAdd.setContentType(null);
httpsPost.addPart( partToAdd );
partToAdd = new StringPart(Params, params);
partToAdd.setTransferEncoding(null);
partToAdd.setContentType(null);
httpsPost.addPart( partToAdd );
//Adding teh files parts.
int i=0;
Iterator iterator = parts.keySet().iterator();
AI_DOCPART part;
String partID;
String partFile;
FilePart fPart;
//loop until we have created all file parts.
while(iterator.hasNext()){
part = (AI_DOCPART)(iterator.next());
partID= part.getIDAsString();
partFile = (String) parts.get(part);
try {
fPart = new FilePart(FILE+(i+1), new File(partFile));
//partToAdd.setContentType(null);
//partToAdd.setTransferEncoding( null );
httpsPost.addPart(fPart);
}
catch (FileNotFoundException e) {
throw new AIException(ERR_INVALIDE_FILENAME,,GUIMediator.getStringResource
(Corporate,ERR_INVALIDE_FILENAME),);
}
partToAdd = new StringPart(PARTNUMBER+(i+1) , partID);
partToAdd.setContentType(null);
partToAdd.setTransferEncoding( null );
httpsPost.addPart( partToAdd );
i++;
}
//Set timeout in Milliseconds - 30 secondes
client.setConnectionTimeout( 3 );
//Send the data
int status=0;
try {
status = client.executeMethod(httpsPost);
}
...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24504] - Cannot create a document that has accent characters (Latin) in it's name
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=24504. 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=24504 Cannot create a document that has accent characters (Latin) in it's name --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 17:30 --- Form-based File Upload in HTML specification (RFC 1867) http://www.ietf.org/rfc/rfc1867.txt that HttpClient implements follows the rules of all multipart MIME data streams as outlined in RFC 1521 and RFC 1522. MIME specification requires all non-ASCII content to be represented using ASCII charset only. Currently HttpClient does not perform such translation automatically. You will have to take care of filename encoding prior to passing it to the FilePart as a parameter. I was going to contribute quote-printable encoder/decoder to the Commons Codec library but never got a chance. To sum things up: if the relevant RFCs are to be strictly adhered to, the behaviour on the part of HttpClient is correct. However, I do agree that it would be nice if HttpClient took care of non-ASCII charset translation automatically. So, feel free to reopen this bug as a feature request. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24309] - MultiThreadedHttpConnectionManager daemon Thread never GC'd
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=24309. 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=24309 MultiThreadedHttpConnectionManager daemon Thread never GC'd [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-19 00:43 --- Patch applied to 2.0 and HEAD. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: read timeout with persistent connection
Ortwin Glück write: There is an option to disable stale checking. Thanks, though turning stale checking off doesn't change the outcome - the readResponse call still blocks for 30s. I don't think it's the stale checking that's causing the problem, but for some reason the server ignores or closes the connection after several minutes of inactivity. Incidentally, I've tried to emulate this using IE 6, and I couldn't reproduce the problem. I believe this is because IE closes persistent connections itself after 60 seconds of inactivity. (See http://www.cs.wisc.edu/~cao/papers/persistent-connection.html. The paper discusses IE 4.01 - though using a network monitor I can confirm this is still true for IE 6.) But, Netscape 7.1 does have the problem. If I load a page from the server, wait a few minutes, and then try a reload, the browser hangs until the socket times out, just as HttpClient does. The network monitor shows the connection closed after a few minutes. As the socket is clearly closed, I have no idea why both netscape and HttpClient can't detect that the socket is closed. I hacked HttpConnection to include a check to call the methods Socket.isClosed/isConnected/isInputShutdown/isOutputShutdown to see if these help determine if the socket is close - all of these indicate that the socket is still alive, yet my network monitor indicates that the connection is closed. The only solution I can see is that perhaps HTTPClient could follow IE's approach and close remove free connections from the connection manager pool after a configurable period of inactivity? Cheers, mat. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
