Re: [general] screwed up Commons site
Local changes to dbcp.html and pool.html can be removed. The cvs version is correct. -- Dirk Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[digester] new rule SetNestedPropertiesRule
Hi, Attached is a rule which behaves like a cross between SetPropertiesRule and BeanPropertySetterRule-with-trailing-wildcard-match. point x7/x y8/y /point digester.addRule(point, new SetNestedPropertiesRule()); Note that the rule doesn't need to use ExtendedBaseRules with trailing wildcard (which is very powerful but not very efficient). It is configured with the pattern matching the parent element. The implementation uses a trick developed for the plugins module: inserting a decorator Rules object that performs custom matching to detect the direct child elements. Yes, this functionality can already be achieved with Digester, but this is pretty efficient and convenient, and this configuration pattern is a common one. Opinions?? Regards, Simon /* * $Header: $ * $Revision: $ * $Date: $ * * * * 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 Apache, 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, *Apache nor may Apache appear in their names without prior *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.commons.digester; import java.util.List; import java.util.LinkedList; import java.util.ArrayList; import java.util.Iterator; import java.util.ListIterator; import java.util.HashMap; import java.beans.PropertyDescriptor; import org.apache.commons.beanutils.BeanUtils; import org.apache.commons.beanutils.DynaBean; import org.apache.commons.beanutils.DynaProperty; import org.apache.commons.beanutils.PropertyUtils; import org.xml.sax.Attributes; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; /** * pRule implementation that sets properties on the object at the top of the * stack, based on child elements with names matching properties on that * object./p * * pExample input that can be processed by this rule:/p * pre * [point] * [x]7[/x] * [y]9[/y] * [/point] * /pre * * pThis rule supports custom mapping of attribute names to property names. * The default mapping for particular attributes can be overridden by using * [EMAIL PROTECTED] #SetNestedPropertiesRule(String[] elementNames, * String[] propertyNames)}. * This allows child elements to be mapped to properties with different names. * Certain elements can also be marked to be ignored./p * * p * A very similar effect can be achieved using a combination of the * BeanPropertySetterRule and the ExtendedBaseRules rules manager; this * Rule, however, works fine with the default RulesBase rules manager./p * *
Re: [digester] new rule SetNestedPropertiesRule
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]
[digester] two very simple plugins patches
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
Index: src/java/org/apache/commons/digester/plugins/PluginCreateRule.java
===
RCS file: /home/cvspublic/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginCreateRule.java,v
retrieving revision 1.8
diff -u -r1.8 PluginCreateRule.java
--- src/java/org/apache/commons/digester/plugins/PluginCreateRule.java 16 Nov 2003 22:37:35 - 1.8
+++ src/java/org/apache/commons/digester/plugins/PluginCreateRule.java 16 Nov 2003 22:47:53 -
@@ -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)
Index: src/java/org/apache/commons/digester/plugins/PluginRules.java
===
RCS file: /home/cvspublic/jakarta-commons/digester/src/java/org/apache/commons/digester/plugins/PluginRules.java,v
retrieving revision 1.6
diff -u -r1.6 PluginRules.java
--- src/java/org/apache/commons/digester/plugins/PluginRules.java 16 Nov 2003 22:37:35 - 1.6
+++ src/java/org/apache/commons/digester/plugins/PluginRules.java 16 Nov 2003 22:46:29 -
@@ -236,6 +236,12 @@
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);
if (rule instanceof InitializableRule) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24747] New: - 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
wrong results and stack overflow error from BivariateRegression
Summary: wrong results and stack overflow error from
BivariateRegression
Product: Commons
Version: Nightly Builds
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Priority: Other
Component: Math
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Example:
import java.util.*;
import org.apache.commons.math.stat.*;
public class RegressionTest
{
public static void main(String[] args)
{
BivariateRegression br1 = new BivariateRegression();
BivariateRegression br2 = new BivariateRegression();
Random random = new Random(1);
int n = 100;
for (int i = 0; i n; i++)
{
br1.addData(((double)i)/(n-1), i); //perfectly correlated
example
br2.addData(((double)i)/(n-1), random.nextDouble());
//uncorrelated example
}
System.out.println(br1.getSignificance()); //should return 0, but
returns NaN instead
System.out.println(br2.getSignificance()); //should return 1, but some
sequences cause stack overflow error!
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24747] - 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 wrong results and stack overflow error from BivariateRegression --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 11:16 --- Created an attachment (id=9142) unit test source code - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24747] - 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 wrong results and stack overflow error from BivariateRegression --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 11:17 --- Created an attachment (id=9143) unit test class file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Closer looking showed that these files had already been updated with cvs clashes. I've reset them to the local cvs. Thanks, Hen On Mon, 17 Nov 2003, Dirk Verbeeck wrote: Local changes to dbcp.html and pool.html can be removed. The cvs version is correct. -- Dirk Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? 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]
Re: Web Presence for ALL Jakarta Commons components
On Thu, 13 Nov 2003, Tim O'Brien wrote: On Thu, 2003-11-13 at 13:59, Noel J. Bergman wrote: You and Martin Cooper both favor Maven. If no one objects, would you guys be willing to do the work? I'm a not a Maven maven. :-) I too would favor Maven and could definately help with the transition. OK, that's three: Mark, Martin and Brett. Is there any reason to NOT do this? If not, I'd suggest that the three of you coordinate efforts, and do it. Count me on the list, I've done a fair amount of Mavenizing already, but most of it has been undercover :-) Ditto. Am prepared to put time into achieving a common lf for Commons. Couple of complaints about Maven: 1) I don't want to have to build every project [ie figure out weird Sun dependencies] just to push up a global site change. I can accept this though. 2) The standard 'project documentation' section gets placed at the bottom when it's the most important information for a specific project. We replicate most of this in other sections. This replication can be a bit odd though, ie) contributors page and the maven generated project team page. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Hen, 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. What are you planning to do with the docs here? Mike On Nov 16, 2003, at 11:58 PM, Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? 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]
cvs commit: jakarta-commons/math project.properties
mdiggory2003/11/17 12:55:34 Modified:math project.properties Log: Test commit. Revision ChangesPath 1.10 +1 -1 jakarta-commons/math/project.properties Index: project.properties === RCS file: /home/cvs/jakarta-commons/math/project.properties,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- project.properties15 Nov 2003 20:59:34 - 1.9 +++ project.properties17 Nov 2003 20:55:34 - 1.10 @@ -16,4 +16,4 @@ http://jakarta.apache.org/commons/beanutils/api/,\ http://jakarta.apache.org/commons/lang/api/,\ http://jakarta.apache.org/commons/discovery/api/,\ - http://jakarta.apache.org/commons/logging/api/ + http://jakarta.apache.org/commons/logging/api/ \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math project.properties
mdiggory2003/11/17 12:56:13 Modified:math project.properties Log: Test commit. Revision ChangesPath 1.11 +2 -1 jakarta-commons/math/project.properties Index: project.properties === RCS file: /home/cvs/jakarta-commons/math/project.properties,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- project.properties17 Nov 2003 20:55:34 - 1.10 +++ project.properties17 Nov 2003 20:56:13 - 1.11 @@ -16,4 +16,5 @@ http://jakarta.apache.org/commons/beanutils/api/,\ http://jakarta.apache.org/commons/lang/api/,\ http://jakarta.apache.org/commons/discovery/api/,\ - http://jakarta.apache.org/commons/logging/api/ \ No newline at end of file + http://jakarta.apache.org/commons/logging/api/ + \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/primitives/xdocs faq.xml navigation.xml
rwaldhoff2003/11/17 13:00:44
Modified:primitives/xdocs faq.xml navigation.xml
Log:
update faq
Revision ChangesPath
1.2 +12 -8 jakarta-commons/primitives/xdocs/faq.xml
Index: faq.xml
===
RCS file: /home/cvs/jakarta-commons/primitives/xdocs/faq.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- faq.xml 16 Nov 2003 23:20:21 - 1.1
+++ faq.xml 17 Nov 2003 21:00:44 - 1.2
@@ -15,7 +15,7 @@
dd
p
The main advantage of the primitive collections is that they are signficantly
smaller than their java.util equivalents.
-How much smaller? Well, consider this table:
+How much smaller?
/p
table border=1 cellspacing=0
tr
@@ -82,26 +82,30 @@
data.
/p
p
-In the pre-autoboxing (JDK 1.5) world, you may also find the primitive collections
easier
+Finally, in the pre-autoboxing (JDK 1.5) world, you may also find the primitive
collections easier
to work with, since you'll waste fewer keystrokes manually boxing and un-boxing the
primitives and their Object wrappers. For instance, to sum an ArrayList of
Integers, you
might write something like:
/p
-preint sum = 0;
+pre
+int sum = 0;
for(Iterator iter = list.iterator(); iter.hasNext(); ) {
sum += ((Integer)(iter.next())).intValue();
-}/pre
+}
+/pre
p
The IntList equivalent would be:
/p
-preint sum = 0;
+pre
+int sum = 0;
for(IntIterator iter = list.iterator(); iter.hasNext(); ) {
sum += iter.next();
-}/pre
+}
+/pre
/dd
-dtQ: But isn't this overkill? Aren't the time and space efficiencies
-insignificant for the size and number of collections used by most applications?/dt
+dtQ: But aren't the time and space efficiencies insignificant for
+the size and number of collections used by most applications?/dt
dd
p
Yes.
1.3 +1 -0 jakarta-commons/primitives/xdocs/navigation.xml
Index: navigation.xml
===
RCS file: /home/cvs/jakarta-commons/primitives/xdocs/navigation.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- navigation.xml27 Oct 2003 20:55:56 - 1.2
+++ navigation.xml17 Nov 2003 21:00:44 - 1.3
@@ -8,6 +8,7 @@
body
menu name=Commons Primitives
item name=Overview href=/index.html/
+ item name=FAQ href=/faq.html/
/menu
commons-nav;
/body
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
J.Pietschmann wrote:
Paul Libbrecht wrote:
a.) logging:
I don't really agree here. I do think it is very useful for any system
to be able to raise a logging verbosity at any-time so that bugs and
misunderstandings can be tracked.
It depends on the complexity of the stuff potentially being prepared
for logging. I don't think [math] is already complex enough that
built-in logging is warranted. The implemented algorithms should be
reasonably fail-safe for the most part. Failures could be sensibly
handled with exceptions, and data for tracking down the problem (e.g.
convergence problems in the solver) should be available. If not, this
should be corrected of course.
The issues where I found Logging occurring where in situations such as
this catch in GammaDistributionImpl
/**
* For this disbution, X, this method returns P(X le; x).
* @param x the value at which the PDF is evaluated.
* @return PDF for this distribution.
*/
public double cummulativeProbability(int x) {
double ret;
if (x 0) {
ret = 0.0;
} else if (x = getNumberOfTrials()) {
ret = 1.0;
} else {
try {
ret = 1.0 - Beta.regularizedBeta(getProbabilityOfSuccess(),
x + 1.0, getNumberOfTrials() - x);
} catch (MathException ex) {
LogFactory.getLog(getClass()).error(
Failed to compute cummulative probability,
returning NaN.,ex);
ret = Double.NaN;
}
}
return ret;
}
I removed instances of this Logging entry in an earlier commit. I think
awhile back there was allot of discussion about if this should throw an
exception or return NaN. The origin of this exception is a Convergence
Exception in ContinuedFraction. The big question is the same as before,
should this convergence exception be passed out and handled by the
application or should it be suppressed internally the way it is here?
-Mark
--
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]
DO NOT REPLY [Bug 24762] New: - CollectionWrapper should implement Serializable
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=24762. 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=24762 CollectionWrapper should implement Serializable Summary: CollectionWrapper should implement Serializable Product: Commons Version: 2.1 Final Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Collections AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The CollectionWrapper inner class (part of CollectionUtils) should implement Serializable. This would allow the creation of serializable lists in the event that the user needs this functionality. Making this change would assume that all the objects contained in the list were serializable (not a big deal IMO.) I discovered this problem when using ListUtils.lazyList() method. The resulting list is not serializable and I need it to be. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
1) I don't want to have to build every project [ie figure out weird Sun dependencies] just to push up a global site change. I can accept this though. I know diddly about the multi-project capabilities of Maven at this point, but I'm kinda hoping it will take care of this kind of thing... No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) Cheers, Brett
Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here? As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/clazz project.xml
dirkv 2003/11/17 13:40:35 Modified:clazzproject.xml Log: make clazz buildable Revision ChangesPath 1.2 +1 -3 jakarta-commons-sandbox/clazz/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/clazz/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 9 Jan 2003 03:23:58 - 1.1 +++ project.xml 17 Nov 2003 21:40:34 - 1.2 @@ -35,8 +35,7 @@ dependencies dependency idjunit/id - typerequired/type - version3.7/version + version3.8.1/version /dependency dependency idant+optional/id @@ -48,7 +47,6 @@ /dependency dependency idcommons-collections/id - typerequired/type version2.1/version /dependency /dependencies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/clazz/xdocs index.xml
dirkv 2003/11/17 13:41:27
Added: clazz/xdocs index.xml
Log:
copy of overview.xml to have something on the homepage
Revision ChangesPath
1.1 jakarta-commons-sandbox/clazz/xdocs/index.xml
Index: index.xml
===
?xml version=1.0 encoding=UTF-8?
document
properties
title
Clazz Overview
/title
author email=[EMAIL PROTECTED]
Dmitri Plotnikov
/author
/properties
body
section name=Clazz
p
Clazz is an upgrade to the Java Beans mechanisms, reflecting new
requirements, new de facto standards and a wider range of potential
applications.
/p
ul
lia href=#RequirementsRequirements/a
ul
lia href=#Project Contributed RequirementsProject Contributed
Requirements/a
/li
/ul
/li
!--
lia href=#Clazz ClassClazz Class/a
/li
lia href=#Client Side of ClazzClient Side of Clazz/a
ul
lia href=#Description ProviderDescription Provider/a/li
lia href=#Metadata ProviderMetadata Provider/a/li
/ul
/li
--
/ul
/section
section name=Requirements
p
Introduced by Stephen Colebourne, here's the initial list of
requirements (lifted from PROPOSAL.html):
/p
p
The package should:
/p
p
ul
liHandle all classes, not just beans/li
liSupport extensible metadata (not just for GUI builders)/li
liHandle normal (today) bean conventions (get/set/add/put methods)/li
liHandle future conventions that are not yet standard/li
liSupport method overloading/li
liProvide a complete alternative to using java.beans.Introspector/li
liBe simple to learn/li
/ul
/p
subsection name=Project Contributed Requirements
p
lt;TBDgt; - requirements contributed by potential users of clazz
go here.
/p
/subsection
/section
section name=Clazz Class
p
The best way to introduce the Clazz class is by comparing it to the
java.lang.Class class. Though both serve the same function as runtime
meta-data about a type, there are several important differences:
ul
li
Class is a final class embedded in the JVM. Its behavior cannot be
customized or enhanced. Clazz is an abstract class
and allows many alternative implementations.
/li
li
Class describes a Java type in terms of fields, methods and
constructors.
Clazz describes a type in terms of properties, operations
and instance factories. In the case when a Clazz represents a Java
class,
those properties, operations and instance factories may or may not map
directly to fields, methods and constructors. The mapping is determined
by the
implementation of the Clazz and can be quite non-trivial. For example,
a Clazz may map pairs of Java methods like getFoo() and setFoo() to a
single property called foo. There may be many ways to describe the same
Java class with a Clazz.
/li
li
Class is restricted to describing Java types.
Clazz does not have that limitation. A Clazz can be created dynamically
out
of piece parts.
/li
/ul
/p
/section
section name=Client Side of Clazz
p
The client sees Clazz as a set of interfaces.
The following code illustrates a basic interaction between a
client and the Clazz package:
/p
!-- + SOURCE + --
source
b/
public class MyExample1 {
void listAllOperations(){
// Step 1. Obtain the ClazzLoader associated with the default
// clazz model. Provide a ClassLoader as a context
// for reflection.
ClazzLoader clazzLoader =
Clazz.getDefaultClazzLoader(MyExample1.class.getClassLoader());
// Step 2. Find the Clazz
Clazz clazz = clazzLoader.getClazzForName(my.example.Example);
// Step 3. Obtain operation descriptions from the clazz
List operations = clazz.getOperations();
for (Iterator iter = operations.iterator(); iter.hasNext();) {
ClazzOperation operation = (ClazzOperation) iter.next();
System.out.println(Operation: +
cvs commit: jakarta-commons-sandbox/clazz/xdocs/stylesheets project.xml
dirkv 2003/11/17 13:43:35 Modified:clazz/xdocs/stylesheets project.xml Log: fix some nbsp; Revision ChangesPath 1.2 +6 -6 jakarta-commons-sandbox/clazz/xdocs/stylesheets/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/clazz/xdocs/stylesheets/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 9 Jan 2003 03:24:01 - 1.1 +++ project.xml 17 Nov 2003 21:43:35 - 1.2 @@ -9,12 +9,12 @@ -- body menu name=Home - item name=Jakartaamp;nbsp;Commons href=http://jakarta.apache.org/commons/; / + item name=Jakarta#xA0;Commons href=http://jakarta.apache.org/commons/; / item name=Clazzhref=/overview.html / /menu menu name=Information item name=Overview href=/overview.html/ - item name=APIamp;nbsp;Docshref=/apidocs/index.html/ + item name=API#xA0;Documentationhref=/apidocs/index.html/ !-- item name=News href=http://jakarta.apache.org/commons/pool/news.html/ item name=User's Guide href=/users-guide.html/ @@ -23,7 +23,7 @@ menu name=Project Files item name=Status href=http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons-sandbox/clazz/STATUS.html?content-type=text/html/ item name=CVS href=http://cvs.apache.org/viewcvs/jakarta-commons/clazz// - item name=Originalamp;nbsp;Proposal href=http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons-sandbox/clazz/PROPOSAL.html?content-type=text/html/ + item name=Original#xA0;Proposal href=http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons-sandbox/clazz/PROPOSAL.html?content-type=text/html/ /menu menu name=Downloads !-- @@ -36,9 +36,9 @@ item name=License href=http://jakarta.apache.org/commons/license.html/ /menu menu name=Jakarta Community - item name=Getamp;nbsp;Involved href=http://jakarta.apache.org/site/getinvolved.html/ - item name=Mailingamp;nbsp;Lists href=http://jakarta.apache.org/site/mail.html/ - item name=CVSamp;nbsp;Repositories href=http://jakarta.apache.org/site/cvsindex.html/ + item name=Get#xA0;Involved href=http://jakarta.apache.org/site/getinvolved.html/ + item name=Mailing#xA0;Lists href=http://jakarta.apache.org/site/mail.html/ + item name=CVS#xA0;Repositories href=http://jakarta.apache.org/site/cvsindex.html/ /menu /body /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jjar/xdocs index.xml
dirkv 2003/11/17 13:46:23 Added: jjar/xdocs index.xml Log: copy of jjar.xml as homepage Revision ChangesPath 1.1 jakarta-commons-sandbox/jjar/xdocs/index.xml Index: index.xml === ?xml version=1.0? document properties titleJJAR/title author email=[EMAIL PROTECTED]Geir Magnusson Jr./author /properties body section name=JJAR : Jakarta JAR Archive Repository p ol li a href=jjar.html#introductionIntroduction/a /li li a href=jjar.html#The RepositoryThe Repository/a /li li a href=jjar.html#The ToolsetThe Toolset/a ul li a href=jjar.html#commandlineJava Commandline Tool/a /li li a href=jjar.html#anttoolJakarta Ant Support/a /li /ul /li li a href=jjar.html#use casesUse Cases/a ul li a href=jjar.html#listrepoListing The Repository/a /li li a href=jjar.html#listsingleListing the Details of a Single Package/a /li li a href=jjar.html#verifyjarVerifying a Jar/a /li li a href=jjar.html#fetchpackageFetching a Package/a /li li a href=jjar.html#antselfdepProject Build Self-Dependency with Ant/a /li /ul /li /ol /p /section section name=Introduction p bJJAR/b is an acronym for Jakarta JAR Archive Repository, an attempt at making a a href=http://www.cpan.org;CPAN/a-like service/infrastructure for the Java development community. /p p bNote :/b iUntil JJAR is officially in production, no guarantees will be made as to the correctness of the delivered jars. Best efforts will be made, but at any time, what you get might not be what you want./i /p p Currently, JJAR is an experimental work in progress. It does work as advertised, and every effort is being made to ensure that it works at any point in time. However, as we are learning about what works and what doesn't, change will happen. Further this is currently not an official Jakarta Commons project, but a well-organized sandbox project. Therefore, production dependencies are discouraged. /p p bRepeat :/b i JJAR is neither an official Jakarta project, nor an official Jakarta Commons project. This document may have been found via a http://jakarta.apache.org/jjar/ link - it is there for information purposes for the repository./i /p p Ok. Now that that's over, simply put, JJAR consists of two parts : /p ul li A distributed repository consisting of jars from various projects (which we call ipackages/i) as well as version and dependency information about those packages. This logical repository consists of a central main repository, and any number of sub-repositories, each responsible for a given project (or projects.) /li li A toolset to allow the navigation and fetching from this repository, as well as direct access to repository information, such as project dependencies. /li /ul p Together, these two parts [hopefully] make up a complete system for package management and delivery for building Java applications. /p /section section name=The Repository p As currently defined, a repository physically consists of a directory containing a irepository descriptor/i, an XML file containing repository information, and a set of jars described by that descriptor. /p p There is no strict requirement as to how a repository is implemented. The expected common implementation will be via http through a regular web server (no server-side programmatic support will be required.) However, in the case of local or enterprise use, it is expected that local file access will be enough. The technical limitation will be that there is a protocol handler for the access method of choice. /p p The central repository will be located on http://jakarta.apache.org/jjar/. The central repository will contain information on any project that does not want to host it's own repository. For any project that does host it's own repository (a iremote repository/i), the central repository will simply contain information about the remote repository. The JJAR toolkit will use this information to tie the central and remote repositories together in a seamless manner. /p p The repository is distributed for several reasons : /p ul li This reduces the maintenance load on the Jakarta volunteers that manage JJAR. /li li It allows easy inclusion of non-Jakarta projects. /li li It allows the developers of
cvs commit: jakarta-commons-sandbox/jjar project.xml
dirkv 2003/11/17 13:53:14 Added: jjar project.xml Log: minimal maven project Revision ChangesPath 1.1 jakarta-commons-sandbox/jjar/project.xml Index: project.xml === ?xml version=1.0? project extend../../jakarta-commons/xdocs/maven/project-base.xml/extend nameCommons JJar/name idcommons-jjar/id logo/images/jjar-logo-blue.jpg/logo urlhttp://jakarta.apache.org/commons/jjar//url inceptionYear2001/inceptionYear shortDescriptionCommons JJar/shortDescription descriptionCommons JJar/description currentVersion0.1-dev/currentVersion versions /versions branches /branches developers developer nameGeir Magnusson Jr./name idgeirm/id email/email organization/organization /developer developer nameJason van Zyl/name idjvanzyl/id email/email organization/organization /developer /developers dependencies dependency idjunit/id version3.8.1/version /dependency !-- these two are required by maven -- dependencyidxml-apis/idversion2.0.2/version/dependency dependencyidxerces/idversion2.0.2/version/dependency !-- /these two are required by maven -- /dependencies /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Web Presence for ALL Jakarta Commons components = updates for cache, clazz, jjar
Previews here: http://cvs.apache.org/~dirkv/cache/ http://cvs.apache.org/~dirkv/clazz/ http://cvs.apache.org/~dirkv/jjar/ cache is a totally new site that follows the dbcp/pool style clazz jjar had some existing content and I did just some minimal fix to make them buildable. (restyle can be done later) If there are no objections I'll push them to the site tomorrow. -- Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] wanted: svg/jpg artist to build component logos
Lots of (sandbox) components don't have a logo yet. Therefor it would be nice to have a tool to auto create logos like: http://jakarta.apache.org/commons/dbcp/images/dbcp-logo-blue.jpg as seen on http://jakarta.apache.org/commons/dbcp/ I'm thinking of a script to build a svg image = jpg. Are there some svg artists out there willing to help a hand? We need a white on blue Commons logo as well. Cheers Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Tokenizer.java
scolebourne2003/11/17 15:02:18
Added: lang/src/test/org/apache/commons/lang TokenizerTest.java
lang/src/java/org/apache/commons/lang Tokenizer.java
Log:
Initial checkin of the Tokenizer class
Revision ChangesPath
1.1
jakarta-commons/lang/src/test/org/apache/commons/lang/TokenizerTest.java
Index: TokenizerTest.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2002-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 SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*/
package org.apache.commons.lang;
import junit.framework.Test;
import junit.framework.TestCase;
import junit.framework.TestSuite;
import junit.textui.TestRunner;
/**
* Unit test for Tokenizer.
*
* @author Matthew Inger
*/
public class TokenizerTest extends TestCase {
/**
* JUnit constructor.
* @param name
*/
public TokenizerTest(String name) {
super(name);
}
public static Test suite() {
TestSuite suite = new TestSuite(TokenizerTest.class);
suite.setName(TokenizerTest Tests);
return suite;
}
public static void main(String[] args) {
TestRunner.run(suite());
}
//---
public void test1() {
String input = a;b;c;\d;\\e\;f; ; ;;
Tokenizer tok = new Tokenizer(input);
tok.setDelimiterChar(';');
String tokens [] = tok.getAllTokens();
String expected[] = new String[]
{
a,
b,
c,
d;\e,
f,
,
,
,
};
assertTrue(tokens.length == expected.length);
for (int i = 0; i expected.length; i++) {
assertTrue(token[ + i + ] was ' + tokens[i]
+ ' but was expected to be ' + expected[i]
+ ',
ObjectUtils.equals(expected[i], tokens[i]));
}
}
public void test2() {
String input = a;b;c ;\d;\\e\;f; ; ;;
Tokenizer tok = new Tokenizer(input);
tok.setDelimiterChar(';');
DO NOT REPLY [Bug 22692] - StringUtils.split ignores empty items
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=22692. 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=22692 StringUtils.split ignores empty items --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 23:02 --- Initial version now checked in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Paul Libbrecht wrote: Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here? As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? Paul That sounds kinda cynical ;-) My ultimate sentiment is to just get it passed on out and let the application manage exceptions dealing with non-convergence. Maybe thats the simplest possible comprimise? Then the user can decide what they will do when convergence fails instead of having the application suppress the exception and force them to test for NaN conditions all the time? -M. -- 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]
Re: [all] wanted: svg/jpg artist to build component logos
Quoting Dirk Verbeeck [EMAIL PROTECTED]: Lots of (sandbox) components don't have a logo yet. Therefor it would be nice to have a tool to auto create logos like: http://jakarta.apache.org/commons/dbcp/images/dbcp-logo-blue.jpg as seen on http://jakarta.apache.org/commons/dbcp/ I'm thinking of a script to build a svg image = jpg. Are there some svg artists out there willing to help a hand? We need a white on blue Commons logo as well. Cheers Dirk Well, here's a basic SVG logo. Perhaps someone else could come up with a better font (I'm using verdana) and the script to convert it to png or jpg. Something like this might be a nice little plugin for maven. --- jaaron http://jadetower.orgattachment: logo.svg- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote: Paul Libbrecht wrote: Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? That sounds kinda cynical ;-) By no means ! My ultimate sentiment is to just get it passed on out and let the application manage exceptions dealing with non-convergence. Maybe thats the simplest possible comprimise? Then the user can decide what they will do when convergence fails instead of having the application suppress the exception and force them to test for NaN conditions all the time? But I would expect that it is not the application itself and not even the user which will receive the NaN but some other, say a graph-component (they should be quite happy with that), or something else... I had a case recently where I made a little integrer calculator offering +-*/ within a kind of console. And it turned out was important for this usage to have a message that said that the 7 was not dividable by 3. Having NaN somewhere (hence everywhere with these operations) would have just told the user something like Huh ?. (plus some people tend even to indicate wether this is positive-zero or negative-zero (when doing elementary limits) which would yeald us positive-NaN or negative-NaN !!). But maybe I'm going too far... sorry... Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Paul Libbrecht wrote: Mark R. Diggory wrote: Paul Libbrecht wrote: Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? That sounds kinda cynical ;-) By no means ! My ultimate sentiment is to just get it passed on out and let the application manage exceptions dealing with non-convergence. Maybe thats the simplest possible comprimise? Then the user can decide what they will do when convergence fails instead of having the application suppress the exception and force them to test for NaN conditions all the time? But I would expect that it is not the application itself and not even the user which will receive the NaN but some other, say a graph-component (they should be quite happy with that), or something else... I had a case recently where I made a little integrer calculator offering +-*/ within a kind of console. And it turned out was important for this usage to have a message that said that the 7 was not dividable by 3. Having NaN somewhere (hence everywhere with these operations) would have just told the user something like Huh ?. (plus some people tend even to indicate wether this is positive-zero or negative-zero (when doing elementary limits) which would yeald us positive-NaN or negative-NaN !!). But maybe I'm going too far... sorry... Paul No, not too far at all, thats a great usage example for why exceptions here may be more beneficial in the long run! -- 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]
[PATCH] Fix for spelling typos in UserGuide
Title: Message While checking out some of the commons projects I saw the announcement thatapache.commons.math just graduated from the sandbox. Congratulations! During my 5 second tour of the docs,I aminor yet glaring typo in the users guide. That is unless you really did mean to misspell"org.apache.commons.matn.utitlities". Anyway, this patch should fix it. Great job on the project! This is some great stuff! Doug P.S. The patch in provided as both an attachment and included in plain text below... Index: overview.xml===RCS file: /home/cvspublic/jakarta-commons/math/xdocs/userguide/overview.xml,vretrieving revision 1.5diff -r1.5 overview.xml61c61 lia href=""org.apache.commons.matn.utitlities/a - common math/stat functions extending java.lang.Math /li--- lia href=""org.apache.commons.math.util/a - common math/stat functions extending java.lang.Math /li Index: overview.xml === RCS file: /home/cvspublic/jakarta-commons/math/xdocs/userguide/overview.xml,v retrieving revision 1.5 diff -r1.5 overview.xml 61c61 lia href=utilities.htmlorg.apache.commons.matn.utitlities/a - common math/stat functions extending java.lang.Math /li --- lia href=utilities.htmlorg.apache.commons.math.util/a - common math/stat functions extending java.lang.Math /li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [all] wanted: svg/jpg artist to build component logos
FYI, I think the version attribute must be 1.0 and not 1 in the svg file. At least that is what XML Spy complains about when validating the document. Gary -Original Message- From: J Aaron Farr [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 15:29 To: Jakarta Commons Developers List Subject: Re: [all] wanted: svg/jpg artist to build component logos Quoting Dirk Verbeeck [EMAIL PROTECTED]: Lots of (sandbox) components don't have a logo yet. Therefor it would be nice to have a tool to auto create logos like: http://jakarta.apache.org/commons/dbcp/images/dbcp-logo-blue.jpg as seen on http://jakarta.apache.org/commons/dbcp/ I'm thinking of a script to build a svg image = jpg. Are there some svg artists out there willing to help a hand? We need a white on blue Commons logo as well. Cheers Dirk Well, here's a basic SVG logo. Perhaps someone else could come up with a better font (I'm using verdana) and the script to convert it to png or jpg. Something like this might be a nice little plugin for maven. --- jaaron http://jadetower.org
RE: Web Presence for ALL Jakarta Commons components
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 3:28 PM To: 'Jakarta Commons Developers List' Subject: RE: Web Presence for ALL Jakarta Commons components No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Web Presence for ALL Jakarta Commons components
Great! Actually, we recently discussed one such javamail alternative on the Maven list, but if there is one at Apache, even better. Here is the list of replacements needed: http://maven.apache.org/sun-licensing-journey.html Cheers, Brett -Original Message- From: Brent Worden [mailto:[EMAIL PROTECTED] Sent: Tuesday, 18 November 2003 1:29 PM To: Jakarta Commons Developers List Subject: RE: Web Presence for ALL Jakarta Commons components -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 3:28 PM To: 'Jakarta Commons Developers List' Subject: RE: Web Presence for ALL Jakarta Commons components No, the problem with Sun dependencies is that, at present, Maven is not allowed to automatically download them from a publicly accessible repository. However, this is just something each person needs to setup once (eg download/obtain javamail 1.2 and put it into $HOME/.maven/repository/javamail/jars/javamail-1.2.jar), and most of the JARs are probably lying around on your system somewhere anyway :) The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Brent Worden http://www.brent.worden.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
They are however in CVS, so if we do a cvs update it'll change those files. cvs server: Updating httpclient M httpclient/applications.html M httpclient/downloads.html M httpclient/features.html M httpclient/index.html M httpclient/news.html M httpclient/overview.html M httpclient/proposal.html M httpclient/status.html To fix the Lang url on sites, we need to cvs update a large number of files. Easy way to do that will be a simply 'cvs update'. Hen On Mon, 17 Nov 2003, Michael Becke wrote: Hen, 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. What are you planning to do with the docs here? Mike On Nov 16, 2003, at 11:58 PM, Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? 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]
RE: [general] screwed up Commons site
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]
RE: Web Presence for ALL Jakarta Commons components
The geronimo project has written clean-room implementations of most J2EE APIs. Maybe we can get them to deploy javamail to ibiblio. Only the interface. It does not operate, AFAIK. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Jira (was RE: [CLI] 2.x Tasks)
On Sun, 2 Nov 2003, Rob Oxspring wrote: I'm happy to switch to jira as and when, although I've used it before for reporting the grand total of 1 bug but I expect it'll be straight forward. Anything's going to be a bit nicer than bugzilla! Just to throw in my tuppence, I've been using JIRA at work and at http://www.osjava.org. Apart from a worry that the sheer number of projects will make the default front page unworkable, JIRA is a joy to use. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Messenger examples
On Wed, 5 Nov 2003, J Aaron Farr wrote: On Tue, 2003-11-04 at 14:29, Aviran wrote: Hi, I'm new to JMS and Jakarta's messenger, I would like to know if there is a sample application with step by step instructions of how to use messenger? Though I have a question for the messenger developers: What's the roadmap on this? What needs done before it could graduate to commons proper? As far as I know James Strachan was the main developer and I think his time is spent on other things now [Groovy/Geronimo]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Jira (was RE: [CLI] 2.x Tasks)
The default dashboard can be configured too, so that can be made more managable for new users who don't or won't customise their own one. - Brett -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Tuesday, 18 November 2003 2:36 PM To: Jakarta Commons Developers List Subject: Re: Using Jira (was RE: [CLI] 2.x Tasks) On Sun, 2 Nov 2003, Rob Oxspring wrote: I'm happy to switch to jira as and when, although I've used it before for reporting the grand total of 1 bug but I expect it'll be straight forward. Anything's going to be a bit nicer than bugzilla! Just to throw in my tuppence, I've been using JIRA at work and at http://www.osjava.org. Apart from a worry that the sheer number of projects will make the default front page unworkable, JIRA is a joy to use. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
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? Mike On Nov 17, 2003, at 10:29 PM, Noel J. Bergman wrote: 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: [general] screwed up Commons site
Do you suggest removing the HttpClient docs from CVS? Mike On Nov 17, 2003, at 10:16 PM, Henri Yandell wrote: They are however in CVS, so if we do a cvs update it'll change those files. cvs server: Updating httpclient M httpclient/applications.html M httpclient/downloads.html M httpclient/features.html M httpclient/index.html M httpclient/news.html M httpclient/overview.html M httpclient/proposal.html M httpclient/status.html To fix the Lang url on sites, we need to cvs update a large number of files. Easy way to do that will be a simply 'cvs update'. Hen On Mon, 17 Nov 2003, Michael Becke wrote: Hen, 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. What are you planning to do with the docs here? Mike On Nov 16, 2003, at 11:58 PM, Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24765] New: - The current code assumes the platforms default encoding is iso-8859-1
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=24765.
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=24765
The current code assumes the platforms default encoding is iso-8859-1
Summary: The current code assumes the platforms default encoding
is iso-8859-1
Product: Commons
Version: 1.0 Final
Platform: Other
OS/Version: OS/400
Status: NEW
Severity: Major
Priority: Other
Component: File Upload
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Currently the jakarta commons File Upload assumes that the default platform
character encoding is iso-8859-1(or some variant), which is not always the case
causing it to operate incorrectly. Below I have identified all classes that do
not support multiple types of encoding. I have put together a solution below
that points out the majority of areas that require the encoding to be
specified. I realize that this is not the most efficient code, but I leave
that up to you to implement it the best way. Please let me know if this is an
acceptable solution and when a new release could be made.
Class org.apache.commons.fileupload.FileUpload
--
Line 331:
byte[] boundary = contentType.substring(contentType.indexOf(boundary=) +
9).getBytes();
//Make sure the bytes match the servlets inputStream bytes
byte[] boundary = contentType.substring(contentType.indexOf(boundary=) +
9).getBytes(req.getCharacterEncoding());
Class org.apache.commons.fileupload.MultipartStream
-
Line 282
this.boundary[0] = 0x0D;
this.boundary[1] = 0x0A;
this.boundary[2] = 0x2D;
this.boundary[3] = 0x2D;
this.boundary[0] = new String(new byte[]{Character.LINE_SEPARATOR}, iso-8859-
1).getBytes()[0];
this.boundary[1] = new String(new byte[]{Character.LETTER_NUMBER}, iso-8859-
1).getBytes()[0];
this.boundary[2] = new String(new byte[]{0x2D},iso-8859-1).getBytes()[0];
this.boundary[3] = new String(new byte[]{0x2D},iso-8859-1).getBytes()[0];
Line 293
if (arrayequals(marker, STREAM_TERMINATOR, 2))
if (arrayequals(marker, new String(STREAM_TERMINATOR,iso-8859-1 ).getBytes
(getHeaderEncoding()), 2))
Line 396
else if (arrayequals(marker, FIELD_SEPARATOR, 2))
else if (arrayequals(marker, new String(FIELD_SEPARATOR,iso-8859-1).getBytes
(getHeaderEncoding()), 2))
Line 480
if (b[0] == HEADER_SEPARATOR[i])
if (b[0] == new String(HEADER_SEPARATOR,iso-8859-1).getBytes
(getHeaderEncoding())[i])
etc
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
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]
DO NOT REPLY [Bug 24747] - 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 wrong results and stack overflow error from BivariateRegression --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 06:04 --- Created an attachment (id=9149) This patch fixes both problems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 Summary|wrong results and stack |[math] wrong results and |overflow error from |stack overflow error from |BivariateRegression |BivariateRegression --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 06:07 --- The 11/18 attachment should fix both problems. It changes the regularizedBeta routine to fix the random correlation case and it modifies the BivariateRegression sums of squares updating formulas to fix the perfect correlation case. - 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
[EMAIL PROTECTED] wrote: Oleg, I agree, our lack of auth/proxy tests is a continuous source of problems. One of our goals for 2.1 should be an effective method for testing all of the various combinations of proxy, authentication and SSL. Ideally it would be best to make this setup as simple as possible. Do you have any thoughts about how we can best accomplish this? Mike The various authentication methods should be tested against servlets in the Test-Webapp. As to proxies, we must implement a couple of tiny local servers running on different ports. Like: TCP 81: Proxy TCP 82: SSL Proxy Those servers should be started and stopped by the test fixtures (setup / teardown). The servers must be configurable as to which authentication method they use. This will also ensure quality of the various authentication methods, as currently their test cases are somewhat minimalistic. I'd love to hack up some code for the server side this week. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Does HttpClient decompress compressed HTTP transfers?
Hi, If i send the right accept-encoding headers, the web-server may answer with a gzip or deflate compressed stream. Does HttpClient decompress it? If yes, how can i turn that off? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does HttpClient decompress compressed HTTP transfers?
Sven Köhler wrote: If i send the right accept-encoding headers, the web-server may answer with a gzip or deflate compressed stream. Does HttpClient decompress it? No, it doesn't. - 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
My take is slightly different (and I wish I had time to implement it) Start by virtualizing the access to the connection, and then, rather than having multiple servers, just have different implementations of a virtualized socket interface, for example. Then see to writing test cases that look something like this: # This marks what the server is supposed to receive, note that this is not # literally what is received, because headers might be sent in a different order # for example. GET /foo HTTP/1.1 @Host: http://localhost:8080 @Content-Length: 30 @End-Headers # Note that on content lines, the CRLF (or just LF) should be # discarded. Instead, CRLF pairs should be explicitly encoded, perhaps # with %CRLF%? Content should (must?) allow substitutions, for example # multi-part boundaries. Perhaps do substitution with something like # %BOUNDARY% @Content: Content goes here # the following would wait for three seconds before sending more # content... @Wait: 3000 @Content: Yet more content here... HTTP/1.1 # Note, here since the test case knows the response it is supposed to # send, it can (by and large) simply send it. @Content: . and so on I spend a lot of time working with XML, so I thought about doing some sort of test-framework like the above using XML instead. which would get rid of some of the bizarre syntax that I suggest above, but I'm not sure whether that makes sense in the context of HttpClient. My idea would be to take cases where we want to talk to actual servers, and replace them with test cases like the above, wherein we could mimick (or exactly duplicate) the odd behavior of various servers. Hopefully this gives someone else an idea -Eric. Ortwin Gluck wrote: [EMAIL PROTECTED] wrote: Oleg, I agree, our lack of auth/proxy tests is a continuous source of problems. One of our goals for 2.1 should be an effective method for testing all of the various combinations of proxy, authentication and SSL. Ideally it would be best to make this setup as simple as possible. Do you have any thoughts about how we can best accomplish this? Mike The various authentication methods should be tested against servlets in the Test-Webapp. As to proxies, we must implement a couple of tiny local servers running on different ports. Like: TCP 81: Proxy TCP 82: SSL Proxy Those servers should be started and stopped by the test fixtures (setup / teardown). The servers must be configurable as to which authentication method they use. This will also ensure quality of the various authentication methods, as currently their test cases are somewhat minimalistic. I'd love to hack up some code for the server side this week. Odi - 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 24560] - HttpClient loops endlessly while trying to retrieve status line
[EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 14:38 --- Odi, agreed - whitespace is a wrong term. CRLF is better. CRLF or LF is correct ;-) (see RFC2616, section 19.3). Would you then prefer my first version of the patch, or do you have another idea how to handle this? Sorry I did not look at the patch. I just outlined my idea of how it should be in my opinion. Odi Ps. Please use the list for discussion and only post decisions to Bugzilla. Short lists of bug notes are read quicker when fixing bugs. - 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
Eric Johnson wrote: My take is slightly different (and I wish I had time to implement it) Start by virtualizing the access to the connection, and then, rather than having multiple servers, just have different implementations of a virtualized socket interface, for example. Eric, we can easily implement that by writing a special connection manager or socket factory. No need to introduce addition abstraction here. Socket is already a nice interface :-) 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. You can see
http://developer.java.sun.com/developer/bugParade/bugs/4255743.html and
http://developer.java.sun.com/developer/bugParade/bugs/4206909.html .
In LimeWire we worked around this by using a workaround listed on those
pages: having a class 'CompressingOutputStream' that extends
DeflaterOutputStream, using the following as the flush method:
private static final byte [] EMPTYBYTEARRAY = new byte [0];
/**
* Ensure all remaining data will be output.
*/
public void flush() throws IOException {
if( def.finished() ) return;
/**
* Now this is tricky: We force the Deflater to flush
* its data by switching compression level.
* As yet, a perplexingly simple workaround for
*
http://developer.java.sun.com/developer/bugParade/bugs/4255743.html
*/
def.setInput(EMPTYBYTEARRAY, 0, 0);
def.setLevel(Deflater.NO_COMPRESSION);
deflate();
def.setLevel(Deflater.DEFAULT_COMPRESSION);
deflate();
super.flush();
}
The other thing you have to be careful of when using
DeflaterOutputStream or InflaterInputStream is spurious
NullPointerExceptions from native code if the connection happens to
close while a deflate/inflate is being performed. We worked around that
particular problem by extending the 'read' of the InflaterInputStream
and the 'deflate' call of the DeflaterOutputStream to catch an NPE and
rethrow an IOX.
Thanks,
Sam
otisg wrote:
I'm not too familiar with HttpClient source code any more, but
it seems to me that this should be easy to add. Please correct
me if I am wrong.
I will be using HttpClient to pull large amounts of data from
the web in a few months, and allowing compressed content may
translate to less bandwidth and a lower hosting bill :)
Otis
Get your own 800 number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag
On Mon, 17 Nov 2003, =?ISO-8859-15?Q?Sven_K=F6hler?=
([EMAIL PROTECTED]) wrote:
Hi,
If i send the right accept-encoding headers, the web-server
may answer
with a gzip or deflate compressed stream. Does HttpClient
decompress it?
If yes, how can i turn that off?
-
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]
Re: Keeping Connections Alive
Hi Mike, Using a listener seems like an interesting idea, although I don't quite see the rationale behind it. MTCM (well, CM's in general really) seem to be designed specifiically for this purpose: to manage http connections. Having an observable interface to HttpConnection would require adding new methods that notify HttpConnection when it is assigned/active, as currently the 'releaseConnection' method basically delegates the call to the HttpConnectionManager that is managing it, leaving HttpConnection as stateless as possible. Perhaps the HttpConnectionManager can actually have the task of informing the observers of the HttpConnection about its status -- that would remove any need to add extraneous methods and state to HttpConnection (other than a way of setting/getting listeners). Of course, it might actually be a good idea to add this state information to HttpConnection for other reasons (that I can't think of at the moment). Thanks, Sam Michael Becke wrote: Hi Sam, I think this is definitely something that could be a useful addition to HttpClient. Though it would be possible to add this functionality to the MultiThreadedHttpConnectionManager (MTCM) I think I would like to keep it separate. Partially because I think MTCM is getting a little to complicated, but also because I think it could be used outside of the MTCM. In general I think we want a pluggable method for tracking the lifecycle of a connection. Something like a HttpConnection listener that is informed when a connection is created, assigned, released, etc. This listener could then handle closing the connections after some period of idleness. Any suggestions or contributions that you may have will be appreciated. Thanks, Mike On Nov 14, 2003, at 12:58 PM, Sam Berlin wrote: Thanks for the reply, Mike. Is there any interest in a feature that would close connections that have been unused for a certain amount of time? I imagine the easiest way to implement this would be to just add some settable parameters (set/getCloseConnectionTime) to MultiThreadedHttpConnectionManager along with another Thread that will occasionally iterate through the list of 'freeConnections' in the 'connectionPool', checking an amount of time has lapsed since the connection was last marked as free. HttpConnection (or HttpConnectionAdapater, since this feature would only be in MultiThreadedHttpConnectionManager) could have a new value added to it that stores the most recent time it was released. Note that this would all rely on the user correctly calling 'releaseConnection', but that's essentially a requirement already anyway. If people are interested in such a feature, I would be more than willing to write up such a patch (as I will probably be doing it for the version LimeWire uses anyway). Thanks, Sam Michael Becke wrote: Hi Sam, HttpClient does not do any active connection reclaiming, except when the resources are reused. In the case of the SimpleHttpConnectionManager the connection is never closed/reopened unless it is required for a new method execution. The case for MultiThreadedHttpConnectionManager is similar though a little more complicated. It keeps a pool of connections with a per-host and total connection limit. Again these connections are never closed until a request for a new connection warrants it. Mike On Nov 13, 2003, at 4:10 PM, Sam Berlin wrote: Hi All, I'd like to clarify a point about HttpClient that I do not fully understand. How/when does the actual connection to a server close? I understand that MultiThreadedHttpConnectionManager (and possibly SimpleConnectionManager as well) will keep the connection alive and reuse it for subsequent HTTP requests. Is there a way to set a limit on how long the connection should be kept alive before waiting for a subsequent request to reuse that connection? Thanks, Sam - 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
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. Oleg On Mon, 2003-11-17 at 15:00, [EMAIL PROTECTED] wrote: 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=24560. 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=24560 HttpClient loops endlessly while trying to retrieve status line --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 14:00 --- Oleg, thank you for reviewing my patch. I think the reviewed version is OK in general (AFAICS from the diff - I haven't applied it yet). Just a few comments (new ideas?) by me: In my opinion, strict mode should be very pedantic about standards compliance. HttpClient should notify the user wherever a problematic, non-standards situation is detected. Of course, trailing whitespace should be silently ignored, but any other characters should be regarded as unexpected (is there a section in RFC 2616 for that? I haven't found it yet). The question is: Is (non-whitespace) garbage following the response (caused by a wrong Content-Length header, for example) unexpected enough? In your version of the patch, there is no chance to get informed about such a situation - and in 'lenient' mode, the detection is disabled completely (did you check the TestBadContentLength testcase? does it pass?). Regarding the ProtocolException/ResponseConsumedWatcher thing, of course, it _is_ a workaround to get that Exception thrown to the caller. However, I would appreciate it if the user _would_ receive that Exception (somehow). I even think it is not such a bad idea to keep that in responseConsumed(), just to inform every HttpClient component that there was an error while reading the response (the interface is not public, anyway). Instead of throwing an Exception, we could also have a boolean without/with errors return value, of course... In short, I would prefer the following behaviour: - For any mode: If garbage is detected, read (up to a certain limit of bytes N) until end of garbage (maximum of N bytes) or until a non-whitespace character is received; N is something 10 (should be user-definable). - For any mode, close the connection (the conncetion is definitely unreliable). - For strict mode, throw a ProtocolException if anything else but whitespace has been received. - (Optionally) introduce an extra pedantic mode (inherits strict mode) and throw a ProtocolException even if N bytes of _whitespace_ garbage have been received. Best regards, 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 24560] - HttpClient loops endlessly while trying to retrieve status line
Christian, see my comments in-line In my opinion, strict mode should be very pedantic about standards compliance. HttpClient should notify the user wherever a problematic, non-standards situation is detected. I do not mind being over-pedantic, but not at the expense of code quality. My personal impression was that throwing a protocol exception from responseConsumed required too much of an ugly plumbing. I believe that a big fat log warning should be enough. A protocol exception thrown from responseConsumed would not make HttpClient more reliable (dirty connection would be dropped, anyway), it would just make it, well, more pedantic. That is it. Of course, trailing whitespace should be silently ignored, but any other characters should be regarded as unexpected (is there a section in RFC 2616 for that? I haven't found it yet). This is what RFC has to say: quote In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF. /quote http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.1 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. Folks, any strong options on this issue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24671] - Basic Authentification fails with non-ASCII username/password characters
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=24671. 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=24671 Basic Authentification fails with non-ASCII username/password characters [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-11-17 21:38 --- Mike, I set up Apache http server 2.0.48 on Win2K (Prof), enabled digest authentication for a directory, and created an user account with a password containing German umlauts. I hit the URL with Mozilla Firebird 0.7 and attempted to authenticate using the password. It did not work. I may know why. If the RFC 2617 is to be strictly adhered to, only ASCII characters in passwords should be allowed for basic digest authentication RFC 2617, Section 2: Basic Authentication Scheme quote basic-credentials = base64-user-pass base64-user-pass = base64 [4] encoding of user-pass, except not limited to 76 char/line user-pass = userid : password userid = *TEXT excluding : password= *TEXT /quote RFC 822 defines TEXT as quote text= any CHAR, including bare; = atoms, specials, CR bare LF, but NOT ; comments and including CRLF ; quoted-strings are ; NOT recognized. /quote RFC 822 defines TEXT as quote ; ( Octal, Decimal.) CHAR= any ASCII character; ( 0-177, 0.-127.) /quote However, I do think that in this instance the spec is too restrictive and we should be using ISO-8859-1 instead of ASCII. So, I reopen the bug. Sorry for having closed it prematurely - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24671] - Basic Authentification fails with non-ASCII username/password characters
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=24671. 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=24671 Basic Authentification fails with non-ASCII username/password characters --- Additional Comments From [EMAIL PROTECTED] 2003-11-18 00:19 --- Oleg, No worries about closing the bug. I was a little slow in getting to it. I agree. I think we should be using 8859-1 instead of ASCII. The following section from RFC 2616 seems to imply that TEXT should be 8859-1, though it is a little vague: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047draft [14]. TEXT := any OCTET except CTLs, but including LWS Either way I think digest needs to be fixed. I will create a patch. Mike - 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
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 On Nov 17, 2003, at 9:50 AM, Ortwin Glück wrote: Eric Johnson wrote: My take is slightly different (and I wish I had time to implement it) Start by virtualizing the access to the connection, and then, rather than having multiple servers, just have different implementations of a virtualized socket interface, for example. Eric, we can easily implement that by writing a special connection manager or socket factory. No need to introduce addition abstraction here. Socket is already a nice interface :-) Odi - 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 24560] - HttpClient loops endlessly while trying to retrieve status line
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. Folks, any strong options on this issue I would prefer a warning to an exception. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping Connections Alive
Hi Sam, My thought, probably not well articulated, was to add the ability to observe and interact with the status of HttpConnections. This would allow for classes other that the connection managers to play a hand in the connection management. Another possibility would be to have a HttpConnectionFactory that is responsible for creating connections and is also notified by the connection manager of connection state changes. In general I would like to add plugin support to the connection management process. I think composition of functionality using the connection managers and various plugins will allow for greater flexibility. Mike On Nov 17, 2003, at 1:26 PM, Sam Berlin wrote: Hi Mike, Using a listener seems like an interesting idea, although I don't quite see the rationale behind it. MTCM (well, CM's in general really) seem to be designed specifiically for this purpose: to manage http connections. Having an observable interface to HttpConnection would require adding new methods that notify HttpConnection when it is assigned/active, as currently the 'releaseConnection' method basically delegates the call to the HttpConnectionManager that is managing it, leaving HttpConnection as stateless as possible. Perhaps the HttpConnectionManager can actually have the task of informing the observers of the HttpConnection about its status -- that would remove any need to add extraneous methods and state to HttpConnection (other than a way of setting/getting listeners). Of course, it might actually be a good idea to add this state information to HttpConnection for other reasons (that I can't think of at the moment). Thanks, Sam Michael Becke wrote: Hi Sam, I think this is definitely something that could be a useful addition to HttpClient. Though it would be possible to add this functionality to the MultiThreadedHttpConnectionManager (MTCM) I think I would like to keep it separate. Partially because I think MTCM is getting a little to complicated, but also because I think it could be used outside of the MTCM. In general I think we want a pluggable method for tracking the lifecycle of a connection. Something like a HttpConnection listener that is informed when a connection is created, assigned, released, etc. This listener could then handle closing the connections after some period of idleness. Any suggestions or contributions that you may have will be appreciated. Thanks, Mike On Nov 14, 2003, at 12:58 PM, Sam Berlin wrote: Thanks for the reply, Mike. Is there any interest in a feature that would close connections that have been unused for a certain amount of time? I imagine the easiest way to implement this would be to just add some settable parameters (set/getCloseConnectionTime) to MultiThreadedHttpConnectionManager along with another Thread that will occasionally iterate through the list of 'freeConnections' in the 'connectionPool', checking an amount of time has lapsed since the connection was last marked as free. HttpConnection (or HttpConnectionAdapater, since this feature would only be in MultiThreadedHttpConnectionManager) could have a new value added to it that stores the most recent time it was released. Note that this would all rely on the user correctly calling 'releaseConnection', but that's essentially a requirement already anyway. If people are interested in such a feature, I would be more than willing to write up such a patch (as I will probably be doing it for the version LimeWire uses anyway). Thanks, Sam Michael Becke wrote: Hi Sam, HttpClient does not do any active connection reclaiming, except when the resources are reused. In the case of the SimpleHttpConnectionManager the connection is never closed/reopened unless it is required for a new method execution. The case for MultiThreadedHttpConnectionManager is similar though a little more complicated. It keeps a pool of connections with a per-host and total connection limit. Again these connections are never closed until a request for a new connection warrants it. Mike On Nov 13, 2003, at 4:10 PM, Sam Berlin wrote: Hi All, I'd like to clarify a point about HttpClient that I do not fully understand. How/when does the actual connection to a server close? I understand that MultiThreadedHttpConnectionManager (and possibly SimpleConnectionManager as well) will keep the connection alive and reuse it for subsequent HTTP requests. Is there a way to set a limit on how long the connection should be kept alive before waiting for a subsequent request to reuse that connection? Thanks, Sam - 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]
