RE: [lang] Array concat?
I've been trying to resist commenting (since I've not contributed anything
here) but I agree with Janek; an Array's join method has a different meaning
in other languages (ECMAScript, VBScript, and others). IMHO following the
expectations users have who know the other languages helps the usability of
the library.
e.g.
Object[] anArray = {one, two, three};
ArrayUtil.join(anArray, , );
outputs one, two, three
This would also compliment java.lang.String.split(regex);
Some other suggestions for the join name:
merge(Object[], Object[]) //Rename of join()
mergeNoDuplicates(Object[], Object[]) //Merges and eliminates duplicates
append(Object[], Object[]) //Convenience method calls merge a, b
append(Object[], Object) //Convenience method calls add
prepend(Object[], Object[]) //Convenience method calls merge b, a
prepend(Object[], Object) //Convenience method calls add using pos 0
join(Object[], String) //
http://www.devguru.com/Technologies/ecmascript/quickref/join.html
Instead of just throwing up ideas I decided to create these and so attached
are patches. The convenience methods aren't that important. It would be nice
to see the merge, mergeNoDuplicates, and join make it?
p.s. I didn't create test-cases at least for the time being. Let's see what
others think first. Hope the attachments make it, if not I can do
Bugzilla/Jira
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 8:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] Array concat?
Hello,
I've committed to HEAD three new ArrayUtils methods and unit tests:
add(Object[], Object)
add(Object[], int, Object)
join(Object[], Object[])
Please comment on method names or impl.
Thank you to Maarten for the patch the add methods are based on.
Ticket is: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26056
Gary
-Original Message-
From: Janek Bogucki [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 14:27
To: Jakarta Commons Developers List
Subject: RE: [lang] Array concat?
On Thu, 2004-01-29 at 12:05, Gary Gregory wrote:
Ah, I do recall join now, much better.
Thanks,
Gary
concat is the best choice because join implies the introduction of a
delimiter between the two arrays which is not the outcome, while append
implies the extension of an existing object somehow and arrays don't get
extended. To me, concat does hint at the production of a new object.
-Janek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: ArrayUtils.java
===
RCS file:
/home/cvspublic/jakarta-commons/lang/src/java/org/apache/commons/lang/ArrayUtils.java,v
retrieving revision 1.37
diff -u -r1.37 ArrayUtils.java
--- ArrayUtils.java 30 Jan 2004 02:12:22 - 1.37
+++ ArrayUtils.java 30 Jan 2004 06:58:20 -
@@ -1279,36 +1279,36 @@
}
/**
- * pJoins the elements of the provided arrays into a single new array./p
+ * pMerges the elements of the provided arrays into a single new array./p
* pThe new array contains all of the element of the first array followed
* by all of the elements from the second array./p
*
* pre
- * ArrayUtils.join(null, null) = null
- * ArrayUtils.join(array1, null) = array1
- * ArrayUtils.join(null, array2) = array2
- * ArrayUtils.join([], []) = []
- * ArrayUtils.join([null], [null]) = [null, null]
- * ArrayUtils.join([a, b, c], [1, 2, 3]) = [a, b, c, 1, 2,
3]
+ * ArrayUtils.merge(null, null) = null
+ * ArrayUtils.merge(array1, null) = array1
+ * ArrayUtils.merge(null, array2) = array2
+ * ArrayUtils.merge([], []) = []
+ * ArrayUtils.merge([null], [null]) = [null, null]
+ * ArrayUtils.merge([a, b, c], [1, 2, 3]) = [a, b, c, 1, 2,
3]
* /pre
*
- * @param array1 the first array of values to join together, may be null
- * @param array2 the second array of values to join together, may be null
- * @return The new joined array, codenull/code if null array inputs.
- * The type of the joined array is the type of the first array.
+ * @param array1 the first array of values to merge together, may be null
+ * @param array2 the second array of values to merge together, may be null
+ * @return The new merged array, codenull/code if null array inputs.
+ * The type of the merged array is the type of the first array.
* @since 2.1
*/
-public static Object[] join(Object[] array1, Object[] array2) {
+public static Object[] merge(Object[] array1, Object[] array2) {
if (array1 == null) {
return array2;
} else if (array2 == null) {
return array1;
} else {
-Object[]
Re: [release managers] Rsync with Apache's Maven repository
On 30-Jan-04, at 06:20 Uhr, __matthewHawthorne wrote: Mark R. Diggory wrote: A.) Version Releases /www/www.apache.org/dist/java-repository b.) Daily Builds /www/cvs.apache.org/builds/java-repository c.) Archives /www/archives.apache.org/dist I think I like this idea. The abundance of snapshots has led to a pollution of ibiblio, and a maintenance headache. If someone wants to depend on an Apache snapshot, they can just edit their build.properties or project.properties to point to the daily builds server. Well... no, that means you would depend on daily build for all of Apache projects which definitely not the intent. Is it really a problem to have one project-name-SNAPSHOT.jar ? (and no dated things)? paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-105) Nested element's setName() called with name of tag
Message:
A new issue has been created in JIRA.
-
View the issue:
http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=JELLY-105
Here is an overview of the issue:
-
Key: JELLY-105
Summary: Nested element's setName() called with name of tag
Type: Bug
Status: Unassigned
Priority: Major
Project: jelly
Components:
taglib.ant
Assignee:
Reporter: Vincent Partington
Created: Fri, 30 Jan 2004 2:01 AM
Updated: Fri, 30 Jan 2004 2:01 AM
Description:
I have written an Ant task that can configure a JMeter task for a specific
environment. It is invoked like this from an ant build.xml file:
configurejmeter
basedir=${basedir}/tests
destdir=${current.build.dir}
includes=*.jmx
property file=${environment.properties} /
property name=nr_threads value=${test.nr.threads} /
property name=nr_iterations value=${test.nr.iterations} /
/configurejmeter
The property file=.../ element specifies a file containing properties to be
inserted into the JMeter task, while the property name=.. value=.../ tags
specify specific properties.
However, when I put this fragment in a maven.xml file, it doesn't work. It seems the
setName() of all the objects created for the nested property elements is invoked
with the value property. The first property element won't work because of that
because it doesn't expect setName() to be invoked when setFile() is invoked too.
I've isolated the problem to line 261 in org.apache.commons.jelly.tags.ant.AntTag:
http://jakarta.apache.org/commons/jelly/libs/ant/xref/org/apache/commons/jelly/tags/ant/AntTag.html#260
Why is that line of code there? It seems strange to me, also because the exception is
masked. When I commented out those lines, the problem disappeared.
BTW, I am using Maven 1.0rc1, which includes
commons-jelly-tags-ant-20030625.032346.jar.
-
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/validation NumberValidator.java
roxspring2004/01/30 02:39:11
Modified:cli/src/java/org/apache/commons/cli2/validation Tag:
RESEARCH_CLI_2_ROXSPRING NumberValidator.java
Log:
NumberFormat.getIntegerInstance() doesn't exist in Java 1.3
Revision ChangesPath
No revision
No revision
1.1.2.3 +3 -1
jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/NumberValidator.java
Index: NumberValidator.java
===
RCS file:
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/validation/Attic/NumberValidator.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- NumberValidator.java 22 Jan 2004 22:40:52 - 1.1.2.2
+++ NumberValidator.java 30 Jan 2004 10:39:11 - 1.1.2.3
@@ -71,7 +71,9 @@
}
public static NumberValidator getIntegerInstance() {
-return new NumberValidator(NumberFormat.getIntegerInstance());
+ final NumberFormat format = NumberFormat.getNumberInstance();
+ format.setParseIntegerOnly(true);
+return new NumberValidator(format);
}
public static NumberValidator getPercentInstance() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] unescaping properties
I would consider the exception changes i mentioned last week for 1.0
Back to unescaping, we should also escape characters on saving, it can
be done with this change in BasePropertiesConfiguration:
@@ -428,7 +429,7 @@
{
write(key);
write( = );
-write(value != null ? value : );
+write(value != null ? StringEscapeUtils.escapeJava(value) : );
write('\n');
}
Emmanuel Bourg
Eric Pugh wrote:
Re: [configuration] unescaping propertiesOkay, I'm sold! I guess we can
start simple with PropertiesConfiguration and then add it to others if
usecases come up. Is there anything else you want in 1.0? Otherwise I want
to move to cutting the Release Candatate this weekend.
Eric
-Original Message-
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 2:09 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration] unescaping properties
I noticed this issue because i needed \n to be handled in my .properties
files, that's the only way to have a line return in a property in such a
file. The same is not true for a DatabaseConfiguration for example, the
value field can store unescaped characters. Same thing for
XMLConfiguration, line returns are naturally accepted in the property
values and XML entities can be used for special characters. That's why i
would say it's a problem specific to PropertiesConfiguration and
AbstractConfiguration doesn't need to be modified.
Emmanuel Bourg
Eric Pugh wrote:
[configuration] unescaping propertiesWell, it seems like if it is good
enough for Propertiesconfiguration, then it is good enough for all of
them,
right? Unless this should be decorator? Would you always want to
escape
these characters? What happens if you don't escape them?
Eric
smime.p7s
Description: S/MIME Cryptographic Signature
RE: [lang] Array concat?
Y'know, he might be right about concat *grin shamefacedly* Sorry, Hen On 29 Jan 2004, Janek Bogucki wrote: On Thu, 2004-01-29 at 12:05, Gary Gregory wrote: Ah, I do recall join now, much better. Thanks, Gary concat is the best choice because join implies the introduction of a delimiter between the two arrays which is not the outcome, while append implies the extension of an existing object somehow and arrays don't get extended. To me, concat does hint at the production of a new object. -Janek - 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/xdocs/style - New directory
psteitz 2004/01/30 06:02:49 jakarta-commons/math/xdocs/style - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration BasePropertiesConfiguration.java
epugh 2004/01/30 06:05:01 Modified:configuration/xdocs changes.xml examples.xml overview.xml configuration/src/test/org/apache/commons/configuration TestPropertiesConfiguration.java configuration/conf test.properties configuration/src/java/org/apache/commons/configuration BasePropertiesConfiguration.java Log: Escape and Unescape crlf type characters when working with properties file. Revision ChangesPath 1.6 +4 -0 jakarta-commons/configuration/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/jakarta-commons/configuration/xdocs/changes.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- changes.xml 23 Jan 2004 11:52:36 - 1.5 +++ changes.xml 30 Jan 2004 14:05:00 - 1.6 @@ -7,6 +7,10 @@ body release version=1.0-dev-4 date= + action dev=ebourg type=add + For configuration based on properties files, allow characters like \n etc + to be escaped and unescaped. + /action action dev=epugh type=add ConfigurationFactory now throws ConfigurationLoadException. /action 1.4 +10 -0 jakarta-commons/configuration/xdocs/examples.xml Index: examples.xml === RCS file: /home/cvs/jakarta-commons/configuration/xdocs/examples.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- examples.xml 16 Jan 2004 14:56:45 - 1.3 +++ examples.xml 30 Jan 2004 14:05:00 - 1.4 @@ -33,6 +33,16 @@ Note that this file complies to the typical format of properties files. /p + p + You can also have in a simple properties file various characters + that are typically escaped like \n, \t etc: + /p + source +![CDATA[ +#Unescaped string that will be escaped +test.unescape = This \n string \t contains \ escaped \\ characters +]] + /source /subsection subsection name=The configuration definition file 1.3 +28 -23jakarta-commons/configuration/xdocs/overview.xml Index: overview.xml === RCS file: /home/cvs/jakarta-commons/configuration/xdocs/overview.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- overview.xml 16 Jan 2004 14:56:45 - 1.2 +++ overview.xml 30 Jan 2004 14:05:00 - 1.3 @@ -88,27 +88,27 @@ /subsection /section section name=Configuration Details - p - Configuration is done by taking the configuration XML file and using included Digester rules, - parsing the individual configurations. Make sure to include the various dependencies required for - each type of configuration! If you have an XML file, you'll need dom4j.jar for instance! - /p - subsection name=Classic Properties File + p + Configuration is done by taking the configuration XML file and using included Digester rules, + parsing the individual configurations. Make sure to include the various dependencies required for + each type of configuration! If you have an XML file, you'll need dom4j.jar for instance! + /p + subsection name=Classic Properties File source ![CDATA[ properties className=org.apache.commons.configuration.PropertiesConfiguration fileName=conf/test.properties/ ]] /source p - This configuration file is very simple. You just need to specify the path to the property file. - /p - /subsection - subsection name=XML Properties File + This configuration file is very simple. You just need to specify the path to the property file. + /p + /subsection + subsection name=XML Properties File source ![CDATA[ dom4j className=org.apache.commons.configuration.DOM4JConfiguration fileName=conf/test.xml/ ]] -/source +/source p The configuration is very similar to the classic properties file. However, the xml file must be in a specific format. Currently there is no DTD. @@ -123,7 +123,7 @@ /subelement /element2 test - short8/short +short8/short /test /baseElement ]] @@ -132,35 +132,40 @@ In the above
Re: [release managers] Rsync with Apache's Maven repository
Paul Libbrecht wrote: On 30-Jan-04, at 06:20 Uhr, __matthewHawthorne wrote: Mark R. Diggory wrote: A.) Version Releases /www/www.apache.org/dist/java-repository b.) Daily Builds /www/cvs.apache.org/builds/java-repository c.) Archives /www/archives.apache.org/dist I think I like this idea. The abundance of snapshots has led to a pollution of ibiblio, and a maintenance headache. If someone wants to depend on an Apache snapshot, they can just edit their build.properties or project.properties to point to the daily builds server. Well... no, that means you would depend on daily build for all of Apache projects which definitely not the intent. Is it really a problem to have one project-name-SNAPSHOT.jar ? (and no dated things)? I disagree. If you specified both ibiblio.org/maven and cvs. apache.org/builds/java-repository as your remote repositories in Maven, you could easily depend on a released version or a SNAPSHOT. Maybe I'm misunderstanding you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/xdocs/stylesheets maven.css print.css tigris.css
psteitz 2004/01/30 06:16:10
Modified:math/xdocs navigation.xml
Added: math/xdocs/style maven.css print.css project.css tigris.css
Removed: math/xdocs/stylesheets maven.css print.css tigris.css
Log:
Converted to commons standard lf.
Revision ChangesPath
1.9 +25 -11jakarta-commons/math/xdocs/navigation.xml
Index: navigation.xml
===
RCS file: /home/cvs/jakarta-commons/math/xdocs/navigation.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- navigation.xml11 Jan 2004 19:34:31 - 1.8
+++ navigation.xml30 Jan 2004 14:16:10 - 1.9
@@ -1,11 +1,22 @@
-?xml version=1.0 encoding=ISO-8859-1?
-!-- $Revision$ $Date$ --
-project name=Math
-
- titleMath/title
- organizationLogo href=/images/jakarta-logo-blue.gifJakarta/organizationLogo
-
- body
+?xml version=1.0 encoding=ISO-8859-1?
+
+!DOCTYPE project [
+!ENTITY commons-nav SYSTEM ../../incl_nav.xml
+]
+
+project name=Math
+
+ titleMath/title
+ organizationLogo href=/images/jakarta-logo-blue.gif
+ Jakarta
+ /organizationLogo
+
+ body
+links
+ item name=Jakarta Commons
+href=http://jakarta.apache.org/commons//
+/links
+
menu name=Math
item name=Overviewhref=/index.html/
item name=Proposalhref=/proposal.html/
@@ -21,6 +32,9 @@
item name=Numerical Analysis href=/userguide/analysis.html/
item name=Special Functions href=/userguide/special.html/
item name=Utilities href=/userguide/utilities.html/
-/menu
- /body
-/project
+/menu
+
+commons-nav;
+
+ /body
+/project
1.1 jakarta-commons/math/xdocs/style/maven.css
Index: maven.css
===
body {
background: #fff;
color: #000;
}
.app h3 {
color: #fff;
background-color: #036;
}
.app h4 {
color: #fff;
background-color: #888;
}
.a td {
background: #ddd;
color: #000;
}
.b td {
background: #efefef;
color: #000;
}
.app th {
background-color: #bbb;
color: #fff;
}
div#banner {
border-top: 1px solid #369;
border-bottom: 1px solid #003;
}
#banner, #banner td {
background: #036;
color: #fff;
}
#leftcol {
background: #eee;
color: #000;
border-right: 1px solid #aaa;
border-bottom: 1px solid #aaa;
border-top: 1px solid #fff;
}
#navcolumn {
background: #eee;
color: #000;
border-right: none;
border-bottom: none;
border-top: none;
}
#breadcrumbs {
background-color: #ddd;
color: #000;
border-top: 1px solid #fff;
border-bottom: 1px solid #aaa;
}
#source {
background-color: #fff;
color: #000;
border-right: 1px solid #888;
border-left: 1px solid #888;
border-top: 1px solid #888;
border-bottom: 1px solid #888;
margin-right: 7px;
margin-left: 7px;
margin-top: 1em;
}
#source pre {
margin-right: 7px;
margin-left: 7px;
}
a[name]:hover, #leftcol a[name]:hover {
color: inherit !important;
}
a:link, #breadcrumbs a:visited, #navcolumn a:visited, .app a:visited, .tasknav
a:visited {
color: blue;
}
a:active, a:hover, #leftcol a:active, #leftcol a:hover {
color: #f30 !important;
}
a:link.selfref, a:visited.selfref {
color: #555 !important;
}
h3, h4 {
margin-top: 1em;
margin-bottom: 0;
}
img.handle {
border: 0;
padding-right: 2px;
}
#navcolumn div div {
background-image: none;
background-repeat: no-repeat;
}
#navcolumn div div {
padding-left: 10px;
}
1.1 jakarta-commons/math/xdocs/style/print.css
Index: print.css
===
#banner, #footer, #leftcol, #breadcrumbs, .docs #toc, .docs .courtesylinks{
display: none;
}
body.docs div.docs{
margin: 0 !important;
border: none !important
}
1.1 jakarta-commons/math/xdocs/style/project.css
Index: project.css
===
#banner, #banner td {
background: #fff;
color: #000;
}
#banner td {
height: 100%;
vertical-align: middle;
}
1.1 jakarta-commons/math/xdocs/style/tigris.css
Index: tigris.css
===
/* $Id: tigris.css,v 1.1 2004/01/30 14:16:10 psteitz Exp $
This file defines basic default formatting for HTML conforming to Tigris
application style. To extend or override these rules for your instance, edit
Re: [release managers] Rsync with Apache's Maven repository
At 10:38 PM -0500 1/29/04, Mark R. Diggory wrote: Because only /www/www.apache.org/dist/java-repository is mirrored to ibiblio, only versioned releases get exposed through the default maven repository settings. Apache developers who wish to be testing against the bleeding edge only need to add this repository location to their maven configuration maven.repo.remote = http://cvs.apache.org/builds/java-repository/,http://www.ibiblio.org/maven/ Would it be better to use the reverse order, so that cvs.apache.org is only bothered when the requested JAR isn't on iBiblio? maven.repo.remote =http://www.ibiblio.org/maven/, http://cvs.apache.org/builds/java-repository/ Thanks for your work on this -- it will be really nice to have a smooth and direct channel to get releases onto iBiblio. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math project.properties project.xml
psteitz 2004/01/30 06:19:26
Modified:math project.properties project.xml
Log:
Converted to commons standard lf.
Revision ChangesPath
1.13 +1 -0 jakarta-commons/math/project.properties
Index: project.properties
===
RCS file: /home/cvs/jakarta-commons/math/project.properties,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- project.properties29 Jan 2004 18:24:02 - 1.12
+++ project.properties30 Jan 2004 14:19:26 - 1.13
@@ -4,6 +4,7 @@
maven.checkstyle.properties=${basedir}/checkstyle.xml
maven.test.failure = false
+maven.xdoc.poweredby.image=maven-feather.png
#If you wish to skip tests when doing builds, uncomment
#maven.test.skip = true
1.38 +11 -2 jakarta-commons/math/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/math/project.xml,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- project.xml 28 Jan 2004 21:05:55 - 1.37
+++ project.xml 30 Jan 2004 14:19:26 - 1.38
@@ -1,10 +1,19 @@
?xml version=1.0 encoding=UTF-8?
!-- $Revision$ $Date$ --
project
- extend../../jakarta-commons/project.xml/extend
+ extend../project.xml/extend
+
+
nameMath/name
idcommons-math/id
currentVersion0.1-dev/currentVersion
+
+ organization
+nameApache Software Foundation/name
+urlhttp://www.apache.org/url
+logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo
+ /organization
+
inceptionYear2003/inceptionYear
logo/images/math.gif/logo
shortDescription
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jelly] Ant's parallel task works differently when invoked via Jelly
When I invoke the following via Ant: parallel sequential echoThread one sleeping for three seconds/echo sleep seconds=3/ echoThread one done sleeping/echo /sequential sequential echoThread two sleeping for one second/echo sleep seconds=1/ echoThread two done sleeping/echo /sequential /parallel echoAll threads complete/echo I get the output I expect: anttest: [echo] Thread one sleeping for three seconds [echo] Thread two sleeping for one second [echo] Thread two done sleeping [echo] Thread one done sleeping [echo] All threads complete but when I invoke the same in a maven.xml goal, I get: anttest: [echo] Thread one sleeping for three seconds [echo] Thread one done sleeping [echo] Thread two sleeping for one second [echo] Thread two done sleeping [echo] All threads complete Where the two groups run sequentially, instead of in parallel. In case you're wondering if maybe the output is just being buffered differently, in my real code I exec a message-feeder within the sequential tags that takes 30-40 minutes to run, so the sequential nature is much more obvious. I just used the sleep and echos to demonstrate what I'm seeing. I didn't see anything about this in Jira. Is it a known problem, or is there something else I need to get this to work? Thanks. BTW, I'm using Maven built from CVS on 11/25/03, which uses commons-jelly-tags-ant-20030625.032346.jar. Jeff -- mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [release managers] Rsync with Apache's Maven repository
Yes, order of these would be up to the developers. But, ordering of these does not necessarily dictate with file is used in the case of snapshot, I believe in such a case the snapshots are compared in the two repositories for underlying version backing them, the newest of the two versions is used. What this means as well is that when your developing/testing and using the nightly build repository, your snapshots will resole to the bleeding edge, when you actually cut a release, you would remove the nightly build repository from your configuration and just use ibiblio, the snapshot would resolve to the newest versioned release stored on ibiblio. -Mark Joe Germuska wrote: At 10:38 PM -0500 1/29/04, Mark R. Diggory wrote: Because only /www/www.apache.org/dist/java-repository is mirrored to ibiblio, only versioned releases get exposed through the default maven repository settings. Apache developers who wish to be testing against the bleeding edge only need to add this repository location to their maven configuration maven.repo.remote = http://cvs.apache.org/builds/java-repository/,http://www.ibiblio.org/maven/ Would it be better to use the reverse order, so that cvs.apache.org is only bothered when the requested JAR isn't on iBiblio? maven.repo.remote =http://www.ibiblio.org/maven/, http://cvs.apache.org/builds/java-repository/ Thanks for your work on this -- it will be really nice to have a smooth and direct channel to get releases onto iBiblio. Joe -- 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]
cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration ConfigurationException.java HierarchicalDOM4JConfiguration.java PropertiesConfiguration.java DOM4JConfiguration.java BasePropertiesConfiguration.java ConfigurationFactory.java ClassPropertiesConfiguration.java
epugh 2004/01/30 06:46:37
Modified:configuration/src/test/org/apache/commons/configuration
TestConfigurationFactory.java
configuration/src/java/org/apache/commons/configuration
HierarchicalDOM4JConfiguration.java
PropertiesConfiguration.java
DOM4JConfiguration.java
BasePropertiesConfiguration.java
ConfigurationFactory.java
ClassPropertiesConfiguration.java
Added: configuration/src/java/org/apache/commons/configuration
ConfigurationException.java
Removed: configuration/src/java/org/apache/commons/configuration/exception
ConfigurationLoadException.java
Log:
Throw ConfigurationException instead of Exception or IOException on public methods
Revision ChangesPath
1.5 +2 -3
jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationFactory.java
Index: TestConfigurationFactory.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/test/org/apache/commons/configuration/TestConfigurationFactory.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestConfigurationFactory.java 23 Jan 2004 11:52:36 - 1.4
+++ TestConfigurationFactory.java 30 Jan 2004 14:46:37 - 1.5
@@ -59,7 +59,6 @@
import junit.framework.TestCase;
-import org.apache.commons.configuration.exception.ConfigurationLoadException;
import org.xml.sax.SAXParseException;
/**
@@ -187,7 +186,7 @@
Configuration c = configurationFactory.getConfiguration();
fail(Should have throw an Exception);
}
- catch (ConfigurationLoadException cle){
+ catch (ConfigurationException cle){
assertTrue(cle.getCause() instanceof SAXParseException);
}
}
1.2 +17 -5
jakarta-commons/configuration/src/java/org/apache/commons/configuration/HierarchicalDOM4JConfiguration.java
Index: HierarchicalDOM4JConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/HierarchicalDOM4JConfiguration.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HierarchicalDOM4JConfiguration.java 23 Dec 2003 15:09:05 - 1.1
+++ HierarchicalDOM4JConfiguration.java 30 Jan 2004 14:46:37 - 1.2
@@ -54,11 +54,13 @@
* http://www.apache.org/.
*/
+import java.net.MalformedURLException;
import java.net.URL;
import java.util.Iterator;
import org.dom4j.Attribute;
import org.dom4j.Document;
+import org.dom4j.DocumentException;
import org.dom4j.Element;
import org.dom4j.io.SAXReader;
@@ -142,9 +144,14 @@
* been specified before.
* @throws Exception if an error occurs
*/
-public void load() throws Exception
+public void load() throws ConfigurationException
{
-load(ConfigurationUtils.getURL(getBasePath(), getFileName()));
+ try {
+ load(ConfigurationUtils.getURL(getBasePath(), getFileName()));
+ }
+ catch (MalformedURLException mue){
+ throw new ConfigurationException(Could not load from +
getBasePath() + , + getFileName());
+ }
}
/**
@@ -152,9 +159,14 @@
* @param url the URL to the XML document
* @throws Exception if an error occurs
*/
-public void load(URL url) throws Exception
+public void load(URL url) throws ConfigurationException
{
-initProperties(new SAXReader().read(url));
+ try {
+ initProperties(new SAXReader().read(url));
+ }
+ catch (DocumentException de){
+ throw new ConfigurationException(Could not load from + url);
+ }
}
/**
1.2 +14 -9
jakarta-commons/configuration/src/java/org/apache/commons/configuration/PropertiesConfiguration.java
Index: PropertiesConfiguration.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/commons/configuration/PropertiesConfiguration.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PropertiesConfiguration.java 23 Dec 2003 15:09:05 - 1.1
+++ PropertiesConfiguration.java 30 Jan 2004 14:46:37 - 1.2
@@ -127,7 +127,7 @@
* @param defaults Configuration defaults to use if key not in file
* @throws IOException Error while loading the properties file
*/
-public PropertiesConfiguration(Configuration defaults)
Re: [release managers] Rsync with Apache's Maven repository
__matthewHawthorne wrote: Paul Libbrecht wrote: On 30-Jan-04, at 06:20 Uhr, __matthewHawthorne wrote: Mark R. Diggory wrote: A.) Version Releases /www/www.apache.org/dist/java-repository b.) Daily Builds /www/cvs.apache.org/builds/java-repository c.) Archives /www/archives.apache.org/dist I think I like this idea. The abundance of snapshots has led to a pollution of ibiblio, and a maintenance headache. If someone wants to depend on an Apache snapshot, they can just edit their build.properties or project.properties to point to the daily builds server. Well... no, that means you would depend on daily build for all of Apache projects which definitely not the intent. Is it really a problem to have one project-name-SNAPSHOT.jar ? (and no dated things)? I disagree. If you specified both ibiblio.org/maven and cvs. apache.org/builds/java-repository as your remote repositories in Maven, you could easily depend on a released version or a SNAPSHOT. Maybe I'm misunderstanding you. Right, if your cofiguring your project dependencies to be snapshot, you will be developing against the latest daily build. If you resolve your dependencies to a verison then your still always going to get that version, no matter whats in the daily build repository and where it points. The important thing to note, and I mentioned this in my last email is that when you allow Maven to do this resolution using the goal resolve-snapshots, you would get different results with the daily build repository in your config, so, when cutting a release, it would be wise to remove the daily build repository from your configuration temporarily. Of course, this is all hypothetical, there is no daily build repository on cvs.apache.org yet. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/configuration/xdocs changes.xml
epugh 2004/01/30 06:53:11 Modified:configuration/xdocs changes.xml Log: Update changes Revision ChangesPath 1.7 +5 -4 jakarta-commons/configuration/xdocs/changes.xml Index: changes.xml === RCS file: /home/cvs/jakarta-commons/configuration/xdocs/changes.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- changes.xml 30 Jan 2004 14:05:00 - 1.6 +++ changes.xml 30 Jan 2004 14:53:11 - 1.7 @@ -7,13 +7,14 @@ body release version=1.0-dev-4 date= + action dev=epugh type=add + ConfigurationException is now thrown by public methods instead of Exception or + IOException or whatnot. + /action action dev=ebourg type=add For configuration based on properties files, allow characters like \n etc to be escaped and unescaped. - /action - action dev=epugh type=add - ConfigurationFactory now throws ConfigurationLoadException. - /action + /action action dev=ebourg type=add New DatabaseConfiguration that uses a database to store the properties. It supports 2 table structures : ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Straw man release plan
After reviewing http://jakarta.apache.org/site/versioning.html I agree with Mark that we should be aiming for a 1.0 release of [math]. Here is a straw man plan, with lots of detail missing. 1. Complete the following code / doco tasks a. Finish the User Guide b. Finalize and execute RealMatrix solve() strategy c. Finalize and execute spline changes d. Extend certified data tests with tests against R or other sources (need to finalize what is included here) e. Fix broken links and other errors in javadoc f. Improve path and boundary value test coverage g. Finalize and implement BeanList stats 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) 3. Depending on feedback from B1, proceed either to B2... or RC1... then 1.0 final. Am I missing anything? Are there other things that we think really *must* get into 1.0? Are there things that we should omit? Mark, do you want to play the Release Manager role? If not, I am willing to do it. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] logo
Mark R. Diggory wrote: Phil's planning to update the look and feel of the site, heres a new logo to fit on the white background. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/math/xdocs/images/math.gif?rev=1.2view=markup -Mark I committed the lf changes. I like the [math] thing in the logo, but I don't like the way it overlaps the commons piece. Maybe eliminate the commons thing or make [math] smaller? I should add my usual disclaimer that I have 0 artistic ability, so this may be fine as is ;-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [release managers] Rsync with Apache's Maven repository
Mark R. Diggory wrote: __matthewHawthorne wrote: Paul Libbrecht wrote: Well... no, that means you would depend on daily build for all of Apache projects which definitely not the intent. Is it really a problem to have one project-name-SNAPSHOT.jar ? (and no dated things)? I disagree. If you specified both ibiblio.org/maven and cvs. apache.org/builds/java-repository as your remote repositories in Maven, you could easily depend on a released version or a SNAPSHOT. Maybe I'm misunderstanding you. Right, if your cofiguring your project dependencies to be snapshot, you will be developing against the latest daily build. If you resolve your dependencies to a verison then your still always going to get that version, no matter whats in the daily build repository and where it points. The important thing to note, and I mentioned this in my last email is that when you allow Maven to do this resolution using the goal resolve-snapshots, you would get different results with the daily build repository in your config, so, when cutting a release, it would be wise to remove the daily build repository from your configuration temporarily. Of course, this is all hypothetical, there is no daily build repository on cvs.apache.org yet. -Mark In any case, in my mind one should not be deploying SNAPSHOTs to the release repository anyway, its only for releases. Further, it seems to me to be a dubious practice to cut a release with a SNAPSHOT dependency in project.xml. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[CLI] Refactoring plans
This is just a quick heads up to let you know what I've got planned in the next few days for the cli2 package (on the ROXSPRING branch) it's mostly refactoring and minor stuff before I get back to experimenting with option paths. 1) Refactor CommandLine. This class is getting pretty big and I'm hoping I can rationalise it a little, firstly by extracting readonly and writeable interfaces, and then probably moving some (potential) functionality to decorators. CommandLine interface WriteableCommandLine interface CommandLineImpl implements both of above TypedCommandLine decorates CommandLine (provide typed getValue() varients) DefaultingCommandLine decorates CommandLine (defaults provided by alternative CommandLine or maybe configuration?) 2) Repackage some cli2. Currently there are 33 classes/interfaces in the cli2 package and I'd like to reduce that. I'm not sure which direction I'll end up going but possibilities include the following: o.a.c.cli2.api - the interfaces and OptionException o.a.c.cli2.impl - the implementations and other exceptions o.a.c.cli2.commandline - the refactored CommandLine and friends o.a.c.cli2.help - Help* An alternative would include subpackages based on the argument/group/parent separation but I don't see that getting us anywhere. 3) Reformat some code. There is a slight mix of code formatting involved currently and I'd like to pick one and bring the source in line using either checkstyle and some nagging or jalopy. Currently we appear to have slightly fewer checkstyle errors if we use the sun settings rather than turbine (5290 vs5640) or we could hack at a checkstyle config and come to a custom conclusion. I think I'm leaning towards to sun style but am open to suggestions. If anyone has any thoughts, wisdom, questions or suggestions they're all welcome, Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] logo
Phil Steitz wrote: Mark R. Diggory wrote: Phil's planning to update the look and feel of the site, heres a new logo to fit on the white background. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/math/xdocs/images/math.gif?rev=1.2view=markup -Mark I committed the lf changes. I like the [math] thing in the logo, but I don't like the way it overlaps the commons piece. Maybe eliminate the commons thing or make [math] smaller? I should add my usual disclaimer that I have 0 artistic ability, so this may be fine as is ;-) Phil I was trying to get a little more consistent look with the rest of the projects by adding in the commons. Unfortunately, if I make the [math] part smaller it looses readability. Another idea I have is to make the commons part a shadow. I'll muck with it more over the weekend. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [release managers] Rsync with Apache's Maven repository
Ryan Hoegg wrote: In any case, in my mind one should not be deploying SNAPSHOTs to the release repository anyway, its only for releases. Further, it seems to me to be a dubious practice to cut a release with a SNAPSHOT dependency in project.xml. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net/ What most people don't realize is that there is mechanism for resolving SNAPSHOT to a release version already in Maven which you can use just before you build distributions with it, you can make all your dependencies SNAPSHOT during development, when the release manager cuts the releases, they resolve the dependencies. then when the user get the source build and runs the maven jar command or ant jar command the proper versioned dependencies are gotten. Also, be clear, all SNAPSHOT is in maven is a link to the latest release. This means that in the ibiblio repository you may have: Parent Directory 29-Jan-2004 19:47 - commons-math-1.0.jar 29-Jan-2004 19:47 105k commons-math-1.0.jar.md5 29-Jan-2004 19:47 1k commons-math-SNAPSHOT.jar29-Jan-2004 19:47 105k commons-math-snapshot-version29-Jan-2004 19:47 1k and the snapshot is really just alink to 1.0 then in the daily build repository you may have: Parent Directory 29-Jan-2004 19:47 - commons-math-20040118.003354.jar 29-Jan-2004 19:47 105k commons-math-20040118.003354.jar.md5 29-Jan-2004 19:47 1k commons-math-SNAPSHOT.jar29-Jan-2004 19:47 105k commons-math-snapshot-version29-Jan-2004 19:47 1k and that SNAPSHOT is a link to the daily build version. The important features are daily build vs release, SNAPSHOT is just a resolving mechanism. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JIRA][Bugzilla][HttpClient] should I stay or should I go?
I sent the message below to [EMAIL PROTECTED] and [EMAIL PROTECTED] a week ago following a rather animated discussion on this list about prospects of Jakarta Commons wholesale migration to JIRA. Apparently our infrastructure people have enough on their plates these days, so I can't blame them for being unable to respond. I felt that some of our questions could be answered here. If this is not the appropriate venue to discuss JIRA vs Bugzilla issue, I'd appreciate any pointer as to where I should turn next -- Original message dated Thu 22/01/2004 21:28 Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] referencing properties across files bug/feature?
Hello,
I have a question regarding referencing properties across different
property files. I've tried using both
commons-configuration-20030706.202021.jar and
commons-configuration-20040121.140929.jar. The setup I have is the
following:
config-override.properties
baseURL=http://localhost:9080
config-default.properties
baseURL=http://localhost:80
servletURL=${baseURL}/servlet
propertiesConfiguration.xml
configuration
properties
className=org.apache.commons.configuration.PropertiesConfiguration
fileName=config-override.properties/
properties
className=org.apache.commons.configuration.PropertiesConfiguration
fileName=config-default.properties/
/configuration
When I call configuration.getString(servletURL) I get
http://localhost:80/servlet, but what I want is
http://localhost:9080/servlet.
Is this a bug or a feature? Is there anyway I can achieve the behavior
I'm after?
Thanks very much.
Charles
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] referencing properties across files bug/feature?
Did you read the section here:
http://jakarta.apache.org/commons/configuration/examples.html?
The latest version has been reworked to make overrides simpler to do. Here
is the guts:
configuration
override
properties fileName=usergui.properties/
dom4j fileName=gui.xml/
/override
additional
dom4j
className=org.apache.commons.configuration.HierarchicalDOM4JConfiguration
fileName=tables.xml/
dom4j
className=org.apache.commons.configuration.HierarchicalDOM4JConfiguration
fileName=tasktables.xml at=tables/
/additional
/configuration
Notice the override versus additional?
Also, check out one of the nightly builds from here:
http://cvs.apache.org/builds/jakarta-commons/nightly/commons-configuration/.
Eric
-Original Message-
From: Charles Crouch [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 6:49 PM
To: [EMAIL PROTECTED]
Subject: [configuration] referencing properties across files
bug/feature?
Hello,
I have a question regarding referencing properties across different
property files. I've tried using both
commons-configuration-20030706.202021.jar and
commons-configuration-20040121.140929.jar. The setup I have is the
following:
config-override.properties
baseURL=http://localhost:9080
config-default.properties
baseURL=http://localhost:80
servletURL=${baseURL}/servlet
propertiesConfiguration.xml
configuration
properties
className=org.apache.commons.configuration.PropertiesConfiguration
fileName=config-override.properties/
properties
className=org.apache.commons.configuration.PropertiesConfiguration
fileName=config-default.properties/
/configuration
When I call configuration.getString(servletURL) I get
http://localhost:80/servlet, but what I want is
http://localhost:9080/servlet.
Is this a bug or a feature? Is there anyway I can achieve the
behavior
I'm after?
Thanks very much.
Charles
-
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: [lang] i18n package proposal
This case sounds like a contract violation on the part of the caller, so throwing IllegalArgumentException is entirely reasonable. In fact that's exactly what I advise for all caller-side contract violations. On Thu, 29 Jan 2004 14:17:46 -0500, Inger, Matthew [EMAIL PROTECTED] said: I had also considered throwing an IllegalArgumentException in the case i outlined (where the number of x values does not match the number of ceofficients [excluding of course b0] ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testing email delivery problems
please ignore. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] running math tests on minotaur hangs
Does anyone else encounter a hang when running the tests in maven on minotaur? % maven test [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.125 sec [junit] Running org.apache.commons.math.random.RandomDataTest RandomDataTest just hangs indefinitely, If I build on my workstation's here in my office (Linux, NT) everything seems to work ok. very odd, very odd indeed. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] i18n package proposal
[Sorry, premature message send.]
Mark R. Diggory wrote:
I don't think logging should be used for anything more than debugging
purposes.
J.Pietschmann said:
Me too. I used the code snippet as an example of a typical application
level exception handling.
I don't think a library must bend over backwards to support the poor
programming practices of its users. That kind of poor exception handling
is a well-documented anti-pattern.
In any case, it shouldn't be the exception's responsibility to locate
resource bundles or message formats. Remember that localized log entries
are only possible if the logging system supports it.
How about something like:
interface LocalizedThrowable
{
/** Returns a key for retrieving an appropriate MessageFormat. */
public String getResourceKey();
/** Renders a localized message for this exception. */
public String formatMessage(MessageFormat format);
}
This would provide an appropriate hook for the logging system to lookup
the localized message and format it.
.T.
--
Todd V. Jonker
Conscious Code Ltd
Thoughtful Software Development
www.consciouscode.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] i18n package proposal
Bad name, implies it's a Throwable but it's not. Also you wouldn't want to
make it extend that.
LocalizedMessageSource? and change getResourceKey to getMessageKey ?
Other names: LocalizedMessagable LocalizedThrowableMessagable etc.
[not that I'm agreeing with the interface's need, just suggesting a change
to the proposal]
Hen
On Fri, 30 Jan 2004, Todd V. Jonker wrote:
[Sorry, premature message send.]
Mark R. Diggory wrote:
I don't think logging should be used for anything more than debugging
purposes.
J.Pietschmann said:
Me too. I used the code snippet as an example of a typical application
level exception handling.
I don't think a library must bend over backwards to support the poor
programming practices of its users. That kind of poor exception handling
is a well-documented anti-pattern.
In any case, it shouldn't be the exception's responsibility to locate
resource bundles or message formats. Remember that localized log entries
are only possible if the logging system supports it.
How about something like:
interface LocalizedThrowable
{
/** Returns a key for retrieving an appropriate MessageFormat. */
public String getResourceKey();
/** Renders a localized message for this exception. */
public String formatMessage(MessageFormat format);
}
This would provide an appropriate hook for the logging system to lookup
the localized message and format it.
.T.
--
Todd V. Jonker
Conscious Code Ltd
Thoughtful Software Development
www.consciouscode.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol Protocol.java SSLProtocolSocketFactory.java ProtocolSocketFactory.java DefaultProtocolSocketFactory.java
mbecke 2004/01/30 11:23:15
Modified:httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH TestNoHost.java
httpclient/src/java/org/apache/commons/httpclient/protocol
Tag: HTTPCLIENT_2_0_BRANCH Protocol.java
SSLProtocolSocketFactory.java
ProtocolSocketFactory.java
DefaultProtocolSocketFactory.java
Added: httpclient/src/test/org/apache/commons/httpclient Tag:
HTTPCLIENT_2_0_BRANCH TestEquals.java
Log:
Fixed possible connection leak caused by lack of equals() and hashCode() on protocol
socket factories.
PR: 26139
Submitted by: Michael Becke
Reviewed by: Oleg Kalnichevski and Roland Weber
Revision ChangesPath
No revision
No revision
1.22.2.1 +5 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestNoHost.java
Index: TestNoHost.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestNoHost.java,v
retrieving revision 1.22
retrieving revision 1.22.2.1
diff -u -r1.22 -r1.22.2.1
--- TestNoHost.java 17 Apr 2003 11:34:19 - 1.22
+++ TestNoHost.java 30 Jan 2004 19:23:15 - 1.22.2.1
@@ -104,6 +104,7 @@
suite.addTest(TestRequestLine.suite());
suite.addTest(TestPartsNoHost.suite());
suite.addTest(TestMethodCharEncoding.suite());
+suite.addTest(TestEquals.suite());
return suite;
}
No revision
Index: TestNoHost.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestNoHost.java,v
retrieving revision 1.22
retrieving revision 1.22.2.1
diff -u -r1.22 -r1.22.2.1
--- TestNoHost.java 17 Apr 2003 11:34:19 - 1.22
+++ TestNoHost.java 30 Jan 2004 19:23:15 - 1.22.2.1
@@ -104,6 +104,7 @@
suite.addTest(TestRequestLine.suite());
suite.addTest(TestPartsNoHost.suite());
suite.addTest(TestMethodCharEncoding.suite());
+suite.addTest(TestEquals.suite());
return suite;
}
No revision
Index: TestNoHost.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestNoHost.java,v
retrieving revision 1.22
retrieving revision 1.22.2.1
diff -u -r1.22 -r1.22.2.1
--- TestNoHost.java 17 Apr 2003 11:34:19 - 1.22
+++ TestNoHost.java 30 Jan 2004 19:23:15 - 1.22.2.1
@@ -104,6 +104,7 @@
suite.addTest(TestRequestLine.suite());
suite.addTest(TestPartsNoHost.suite());
suite.addTest(TestMethodCharEncoding.suite());
+suite.addTest(TestEquals.suite());
return suite;
}
1.1.2.1 +4 -4
jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestEquals.java
Index: TestEquals.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestEquals.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- TestEquals.java 27 Jan 2004 22:18:49 - 1.1
+++ TestEquals.java 30 Jan 2004 19:23:15 - 1.1.2.1
@@ -1,13 +1,13 @@
package org.apache.commons.httpclient;
+import junit.framework.Test;
+import junit.framework.TestCase;
+import junit.framework.TestSuite;
+
import org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory;
import org.apache.commons.httpclient.protocol.Protocol;
import org.apache.commons.httpclient.protocol.ProtocolSocketFactory;
import org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory;
-
-import junit.framework.Test;
-import junit.framework.TestCase;
-import junit.framework.TestSuite;
/**
*/
No revision
No revision
1.5.2.1 +5 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol/Protocol.java
Index: Protocol.java
===
RCS file:
/home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/protocol/Protocol.java,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- Protocol.java 31 Jan 2003 00:33:36 - 1.5
+++ Protocol.java 30 Jan 2004 19:23:15 - 1.5.2.1
@@ -165,14 +165,14 @@
if (http.equals(id)) {
final Protocol http
-= new Protocol(http, new
Re: [math] Straw man release plan
Hello everybody, My name is Brent Redeker, and I've had some interest in the Commons Math project since I heard of it about a month ago. I've been meaning to offer any help I can give to the project, and perhaps I can be of some assistance in preparing for a 1.0 release. If the project could use my help, and if somebody could get me started, I'd be glad to do what I can. (Unfortunately, I'll probably need some hand-holding at first, as I am unfamiliar with how Apache contributors work.) I'm actually kind of interested in the Commons Math linear package, as that seems like it needs some work yet. Although I haven't finished my degree yet, I've had a number of mathematics courses, including Linear Algebra and Numerical Analysis, so I'm sure I know enough to be of some use. Brent Redeker On Jan 30, 2004, at 8:58 AM, Phil Steitz wrote: After reviewing http://jakarta.apache.org/site/versioning.html I agree with Mark that we should be aiming for a 1.0 release of [math]. Here is a straw man plan, with lots of detail missing. 1. Complete the following code / doco tasks a. Finish the User Guide b. Finalize and execute RealMatrix solve() strategy c. Finalize and execute spline changes d. Extend certified data tests with tests against R or other sources (need to finalize what is included here) e. Fix broken links and other errors in javadoc f. Improve path and boundary value test coverage g. Finalize and implement BeanList stats 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) 3. Depending on feedback from B1, proceed either to B2... or RC1... then 1.0 final. Am I missing anything? Are there other things that we think really *must* get into 1.0? Are there things that we should omit? Mark, do you want to play the Release Manager role? If not, I am willing to do it. Phil - 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.xml
mdiggory2004/01/30 11:52:08 Modified:math project.xml Log: Fixing email addresses and changing version to 1.0 Revision ChangesPath 1.39 +27 -32jakarta-commons/math/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/math/project.xml,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- project.xml 30 Jan 2004 14:19:26 - 1.38 +++ project.xml 30 Jan 2004 19:52:08 - 1.39 @@ -2,18 +2,14 @@ !-- $Revision$ $Date$ -- project extend../project.xml/extend - - nameMath/name idcommons-math/id - currentVersion0.1-dev/currentVersion - + currentVersion1.0-dev/currentVersion organization nameApache Software Foundation/name urlhttp://www.apache.org/url logohttp://jakarta.apache.org/images/jakarta-logo.gif/logo /organization - inceptionYear2003/inceptionYear logo/images/math.gif/logo shortDescription @@ -25,46 +21,45 @@ siteDirectory/www/jakarta.apache.org/commons/math//siteDirectory versions version - id0.1-dev/id - name0.1-dev/name + id1.0/id + name1.0-dev/name /version /versions - developers - developer - nameAlbert Davidson Chou/name - email[EMAIL PROTECTED]/email -/developer +developer + nameAlbert Davidson Chou/name + emailachou at apache dot org/email +/developer developer nameMark Diggory/name idmdiggory/id - email[EMAIL PROTECTED]/email -/developer + emailmdiggory at apache dot org/email +/developer developer nameRobert Burrell Donkin/name idrdonkin/id - email[EMAIL PROTECTED]/email + emailrdonkin at apache dot org/email /developer developer nameTim O'Brien/name idtobrien/id - email[EMAIL PROTECTED]/email -/developer + emailtobrien at apache dot org/email +/developer developer - nameJ. Pietschmann/name - idpietsch/id - email[EMAIL PROTECTED]/email -/developer -developer - namePhil Steitz/name - idpsteitz/id - email[EMAIL PROTECTED]/email - /developer -developer - nameBrent Worden/name - idbrentworden/id - email[EMAIL PROTECTED]/email -/developer + nameJ. Pietschmann/name + idpietsch/id + emailj3322ptm at yahoo dot de/email +/developer +developer + namePhil Steitz/name + idpsteitz/id + emailpsteitz at apache dot org/email +/developer +developer + nameBrent Worden/name + idbrentworden/id + emailbrentworden at apache dot org/email +/developer /developers contributors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] running math tests on minotaur hangs
--- Mark R. Diggory [EMAIL PROTECTED] wrote: Does anyone else encounter a hang when running the tests in maven on minotaur? % maven test [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.125 sec [junit] Running org.apache.commons.math.random.RandomDataTest RandomDataTest just hangs indefinitely, If I build on my workstation's here in my office (Linux, NT) everything seems to work ok. very odd, very odd indeed. -Mark Any idea what test is hanging? Does it hang when run from Ant? One thing that could theoretically hang / take a long time is nextPoisson(), which I think is tested there, though the probability of it taking even a second should be astronomically small with the actual parameter in the test (assuming things are working correctly). I will add a bound for this in any case. Phil __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math build.xml
mdiggory2004/01/30 11:53:33
Modified:math build.xml
Log:
Fixing version number.
Revision ChangesPath
1.10 +14 -16jakarta-commons/math/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/math/build.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- build.xml 14 Nov 2003 21:46:30 - 1.9
+++ build.xml 30 Jan 2004 19:53:33 - 1.10
@@ -1,9 +1,7 @@
?xml version=1.0 encoding=UTF-8?
-!--
- build.xml generated by maven from project.xml version 0.1-dev
- on date September 27 2003, time 0007
---
+!--build.xml generated by maven from project.xml version 0.1
+ on date January 29 2004, time 1839--
project default=jar name=commons-math basedir=.
property name=defaulttargetdir value=target
@@ -20,7 +18,7 @@
/property
property name=javadocdir value=dist/docs/api
/property
- property name=final.name value=commons-math-0.1-dev
+ property name=final.name value=commons-math-1.0-dev
/property
target name=init description=o Initializes some properties
mkdir dir=${libdir}
@@ -133,11 +131,11 @@
format pattern=2003- property=year
/format
/tstamp
-property name=copyright value=Copyright amp;copy; Apache Software
Foundation. All Rights Reserved.
+property name=copyright value=Copyright amp;copy; 2003-2004 Apache
Software Foundation. All Rights Reserved.
/property
-property name=title value=Math 0.1-dev API
+property name=title value=Math 0.1 API
/property
-javadoc use=true private=true destdir=${javadocdir} author=true
version=true sourcepath=src/java packagenames=org.apache.commons.*.*
+javadoc bottom=Copyright amp;copy; 2003-2004 Apache Software Foundation. All
Rights Reserved. windowtitle=Math 0.1 API use=true private=true
destdir=${javadocdir} author=true doctitle=Math 0.1 API version=true
sourcepath=C:\eclipse\workspace\math\src\java packagenames=org.apache.commons.*.*
classpath
fileset dir=${libdir}
include name=*.jar
@@ -149,21 +147,21 @@
/javadoc
/target
target name=get-deps unless=noget depends=init
-get dest=${libdir}/commons-beanutils-1.5.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.5.jar;
+get dest=${libdir}/commons-beanutils-1.5.jar usetimestamp=true
ignoreerrors=true
src=http://www.apache.org/dist/java-repository/commons-beanutils/jars/commons-beanutils-1.5.jar;
/get
-get dest=${libdir}/commons-collections-SNAPSHOT.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-SNAPSHOT.jar;
+get dest=${libdir}/commons-collections-2.1.jar usetimestamp=true
ignoreerrors=true
src=http://www.apache.org/dist/java-repository/commons-collections/jars/commons-collections-2.1.jar;
/get
-get dest=${libdir}/commons-lang-SNAPSHOT.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-lang/jars/commons-lang-SNAPSHOT.jar;
+get dest=${libdir}/commons-lang-2.0.jar usetimestamp=true
ignoreerrors=true
src=http://www.apache.org/dist/java-repository/commons-lang/jars/commons-lang-2.0.jar;
/get
-get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-logging/jars/commons-logging-1.0.3.jar;
+get dest=${libdir}/commons-logging-1.0.3.jar usetimestamp=true
ignoreerrors=true
src=http://www.apache.org/dist/java-repository/commons-logging/jars/commons-logging-1.0.3.jar;
/get
-get dest=${libdir}/commons-discovery-SNAPSHOT.jar usetimestamp=true
ignoreerrors=true
src=http://www.ibiblio.org/maven/commons-discovery/jars/commons-discovery-SNAPSHOT.jar;
+get dest=${libdir}/commons-discovery-SNAPSHOT.jar usetimestamp=true
ignoreerrors=true
src=http://www.apache.org/dist/java-repository/commons-discovery/jars/commons-discovery-SNAPSHOT.jar;
/get
-get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar;
+get dest=${libdir}/junit-3.8.1.jar usetimestamp=true ignoreerrors=true
src=http://www.apache.org/dist/java-repository/junit/jars/junit-3.8.1.jar;
/get
-get dest=${libdir}/ant-1.5.jar usetimestamp=true ignoreerrors=true
src=http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar;
+get dest=${libdir}/ant-1.5.jar usetimestamp=true ignoreerrors=true
src=http://www.apache.org/dist/java-repository/ant/jars/ant-1.5.jar;
/get
-get dest=${libdir}/ant-optional-1.5.jar usetimestamp=true
ignoreerrors=true src=http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar;
+get dest=${libdir}/ant-optional-1.5.jar usetimestamp=true
Re: [lang] i18n package proposal
Henri Yandell wrote: LocalizedMessageSource? and change getResourceKey to getMessageKey ? Other names: LocalizedMessagable LocalizedThrowableMessagable etc. Sounds good, but the scope should be [lang], [ressource] or the yet-to-create [i18n] project. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/math/xdocs/userguide xdoc.xsl
mdiggory2004/01/30 11:58:37 Modified:math/xdocs xdoc.xsl math/xdocs/userguide xdoc.xsl Log: Ajusting xdoc templates css styles appropriately, these are just used for testing/preview in xml/xslt enabled browsers. Revision ChangesPath 1.2 +10 -2 jakarta-commons/math/xdocs/xdoc.xsl Index: xdoc.xsl === RCS file: /home/cvs/jakarta-commons/math/xdocs/xdoc.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- xdoc.xsl 15 Nov 2003 18:38:16 - 1.1 +++ xdoc.xsl 30 Jan 2004 19:58:37 - 1.2 @@ -6,8 +6,9 @@ xsl:apply-templates select=/document/properties/title/ xsl:apply-templates select=/document/meta/ style type=text/css - @import url(./stylesheets/tigris.css); - @import url(./stylesheets/maven.css); + @import url(./style/tigris.css); + @import url(./style/maven.css); + @import url(./style/project.css); /style link rel=stylesheet href=./style/print.css type=text/css media=print/link /head @@ -33,6 +34,13 @@ xsl:apply-templates/ /div /xsl:template + xsl:template match=source + div id=source + pre + xsl:apply-templates/ + /pre + /div + /xsl:template xsl:template match=node()|@* xsl:copy xsl:apply-templates select=@*/ 1.2 +10 -2 jakarta-commons/math/xdocs/userguide/xdoc.xsl Index: xdoc.xsl === RCS file: /home/cvs/jakarta-commons/math/xdocs/userguide/xdoc.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- xdoc.xsl 15 Nov 2003 18:43:24 - 1.1 +++ xdoc.xsl 30 Jan 2004 19:58:37 - 1.2 @@ -6,8 +6,9 @@ xsl:apply-templates select=/document/properties/title/ xsl:apply-templates select=/document/meta/ style type=text/css - @import url(../stylesheets/tigris.css); - @import url(../stylesheets/maven.css); + @import url(../style/tigris.css); + @import url(../style/maven.css); + @import url(../style/project.css); /style link rel=stylesheet href=../style/print.css type=text/css media=print/link /head @@ -33,6 +34,13 @@ xsl:apply-templates/ /div /xsl:template + xsl:template match=source + div id=source + pre + xsl:apply-templates/ + /pre + /div + /xsl:template xsl:template match=node()|@* xsl:copy xsl:apply-templates select=@*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [fileupload] FileItem.getFieldName() does not follow specifie d en coding?
Okay. I re-tract my current this question. It was the client not encoding name attribute of the input field. It was not the fileupload package at all. My apologies to the fileupload team. -Original Message- From: Robert Priest Sent: Thursday, January 29, 2004 4:16 PM To: 'Jakarta Commons Developers List' Subject: RE: [fileupload] FileItem.getFieldName() does not follow specifie d en coding? I am using the latest version of the fileupload jar (commons-fileupload-1.0.jar) -Original Message- From: Robert Priest Sent: Thursday, January 29, 2004 2:53 PM To: 'Jakarta Commons Developers List' Subject: [fileupload] FileItem.getFieldName() does not follow specified en coding? Hello, I am using DiskFileUpload and the DefaultFileItem classes. I am setting the Header Encoding (in my jsp page) as so: // Create a new file upload handler DiskFileUpload upload = new DiskFileUpload(); //set the encoding to UTF-8 upload.setHeaderEncoding(UTF-8); I am attempting to upload a file with Chinese characters in the name. But when I do a FileItem.getFieldName(), I am coming up with for the file name. However, FileItem.getName() seems to be correctly encoded? Can anyone tell me what I could be missing when I perform a getFieldName(). I know that you can get the contents of a item by specifying FileItem.getString(UTF-8), and that will decode correctly. However, there is no such call for getFieldName(). Thanks in advance. - 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: [math] running math tests on minotaur hangs
I'll do alittle more individual testcase testing in Ant and Maven then get back to you on that. -Mark Phil Steitz wrote: --- Mark R. Diggory [EMAIL PROTECTED] wrote: Does anyone else encounter a hang when running the tests in maven on minotaur? % maven test [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.125 sec [junit] Running org.apache.commons.math.random.RandomDataTest RandomDataTest just hangs indefinitely, If I build on my workstation's here in my office (Linux, NT) everything seems to work ok. very odd, very odd indeed. -Mark Any idea what test is hanging? Does it hang when run from Ant? One thing that could theoretically hang / take a long time is nextPoisson(), which I think is tested there, though the probability of it taking even a second should be astronomically small with the actual parameter in the test (assuming things are working correctly). I will add a bound for this in any case. Phil __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [math] Straw man release plan
Phil, I've added some issues I want to address in the release process, if you wish to take on the RM roles associated with 1, I think we would be honored. -thx, Mark Phil Steitz wrote: After reviewing http://jakarta.apache.org/site/versioning.html I agree with Mark that we should be aiming for a 1.0 release of [math]. Here is a straw man plan, with lots of detail missing. 1. Complete the following code / doco tasks a. Finish the User Guide b. Finalize and execute RealMatrix solve() strategy c. Finalize and execute spline changes d. Extend certified data tests with tests against R or other sources (need to finalize what is included here) e. Fix broken links and other errors in javadoc f. Improve path and boundary value test coverage g. Finalize and implement BeanList stats 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) a. Add a a preGoal for dist to make sure the generated user guide html gets into the distributions. b. Remove experimental directory from binary distribution, think this was just a build error c. create manifest entries for jars. d. create INSTALL readme for src distribution (bulding instructions for ant and maven) e. iron out details of tagging repository when release is cut with maven 3. Depending on feedback from B1, proceed either to B2... or RC1... then 1.0 final. Am I missing anything? Are there other things that we think really *must* get into 1.0? Are there things that we should omit? Mark, do you want to play the Release Manager role? If not, I am willing to do it. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [math] Straw man release plan
Brent, Welcome, we have been creating documentation on th developer process. its probably best you read through it and then talk with us more. http://jakarta.apache.org/commons/math/developers.html 1.) Specifically focus on the areas of working with ant, maven, cvs, creating patches and submitting them via bugzilla. This is how you make your first steps in the contributor/commiter process 2.) What your development environment at this time? Ant and Maven work good for testing/building. I'd recommend eclipse for its ant, cvs and refactoring capabilities, plus its free. www.eclipse.org 3.) Post lots of questions on the list. Get involved with the discussions on RealMatrix related stuff. Cheers -Mark Brent Redeker wrote: Hello everybody, My name is Brent Redeker, and I've had some interest in the Commons Math project since I heard of it about a month ago. I've been meaning to offer any help I can give to the project, and perhaps I can be of some assistance in preparing for a 1.0 release. If the project could use my help, and if somebody could get me started, I'd be glad to do what I can. (Unfortunately, I'll probably need some hand-holding at first, as I am unfamiliar with how Apache contributors work.) I'm actually kind of interested in the Commons Math linear package, as that seems like it needs some work yet. Although I haven't finished my degree yet, I've had a number of mathematics courses, including Linear Algebra and Numerical Analysis, so I'm sure I know enough to be of some use. Brent Redeker On Jan 30, 2004, at 8:58 AM, Phil Steitz wrote: After reviewing http://jakarta.apache.org/site/versioning.html I agree with Mark that we should be aiming for a 1.0 release of [math]. Here is a straw man plan, with lots of detail missing. 1. Complete the following code / doco tasks a. Finish the User Guide b. Finalize and execute RealMatrix solve() strategy c. Finalize and execute spline changes d. Extend certified data tests with tests against R or other sources (need to finalize what is included here) e. Fix broken links and other errors in javadoc f. Improve path and boundary value test coverage g. Finalize and implement BeanList stats 2. Use Mark's magical maven release-generator to cut a 1.0-B1 release including everything currently in CVS other than the /experimental tree. (Confidence intervals, the Bootstrap and Multiple Regression will have to wait until 1.1.) 3. Depending on feedback from B1, proceed either to B2... or RC1... then 1.0 final. Am I missing anything? Are there other things that we think really *must* get into 1.0? Are there things that we should omit? Mark, do you want to play the Release Manager role? If not, I am willing to do it. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26517] - Compilation of jsvc fails, missing ; in home.c
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=26517.
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=26517
Compilation of jsvc fails, missing ; in home.c
--- Additional Comments From [EMAIL PROTECTED] 2004-01-30 20:25 ---
Just to elaborate, as I ran into this 'make' error as well, while setting up
Tomcat (on Redhat Linux 9). And after adding the semicolon I get the home.o
output file successfully.
Line 110 is part of the parse() function in home.c
static bool parse(home_data *data) {
...
if(sp != NULL)
*sp = '\0'; /* Semicolon added on line 110 :-) */
}
Now the next, perhaps separate bug, is that I get a compile error in the java.c
source file when I attempt to finish the make. Here is the error in the output
gcc -g -O2 -DCPU=\i386\ -DOS_LINUX -DDSO_DLFCN
-I/usr/local/java/j2sdk_nb/j2sdk1.4.2/include
-I/usr/local/java/j2sdk_nb/j2sdk1.4.2/include/linux -Wall -Wstrict-prototypes -c
java.c -o java.o
java.c: In function `java_init':
java.c:156: warning: implicit declaration of function `dso_error'
Thanks,
Francis J. Wildhaber
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26470] - TreeBidiMap.put(Object, Object) throws ClassCastException
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=26470. 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=26470 TreeBidiMap.put(Object, Object) throws ClassCastException [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 21:04 --- Playing devil's advocate for a moment... if both objects need to implement Comparable, why not add a put(Comparable, Comparable) method to TreeBidiMap, and have put(Object, Object) throw an IllegalArgumentException that explicitly identifies the arguments' non-Comparability as the problem? Of course, I'm taking for granted that signatures are dynamically checked for specificity at runtime and not limited to those the compiler explicitly knew about at compile time (It's been a while since I've tiptoed through THAT dimly- lit corner of the Java universe), but I'd be fairly shocked if the proper behavior were for the JVM to stupidly ignore TreeBidiMap's put(Comparable, Comparable) method (if one were added) and pass the call along to its put (Object, Object) method instead since that's all a generic Map-implementing object has... ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JIRA][Bugzilla][HttpClient] should I stay or should I go?
Oleg, Sorry, I thought many of these points were addressed in the general discussion about commons and JIRA. I will respond specifically to each of your questions below... [EMAIL PROTECTED] wrote: * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? No, we will not encourage. * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? Yes, existing bug reports can be transfered in their entirety. There is a data migration process. All accounts would also be preserved, although after the conversion, if you change your password in one place (JIRA or bugzilla), it won't change in the other. * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). Agreed, release management is really the kicker for why I wanted it for the James project and why I've been (slowly) getting JIRA running. As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. I don't know who or if anybody maintains the bugzilla info. I would send just this request to the infrastructure mailing list and hopefully someone can help. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net][vote] Release plan for commons-net.1.2.0
I am now proposing for a formal vote, releasing commons-net.1.2.0. The proposal is to release the current HEAD branch, as last amended by me over a week ago. I know there are other patches that have been submitted but no one seems to have the time to evaluate them. The current version of the code contributes autodetection of system type with manual override capability for any ListParser and accomplishes substantial refactoring, reducing the confusion level in this part of the system. These are important changes and will enable better interface with Ant. This plan does NOT encompass the release of the 1.1.1 branch as the last JDK1.1 compatible version. Although the code now in that branch compiles and runs if jakarta-oro-2.0.1.jar is substituted for 2.0.7, it throws JIT errors which probably have more to do with my execution environment or some configuration mistake in this ancient JDK and I'm stumped. I recommend doing this release later (CVS tag is there, waiting to be handled) when more time may be available to look at these issues. If anyone is familiar with JIT errors in JDK1.1 perhaps they can weigh in on what error messages in my previous emails mean. My vote, of course: +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] i18n package proposal
If it's all that is defined in the proposal, I think lang is fine. If it all grows beyond that, I have my doubts that it would be right in lang because it will most likely have become an i18n thing and not just a nice marker for throwables. Hen On Fri, 30 Jan 2004, J.Pietschmann wrote: Henri Yandell wrote: LocalizedMessageSource? and change getResourceKey to getMessageKey ? Other names: LocalizedMessagable LocalizedThrowableMessagable etc. Sounds good, but the scope should be [lang], [ressource] or the yet-to-create [i18n] project. J.Pietschmann - 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: [lang] i18n package proposal
Correct me if i'm wrong, but doesn't Throwable have a
getLocalizedMessage() method which defaults to calling
getMessage()?
Ideally, your exception construction would take in the
resource key, and the getLocalizedMessage method would
use that key to retrieve the resource.
Personally, i think Sun should have included the Locale
in that method signature. Otherwise, you'd have to just
assume the system default locale, or have some static
to get the current locale. Not a great idea in my
opinion.
What i did on a previous job was this:
public class LocalizableException
extends Exception {
...
public String getLocalizedMessage(Locale locale) {
}
}
public class LocalizableRuntimeException
extends RuntimeException {
...
public String getLocalizedMessage(Locale locale) {
}
}
The exception's constructor would then take any message
parameters it needed, and store them. I personally don't
like the use of the Messages class because it is so common
to parameterize resource strings, that I think it ought
to be part of the Resources interface itself to get a message
with parameters.
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 5:37 PM
To: Jakarta Commons Developers List
Subject: Re: [lang] i18n package proposal
If it's all that is defined in the proposal, I think lang is fine. If it
all grows beyond that, I have my doubts that it would be right in lang
because it will most likely have become an i18n thing and not just a nice
marker for throwables.
Hen
On Fri, 30 Jan 2004, J.Pietschmann wrote:
Henri Yandell wrote:
LocalizedMessageSource? and change getResourceKey to getMessageKey ?
Other names: LocalizedMessagable LocalizedThrowableMessagable etc.
Sounds good, but the scope should be [lang], [ressource] or the
yet-to-create [i18n] project.
J.Pietschmann
-
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 26470] - TreeBidiMap.put(Object, Object) throws ClassCastException
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=26470. 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=26470 TreeBidiMap.put(Object, Object) throws ClassCastException [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 22:52 --- Time to be shocked I'm afraid. Adding the extra put method does not force it to get called. For example, this is especially true when calling via the BidiMap interface. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] i18n package proposal
I am -1 to adding behaviour to do with localized messages into [lang]. It gets way too complex and religious and just doens't fit. Stephen From: Henri Yandell [EMAIL PROTECTED] If it's all that is defined in the proposal, I think lang is fine. If it all grows beyond that, I have my doubts that it would be right in lang because it will most likely have become an i18n thing and not just a nice marker for throwables. Hen On Fri, 30 Jan 2004, J.Pietschmann wrote: Henri Yandell wrote: LocalizedMessageSource? and change getResourceKey to getMessageKey ? Other names: LocalizedMessagable LocalizedThrowableMessagable etc. Sounds good, but the scope should be [lang], [ressource] or the yet-to-create [i18n] project. J.Pietschmann - 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: [lang] Array concat?
I believe that the collections like names will be best in the long run. Thus: add(Object[], Object) add(Object[], int, Object) addAll(Object[], Object[]) Stephen From: Gary Gregory [EMAIL PROTECTED] I've committed to HEAD three new ArrayUtils methods and unit tests: add(Object[], Object) add(Object[], int, Object) join(Object[], Object[]) Please comment on method names or impl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Array concat?
So:
(0) join
Current name and will be renamed to one of the following.
(1) concat
Henri and Janek like it.
(2) merge
Proposed by [EMAIL PROTECTED]
I'm not fond of this one. I cannot help but think of a merge sort; to me
merge does not imply order, as in: add one after the other.
(3) add
Recall that we also now have:
a) add(Object[], Object)
b) add(Object[], int, Object)
So why not:
c) add(Object[], Object[])
If we like 3a and 3b, 3c makes the most sense I think.
Gary
-Original Message-
From: Tim Reilly [mailto:[EMAIL PROTECTED]
Sent: Friday, January 30, 2004 00:03
To: Jakarta Commons Developers List
Subject: RE: [lang] Array concat?
I've been trying to resist commenting (since I've not contributed anything
here) but I agree with Janek; an Array's join method has a different
meaning
in other languages (ECMAScript, VBScript, and others). IMHO following the
expectations users have who know the other languages helps the usability
of
the library.
e.g.
Object[] anArray = {one, two, three};
ArrayUtil.join(anArray, , );
outputs one, two, three
This would also compliment java.lang.String.split(regex);
Some other suggestions for the join name:
merge(Object[], Object[]) //Rename of join()
mergeNoDuplicates(Object[], Object[]) //Merges and eliminates duplicates
append(Object[], Object[]) //Convenience method calls merge a, b
append(Object[], Object) //Convenience method calls add
prepend(Object[], Object[]) //Convenience method calls merge b, a
prepend(Object[], Object) //Convenience method calls add using pos 0
join(Object[], String) //
http://www.devguru.com/Technologies/ecmascript/quickref/join.html
Instead of just throwing up ideas I decided to create these and so
attached
are patches. The convenience methods aren't that important. It would be
nice
to see the merge, mergeNoDuplicates, and join make it?
p.s. I didn't create test-cases at least for the time being. Let's see
what
others think first. Hope the attachments make it, if not I can do
Bugzilla/Jira
-Original Message-
From: Gary Gregory [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 8:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [lang] Array concat?
Hello,
I've committed to HEAD three new ArrayUtils methods and unit tests:
add(Object[], Object)
add(Object[], int, Object)
join(Object[], Object[])
Please comment on method names or impl.
Thank you to Maarten for the patch the add methods are based on.
Ticket is: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26056
Gary
-Original Message-
From: Janek Bogucki [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 14:27
To: Jakarta Commons Developers List
Subject: RE: [lang] Array concat?
On Thu, 2004-01-29 at 12:05, Gary Gregory wrote:
Ah, I do recall join now, much better.
Thanks,
Gary
concat is the best choice because join implies the introduction of a
delimiter between the two arrays which is not the outcome, while
append
implies the extension of an existing object somehow and arrays don't
get
extended. To me, concat does hint at the production of a new object.
-Janek
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Array concat?
Ah! Synchronicity! hh -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 15:16 To: Jakarta Commons Developers List Subject: Re: [lang] Array concat? I believe that the collections like names will be best in the long run. Thus: add(Object[], Object) add(Object[], int, Object) addAll(Object[], Object[]) Stephen From: Gary Gregory [EMAIL PROTECTED] I've committed to HEAD three new ArrayUtils methods and unit tests: add(Object[], Object) add(Object[], int, Object) join(Object[], Object[]) Please comment on method names or impl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: access denied exception
Hello,
this looks like a Java2 security problem. Two options:
Hack: Disable Java2 security.
Clean: grant your application the necessary permissions
in the java.policy file
The file should be in ${JAVA_HOME}/jre/lib/security/
I hope someone else can come up with the exact
permission entries required for the HTTP Client.
best regards,
Roland
D Alvarado [EMAIL PROTECTED]
30.01.2004 06:36
Please respond to Commons HttpClient Project
To: [EMAIL PROTECTED]
cc:
Subject:access denied exception
Hi, I was hoping someone could help me with this
exception. I'm trying to POST some data to a
remote site using https. The code is almost
directly from jakarta:
// Create an instance of HttpClient.
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
// Create a method instance.
PostMethod method = new
PostMethod(https://www.thirdparty.com;);
method.setRequestBody(data);
// Execute the method.
int statusCode = -1;
int attempt = 0;
// We will retry up to 3 times.
while (statusCode == -1 attempt 3) {
try {
// execute the method.
statusCode =
client.executeMethod(method);
} catch (HttpRecoverableException
e) {
System.err.println(A
recoverable exception occurred, retrying. +
e.getMessage());
} catch (IOException e) {
System.err.println(Failed to download file.);
e.printStackTrace();
}
}
// Check that we didn't run out of retries.
if (statusCode == -1) {
System.err.println(Failed to
recover from exception.);
}
I am running WebLogic 5.1 sp12, with the lastest
version of JSSE. But the above code generates
the following exception:
java.security.AccessControlException: access
denied (java.security.SecurityPermission
getProperty.ssl.SocketFactory.provider)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.security.Security.getProperty(Security.java:879)
at javax.net.ssl.SSLSocketFactory$1.run(DashoA6275)
at
java.security.AccessController.doPrivileged(Native
Method)
at javax.net.ssl.SSLSocketFactory.a(DashoA6275)
at
javax.net.ssl.SSLSocketFactory.getDefault(DashoA6275)
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:112)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at
jsp_servlet._ma._thinkwell._student.__tw_student_redirect._jspService(__tw_student_redirect.java:238)
at lycea.ui.LyceaJspServlet.service(Unknown Source)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:138)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:945)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)
Any thoughts? Thanks for your time, Dave
Care2 make the world greener!
Think twice before eating farmed salmon. Find out why:
http://www.care2.com/go/z/11051/1067
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Re: Httpclient won't run in JUnit
Michael Czeiszperger wrote: java.lang.ExceptionInInitializerError Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.comons.logging.impl.Jdk14Logger does not implement Log This happens when there is an old version of commons-logging in the classpath. Please check if you can update to a later version. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why on earth do we differenciate between proxy and host credentials?
On 30/1/04 1:32 AM, Roland Weber [EMAIL PROTECTED] wrote: Hello Oleg, from a technical standpoint, host and port would be sufficient to differentiate between a proxy and HTTP server on the same machine. Actually it's not. It's quite possible to have a proxy and a webserver running on the same port on the same machine (using the same interface with the same IP address for what it's worth). We actually have this setup at work on a Windows 2000 box. I believe it works because the proxy is essentially just a module in IIS so it's really just the one program that behaves differently depending on it's input. I believe the same can be achieved with Apache using the right module. It would be technically possible to require (or for users to desire) the use of different credentials with such a proxy/web server combination. I would definitely concede that it's a very unusual case so I'm certainly not against combining the credentials. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Httpclient won't run in JUnit
On Jan 30, 2004, at 3:44 AM, Ortwin Glück wrote: Michael Czeiszperger wrote: java.lang.ExceptionInInitializerError Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Class org.apache.comons.logging.impl.Jdk14Logger does not implement Log This happens when there is an old version of commons-logging in the classpath. Please check if you can update to a later version. Thanks for the help. I'm using commons-logging 1.0.3, which appears to be the latest version available. Michael Czeiszperger czei at webperformanceinc dot com Web Performance, Inc. 919-845-7601 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10794] - User interaction for authentication
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=10794. 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=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 15:55 --- Created an attachment (id=10158) Patch (take 3) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why on earth do we differenciate between proxy and hostcredentials?
Hi Adrian, All right. I give up. Evil Comrade Oleg will leave HttpState alone ;-) Besides, Roland has made a good point. It may be a bit cumbersome to set default proxy and host credentials if all credentials are kept in the same pool. Oleg -Original Message- From: Adrian Sutton [mailto:[EMAIL PROTECTED] Sent: Friday, January 30, 2004 12:40 To: Commons HttpClient Project Subject: Re: Why on earth do we differenciate between proxy and hostcredentials? On 30/1/04 1:32 AM, Roland Weber [EMAIL PROTECTED] wrote: Hello Oleg, from a technical standpoint, host and port would be sufficient to differentiate between a proxy and HTTP server on the same machine. Actually it's not. It's quite possible to have a proxy and a webserver running on the same port on the same machine (using the same interface with the same IP address for what it's worth). We actually have this setup at work on a Windows 2000 box. I believe it works because the proxy is essentially just a module in IIS so it's really just the one program that behaves differently depending on it's input. I believe the same can be achieved with Apache using the right module. It would be technically possible to require (or for users to desire) the use of different credentials with such a proxy/web server combination. I would definitely concede that it's a very unusual case so I'm certainly not against combining the credentials. Regards, Adrian Sutton. -- Intencha tomorrow's technology today Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10794] - User interaction for authentication
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=10794. 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=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 16:33 --- Folks, This patch is based on the patch (take 1) with the following changes: * Global CredentialsPrompter class has been removed * Authentication callbacks moved to HttpMethodParams class * Authentication realm key is now comprised of host name, port, realm name and authentication type Please let me know what you think. I know that test cases are lacking. As soon as the API stabilize a little, I'll provide test cases for new functionality using Odi's shiny new simple HTTP server / simple proxy framework - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HttpClient][Bugzilla] should I stay or should I go?
Folks, Did I say something glaringly stupid in my message below? It's been a week since I sent this request. I have not received a single response so far. Any idea what may be wrong? Or are our infrastructure folks simply too overwhelmed these days sorting out MyDoom mess? Shall I forward the original message to commons-dev list? Oleg -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 21:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jakarta Commons HttpClient mailing list Subject: [HttpClient][Bugzilla] should I stay or should I go? Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - 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: [HttpClient][Bugzilla] should I stay or should I go?
I see nothing wrong with your original email. Perhaps an email to commons-dev would be helpful. Mike On Jan 30, 2004, at 11:57 AM, Kalnichevski, Oleg wrote: Folks, Did I say something glaringly stupid in my message below? It's been a week since I sent this request. I have not received a single response so far. Any idea what may be wrong? Or are our infrastructure folks simply too overwhelmed these days sorting out MyDoom mess? Shall I forward the original message to commons-dev list? Oleg -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Thursday, January 22, 2004 21:28 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Jakarta Commons HttpClient mailing list Subject: [HttpClient][Bugzilla] should I stay or should I go? Good day, Following the proposal to migrate Jakarta Commons projects from Bugzilla to JIRA posted to the Jakarta commons-dev list, we would like to have a few points clarified, before the final decision can be made whether Jakarta Commons HttpClient project stays with Bugzilla or migrates (kindly requests to be migrated) to JIRA. * Do you actually encourage migration from Bugzilla to JIRA? Will it make the task of to administering and supporting projects' infrastructure (issue tracking in the first place) easier for you? * Can existing bug reports (including closed ones) be migrated to JIRA in their entirety, if at all? What kind of data would not be migrated automatically? Would existing user accounts be preserved? * We (HttpClient committers contributors) have been in fact quite satisfied with Bugzilla so far. It has served us well. The only thing we have found constraining is the release management (versions, milestones, etc). As an alternative to migration to JIRA would it be possible to promote HttpClient from a component of Jakarta-commons project to a full fledged top level project with its own set of versions and milestones? HttpClient has already got its own mailing list. HttpClient related content constitutes 20-30% Bugzilla entries for the Jakarta-commons project. I believe this might be the best option, as least as far as we are concerned. I am just not sure it is technically feasible. Cheers, Oleg - 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 10794] - User interaction for authentication
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=10794. 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=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 18:48 --- Oleg, Overall I think the design is good now. I have just a few comments on some of the specifics. - I would prefer the name CredentialsProvider to CredentialsCallback. Though callback works, I think provider is a little more standard. - Also, I am wondering if the CredentialsCallback.getCredentials() method should be changed to accept an instance of HttpAuthRealm instead of the scheme, host, and port. - The callback param is currently assumed to be a Collection, but I wonder if this is really necessary. It seems like just a CredentialsCallback should be sufficient, especially since it can be configured on a per method basic. I haven't had time to look closely at the HttpMethodDirector authentication logic but I think some test cases will take care of that. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10794] - User interaction for authentication
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=10794. 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=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 19:55 --- Created an attachment (id=10165) Patch (take 3) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10794] - User interaction for authentication
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=10794. 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=10794 User interaction for authentication --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 20:03 --- Oopsie. The patch is in fact the 'take 4'. Mike, I agree with all your points. However, I feel that CredentialsCallback#getCredentials() taking AuthScheme as a parameter buys us a little more flexibility. For some authentication schemes parameters other than host, port, realm and auth type _may_ be of some use (like domain for NTLM scheme). Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26139] - Memory leak in MultiThreadedHttpClient caused by bad .equals()
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=26139. 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=26139 Memory leak in MultiThreadedHttpClient caused by bad .equals() [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-30 19:23 --- Patch applied to 2.0. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Httpclient won't run in JUnit
On Jan 29, 2004, at 5:10 PM, Michael Becke wrote:
Looks like a class loader problem. My guess is that commons-logging
is being loaded by more than one class loader.
I figured that since HttpClient uses JUnit for its test suite that
HttpClient had to be compatible with JUnit. Here's the most simple
JUnit example showing that the latest versions of HttpClient does not
run with JUnit. The example does nothing but start JUnit with the
latest versions of HttpClient and commons logging and no other
libraries involved:
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
import junit.framework.*;
/**
* Simple example showing problem with running HttpClient code within
JUnit
*/
public class HttpClientJunitBug extends TestCase
{
public HttpClientJunitBug(String s)
{
super(s);
}
public void testSimple()
{
org.apache.commons.httpclient.HttpClient client = new
org.apache.commons.httpclient.HttpClient();
assertTrue( client != null );
}
}
promptjavac HttpClientJunitBut.java
promptjava -cp
junit.jar:commons-httpclient-2.0-rc2.jar:commons-logging-api.jar:.
junit.swingui.TestRunner HttpClientJunitBug
The result is:
java.lang.ExceptionInInitializerError
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.comons.logging.impl.Jdk14Logger does not implement Log
I thought maybe someone who runs the HttpClient test suite regularly
would be able to spot my mistake easily. (Hopefully!)
Thanks,
Michael Czeiszperger
czei at webperformanceinc dot com
Web Performance, Inc.
919-845-7601
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: access denied exception
Thanks kindly for the reponse. Just one small
follow-up question. What am I granting
permission to access what?
Much thanks - Dave
Begin Original Message
From: Roland Weber [EMAIL PROTECTED]
Sent: Fri, 30 Jan 2004 09:18:40 +0100
To: Commons HttpClient Project
[EMAIL PROTECTED]
Subject: Re: access denied exception
Hello,
this looks like a Java2 security problem. Two
options:
Hack: Disable Java2 security.
Clean: grant your application the necessary
permissions
in the java.policy file
The file should be in ${JAVA_HOME}/jre/lib/security/
I hope someone else can come up with the exact
permission entries required for the HTTP Client.
best regards,
Roland
D Alvarado [EMAIL PROTECTED]
30.01.2004 06:36
Please respond to Commons HttpClient Project
To:
[EMAIL PROTECTED]
cc:
Subject:access denied exception
Hi, I was hoping someone could help me with this
exception. I'm trying to POST some data to a
remote site using https. The code is almost
directly from jakarta:
// Create an instance of HttpClient.
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
// Create a method instance.
PostMethod method = new
PostMethod(https://www.thirdparty.com;);
method.setRequestBody(data);
// Execute the method.
int statusCode = -1;
int attempt = 0;
// We will retry up to 3 times.
while (statusCode == -1 attempt 3) {
try {
// execute the method.
statusCode =
client.executeMethod(method);
} catch (HttpRecoverableException
e) {
System.err.println(A
recoverable exception occurred, retrying. +
e.getMessage());
} catch (IOException e) {
System.err.println(Failed to download file.);
e.printStackTrace();
}
}
// Check that we didn't run out of retries.
if (statusCode == -1) {
System.err.println(Failed to
recover from exception.);
}
I am running WebLogic 5.1 sp12, with the lastest
version of JSSE. But the above code generates
the following exception:
java.security.AccessControlException: access
denied (java.security.SecurityPermission
getProperty.ssl.SocketFactory.provider)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.security.Security.getProperty(Security.java:879)
at javax.net.ssl.SSLSocketFactory$1.run(DashoA6275)
at
java.security.AccessController.doPrivileged(Native
Method)
at javax.net.ssl.SSLSocketFactory.a(DashoA6275)
at
javax.net.ssl.SSLSocketFactory.getDefault(DashoA6275)
at
org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:112)
at
org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:663)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:661)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:529)
at
jsp_servlet._ma._thinkwell._student.__tw_student_redirect._jspService(__tw_student_redirect.java:238)
at lycea.ui.LyceaJspServlet.service(Unknown Source)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:120)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:138)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:945)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:909)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:269)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:392)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:274)
at
weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)
Any thoughts? Thanks for your time, Dave
Care2 make the world greener!
Think twice before eating farmed salmon. Find out
why:
http://www.care2.com/go/z/11051/1067
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
End Original Message
Care2 make the world greener!
Think twice before eating farmed salmon. Find out why:
http://www.care2.com/go/z/11051/1067
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
