DO NOT REPLY [Bug 34677] - [Math] homoscedasticTTest method uses non homoscedastic method

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34677


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-05-02 07:19 ---
Good catch - yes, this should use the homoscedastic t statistic. Previous test
case masked the error, as the t statistics took the same value.  Code has been
fixed and test cases made more sensitive. 

Fixed in nightly builds starting 02-may-2005.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r165583 - in /jakarta/commons/proper/math/trunk: src/experimental/R/TTestCases src/java/org/apache/commons/math/stat/inference/TTestImpl.java src/test/org/apache/commons/math/stat/inference/TTestTest.java xdocs/changes.xml

[psteitz]

Author: psteitz
Date: Sun May  1 22:14:49 2005
New Revision: 165583

URL: http://svn.apache.org/viewcvs?rev=165583&view=rev
Log:
Fixed error in TTestImpl.homoscedasticTtest. Implementation was
incorrectly using heteroscedastic t statistic. Also improved sensitivity
of test cases.
BZ #34677
Reported by: Gilles Gaillard

Added:
jakarta/commons/proper/math/trunk/src/experimental/R/TTestCases
Modified:

jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/stat/inference/TTestImpl.java

jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/stat/inference/TTestTest.java
jakarta/commons/proper/math/trunk/xdocs/changes.xml

Added: jakarta/commons/proper/math/trunk/src/experimental/R/TTestCases
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/src/experimental/R/TTestCases?rev=165583&view=auto
==
--- jakarta/commons/proper/math/trunk/src/experimental/R/TTestCases (added)
+++ jakarta/commons/proper/math/trunk/src/experimental/R/TTestCases Sun May  1 
22:14:49 2005
@@ -0,0 +1,105 @@
+#   Copyright 2005 The Apache Software Foundation
+#
+#   Licensed under the Apache License, Version 2.0 (the "License");
+#   you may not use this file except in compliance with the License.
+#   You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+#   Unless required by applicable law or agreed to in writing, software
+#   distributed under the License is distributed on an "AS IS" BASIS,
+#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+#   See the License for the specific language governing permissions and
+#   limitations under the License.
+#
+#--
+# R source file to validate TTest tests in
+# org.apache.commons.math.inference.TTestImpl
+#
+# To run the test, install R, put this file and testFunctions
+# into the same directory, launch R from this directory and then enter
+# source("")
+#
+# R functions used
+# t.test(x, y = NULL, alternative = c("two.sided", "less", "greater"),
+# mu = 0, paired = FALSE, var.equal = FALSE, ... )
+# Arguments
+#   x  a numeric vector of data values.
+#   y  an optional numeric vector data values.
+#   alternativea character string specifying the alternative 
hypothesis, 
+# must be one of "two.sided" (default), "greater" or "less". You can 
specify
+# just the initial letter.
+#   mu  a number indicating the true value of the mean (or difference in means
+#  if you are performing a two sample test).
+#   paired a logical indicating whether you want a paired t-test.
+#   var.equal  a logical variable indicating whether to treat the two
+# variances as being equal. 
+# If TRUE then the pooled variance is used to estimate the variance,
+# otherwise the Welch (or Satterthwaite) approximation to the degrees
+# of freedom is used.
+#--
+tol <- 1E-10   # error tolerance for tests
+#--
+# Function definitions
+#--
+source("testFunctions")   # utility test functions
+#--
+# Verification function
+#
+verifyTest <- function(out,expectedP, expectedT,
+  tol) {
+  if (assertEquals(expectedP, out$p.value, tol,
+ "Ttest p value")) {
+ displayPadded(output, SUCCEEDED, 80)
+  } else {
+ displayPadded(output, FAILED, 80)
+  }  
+  output <- c("t test test statistic") 
+  if (assertEquals(expectedT, out$statistic, tol,
+  "Ttest t statistic")) {
+  displayPadded(output, SUCCEEDED, 80)
+  } else {
+  displayPadded(output, FAILED, 80)
+  }  
+  displayDashes(WIDTH)
+}
+
+cat("One-sample, two-sided TTest test cases \n")
+sample1 <- c(93.0, 103.0, 95.0, 101.0, 91.0, 105.0, 96.0, 94.0, 101.0,  88.0,
+  98.0, 94.0, 101.0, 92.0, 95.0)
+out <- t.test(sample1, mu=100.0)
+expectedP <-  0.0136390585873
+expectedT<- -2.81976445346
+verifyTest(out,expectedP, expectedT, tol) 
+
+cat("One-sample, one-sided TTest test cases \n")
+sample1 <- c(2, 0, 6, 6, 3, 3, 2, 3, -6, 6, 6, 6, 3, 0, 1, 1, 0, 2, 3, 3)
+out <- t.test(sample1, mu=0.0, alternative="g")
+expectedP <-  0.000521637019637
+expectedT<- 3.86485535541
+verifyTest(out,expectedP, expectedT, tol) 
+
+cat("Homoscedastic TTest test cases \n")
+sample1 <- c(2, 4, 6, 8, 10, 97)
+sample2 <- c(4, 6, 8, 10, 16)
+out <- t.test(sample1,sample2,var.equal = TRUE)
+expectedP <-  0.4833963785
+expectedT<- 0.73096310086
+verifyTest(out,expectedP, expectedT, tol)
+ 
+cat("Heteroscedastic TTest test cases \n")
+sample1 <- c(7, -4, 18, 17, -3, -5, 1, 10, 11, -2)
+sample2 <- c(-1, 12, -1, -3, 3, 

svn commit: r165581 - /jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java

[psteitz]

Author: psteitz
Date: Sun May  1 22:01:44 2005
New Revision: 165581

URL: http://svn.apache.org/viewcvs?rev=165581&view=rev
Log:
Removed unused import.

Modified:

jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java

Modified: 
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java?rev=165581&r1=165580&r2=165581&view=diff
==
--- 
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
 (original)
+++ 
jakarta/commons/proper/math/trunk/src/test/org/apache/commons/math/util/MathUtilsTest.java
 Sun May  1 22:01:44 2005
@@ -17,8 +17,6 @@
 
 import java.math.BigDecimal;
 
-import org.apache.commons.math.TestUtils;
-
 import junit.framework.Test;
 import junit.framework.TestCase;
 import junit.framework.TestSuite;



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed

[Brett Porter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I spoke to Paul Brown about it, and he said its either a bug, or
tightening up compliance and some abuses breaking. If you post it to the
jaxen list, somebody will probably track it down.

I don't think I'm familiar enough with it to hold a conversation about it.

- - Brett

Dion Gillard wrote:

>Looks like a Jaxen code change has busted us.
>
>On 4/21/05, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>
>>Test reports can be found at
>>.
>>
>>Stefan
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCdbMAOb5RoQhMkRMRAiY3AKCy3vIhnh55f2T0rKvJFYgihQm66wCguYS4
yh1opY4eDBNO8qv8yX1W1uA=
=5RT6
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

[Dion Gillard]

Cool.

I believe the core could be released almost as is, but some of the
taglibs (e.g. Ant and XML) could do with a good look.

On 5/2/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Already committed. It was solely Hans' patch applied, the rest of the
> fix was inside Maven.
> 
> So, yes, please feel free to roll on with a release :)
> 
> Incidentally, the memory usage to build all 82 plugin sites in a reactor
> was around 50M. Not perfect, but much better.
> 
> Cheers,
> Brett
> 
> Paul Libbrecht wrote:
> 
> > Le 1 mai 05, à 19:36, peter royal a écrit :
> >
> >> On May 1, 2005, at 9:09 AM, Brett Porter wrote:
> >>
> >>> I've solved this problem. One of the jelly tags was relying on a new
> >>> instance being created, but the instance is now being reused. Note that
> >>> the tag is the same call from the same script, so I assume that this is
> >>> valid, so I have made the tag not be stateful and it fixed the Maven
> >>> problem.
> >>> Does anyone know if this is correct behaviour?
> >>
> >> Sounds correct to me :)
> >
> >
> > Yes, this sounds also correct to me...
> > I think the assumption that a new instance of tag-objects be created
> was correct if one would set not to "cache" tags (using the formerly
> available setCacheTags method); this was probably the default.
> > SInce the thread-local fixes, all tags are cached and...
> >
> > I am wondering wether there would be wish to bring back the method
> setCacheTags and actually disable caching in some circumstances. I would
> rather say it's better to keep it out as it makes life-cycle easier to
> write for tags (and one can still clear the contexts).
> >
> > Brett, I'm really looking forward to your commit (which will include
> Hans' patch, then, correct?).
> > From there on we should hunt for 1.0!
> >
> > paul
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.0 (Cygwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCdWypOb5RoQhMkRMRAgy4AKCWERMZ0QEdOMjBzGfqXRm60uHE0wCdGksv
> TGthN9SAAAIM4Uwhbb3CztI=
> =b3Z3
> -END PGP SIGNATURE-
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
http://www.multitask.com.au/people/dion/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

[Brett Porter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Already committed. It was solely Hans' patch applied, the rest of the
fix was inside Maven.

So, yes, please feel free to roll on with a release :)

Incidentally, the memory usage to build all 82 plugin sites in a reactor
was around 50M. Not perfect, but much better.

Cheers,
Brett

Paul Libbrecht wrote:

> Le 1 mai 05, à 19:36, peter royal a écrit :
>
>> On May 1, 2005, at 9:09 AM, Brett Porter wrote:
>>
>>> I've solved this problem. One of the jelly tags was relying on a new
>>> instance being created, but the instance is now being reused. Note that
>>> the tag is the same call from the same script, so I assume that this is
>>> valid, so I have made the tag not be stateful and it fixed the Maven
>>> problem.
>>> Does anyone know if this is correct behaviour?
>>
>> Sounds correct to me :)
>
>
> Yes, this sounds also correct to me...
> I think the assumption that a new instance of tag-objects be created
was correct if one would set not to "cache" tags (using the formerly
available setCacheTags method); this was probably the default.
> SInce the thread-local fixes, all tags are cached and...
>
> I am wondering wether there would be wish to bring back the method
setCacheTags and actually disable caching in some circumstances. I would
rather say it's better to keep it out as it makes life-cycle easier to
write for tags (and one can still clear the contexts).
>
> Brett, I'm really looking forward to your commit (which will include
Hans' patch, then, correct?).
> From there on we should hunt for 1.0!
>
> paul
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCdWypOb5RoQhMkRMRAgy4AKCWERMZ0QEdOMjBzGfqXRm60uHE0wCdGksv
TGthN9SAAAIM4Uwhbb3CztI=
=b3Z3
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JELLY-209) Ant tags do not redirect stderr ou stdout to Ant tag

[Cyrille Le Clerc (JIRA)]

 [ 
http://issues.apache.org/jira/browse/JELLY-209?page=comments#action_64233 ]
 
Cyrille Le Clerc commented on JELLY-209:


Dropping patch a-path-for-JELLY-209-commons-jelly-tags-ant-1.0.jar under 
$MAVEN_HOME/lib worked on windows XP / sun jdk 1.4 but failed on linux rhel3 / 
ibm jdk 1.4.

On linux rhel3 / ibm jdk 1.4, I had to update commons-jelly-tags-ant-1.0.jar 
(overwriting original classes by the ones provided in 
a-patch-for-JELLY-209-commons-jelly-tags-ant-1.0.jar)

> Ant tags do not redirect stderr ou stdout to Ant tag
> 
>
>  Key: JELLY-209
>  URL: http://issues.apache.org/jira/browse/JELLY-209
>  Project: jelly
> Type: Bug
>   Components: taglib.ant
> Versions: 1.0
>  Environment: Sun JDK 1.4.2_07, commons-jelly-1.0-RC1.jar, 
> commons-jelly-tags-ant-1.0.jar
> Reporter: Cyrille Le Clerc
>  Attachments: AntTag.java.diff, 
> a-path-for-JELLY-209-commons-jelly-tags-ant-1.0.jar
>
> Ant tag (org.apache.commons.jelly.tags.ant.AntTag) does not redirect 
> System.out and System.err to the target Ant tag (through the Ant Project). 
> Due to this, System.out and System.err are not handled by Ant tasks (e.g. 
> JunitTask should output in TEST-xxx.xml stdout and stderr).
> Sample of code to redirect stdout and stderr in 
> org.apache.tools.ant.Main#runBuild(ClassLoader), version 1.6.2 :
>   System.setOut(new PrintStream(new DemuxOutputStream(project, false)));
>   System.setErr(new PrintStream(new DemuxOutputStream(project, true)));
> Patch :
> To patch this problem, I modified org.apache.commons.jelly.tags.ant.AntTag to 
> redirect stdout and stderr before calling "task.perform()" and, after the 
> task execution, reset stdout an stderr to their initial values.
> Diff of org.apache.commons.jelly.tags.ant.AntTag
> (It does not seem to be possible to attach files in Jira)
> Index: AntTag.java
> ===
> RCS file: 
> /home/cvspublic/jakarta-commons/jelly/jelly-tags/ant/src/java/org/apache/commons/jelly/tags/ant/AntTag.java,v
> retrieving revision 1.34
> diff -r1.34 AntTag.java
> 18a19
> > import java.io.PrintStream;
> 36a38
> > import org.apache.tools.ant.DemuxOutputStream;
> 185c187,199
> < task.perform();
> ---
> > // according to org.apache.tools.ant.Main, redirect stdout 
> > and stderr
> > PrintStream initialOut = System.out;
> > PrintStream initialErr = System.err;
> > PrintStream newOut = new PrintStream(new 
> > DemuxOutputStream(project, false));
> > PrintStream newErr = new PrintStream(new 
> > DemuxOutputStream(project, true));
> > try{
> > System.setOut(newOut);
> > System.setErr(newErr);
> > task.perform();
> > } finally {
> > System.setOut(initialOut);
> > System.setErr(initialErr);
> > }

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34686] - [collections] TransformedMap putAll(empty map) causes IllegalArgumentException

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34686


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|TransformedMap putAll(empty |[collections] TransformedMap
   |map) causes |putAll(empty map) causes
   |IllegalArgumentException|IllegalArgumentException




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34689] - [collections] Strong reference not really cleared in TestReference*Map testcases

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34689


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Strong reference not really |[collections] Strong
   |cleared in TestReference*Map|reference not really cleared
   |testcases   |in TestReference*Map
   ||testcases




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34690] - [collections] Concurrent modification in FastArrayList

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34690


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Concurrent modification in  |[collections] Concurrent
   |FastArrayList   |modification in
   ||FastArrayList




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r165558 - /jakarta/commons/proper/lang/trunk/xdocs/userguide.xml

[stevencaswell]

Author: stevencaswell
Date: Sun May  1 15:15:46 2005
New Revision: 165558

URL: http://svn.apache.org/viewcvs?rev=165558&view=rev
Log:
added header similar to developer's guide;
added code tags around method call examples

Modified:
jakarta/commons/proper/lang/trunk/xdocs/userguide.xml

Modified: jakarta/commons/proper/lang/trunk/xdocs/userguide.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/xdocs/userguide.xml?rev=165558&r1=165557&r2=165558&view=diff
==
--- jakarta/commons/proper/lang/trunk/xdocs/userguide.xml (original)
+++ jakarta/commons/proper/lang/trunk/xdocs/userguide.xml Sun May  1 15:15:46 
2005
@@ -24,14 +24,34 @@
 
  
 
+  
+
+  The Jakarta Commons Lang Package
+  Users Guide
+$Id$
+  [Description]
+  [lang.*]
+  [lang.builder.*]
+  [lang.enums.*]
+  [lang.exception.*]
+  [lang.math.*]
+  [lang.mutable.*]
+  [lang.time.*]
+  [lang.text.*]
+  
+
+  
+
+  
   
The Commons Lang library provides much needed additions to the standard 
JDK's java.lang package. Very generic, very reusable components for everyday 
use.
The top level package contains various Utils classes, whilst there are 
various subpackages including enums, exception and builder. Using the Utils 
classes is generally simplicity itself. They are the equivalent of global 
functions in another language, a collection of stand-alone, thread-safe, static 
methods. In contrast, subpackages may contain interfaces which may have to be 
implemented or classes which may need to be extended to get the full 
functionality from the code. They may, however, contain more global-like 
functions. 
Lang seeks to support Java 1.2 onwards, so although you may have seen 
features in later versions of Java, such as split methods and nested 
exceptions, Lang still maintains non-java.lang versions for users of earlier 
versions of Java. 
You will find deprecated methods as you stroll through the Lang 
documentation. These are removed in the next major release. 
-   Before we begin, it's a good time to mention the Utils classes. They all 
contain empty public constructors with warnings not to use. This may seem an 
odd thing to do, but it allows tools like Velocity to access the class as if it 
were a bean. In other words, yes we know abbout private constructors. 
+   Before we begin, it's a good time to mention the Utils classes. They all 
contain empty public constructors with warnings not to use. This may seem an 
odd thing to do, but it allows tools like Velocity to access the class as if it 
were a bean. In other words, yes we know about private constructors. 
   
 
+   

 
  Lang has a series of String utilities. The first is StringUtils, 
oodles and oodles of functions which tweak, transform, squeeze and cuddle 
java.lang.Strings. In addition to StringUtils, there are a series of other 
String manipulating classes; RandomStringUtils, StringEscapeUtils and 
Tokenizer. RandomStringUtils speaks for itself. It's provides ways in which to 
generate pieces of text, such as might be used for default passwords. 
StringEscapeUtils contains methods to escape and unescape Java, JavaScript, 
HTML, XML and SQL. Tokenizer is an improved alternative to 
java.util.StringTokenizer. 
@@ -40,12 +60,12 @@
 
 
 
- In addition to dealing with Strings, it's also important to deal with 
chars and Characters. CharUtils exists for this purpose, while CharSetUtils 
exists for set-manipulation of Strings. Be careful, although CharSetUtils takes 
an argument of type String, it is only as a set of characters. For example, 
'CharSetUtils.delete("testtest", "tr")' will remove all t's and all r's from 
the String, not just the String "tr". 
+ In addition to dealing with Strings, it's also important to deal with 
chars and Characters. CharUtils exists for this purpose, while CharSetUtils 
exists for set-manipulation of Strings. Be careful, although CharSetUtils takes 
an argument of type String, it is only as a set of characters. For example, 
CharSetUtils.delete("testtest", "tr") will remove all t's and all 
r's from the String, not just the String "tr". 
  CharRange and CharSet are both used internally by CharSetUtils, and 
will probaby rarely be used. 
 
 
 
- SystemUtils is a simple little class which makes it easy to find out 
information about which platform you are on. For some, this is a necessary 
evil. It was never something I expected to use myself until I was trying to 
ensure that Commons Lang itself compiled under JDK 1.2. Having pushed out a few 
JDK 1.3 bits that had slipped in (Collections.EMPTY_MAP is a classic offender), 
I then found that one of the Unit Tests was dying mysteriously under JDK 1.2, 
but ran fine under JDK 1.3. There was no obvious solution and I needed to move 
onwards, so the simple solution was to wrap that particular test in a 
'

svn commit: r165557 - /jakarta/commons/proper/lang/trunk/xdocs/tasks.xml

[stevencaswell]

Author: stevencaswell
Date: Sun May  1 15:14:55 2005
New Revision: 165557

URL: http://svn.apache.org/viewcvs?rev=165557&view=rev
Log:
removed entry for writing users guide

Modified:
jakarta/commons/proper/lang/trunk/xdocs/tasks.xml

Modified: jakarta/commons/proper/lang/trunk/xdocs/tasks.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/xdocs/tasks.xml?rev=165557&r1=165556&r2=165557&view=diff
==
--- jakarta/commons/proper/lang/trunk/xdocs/tasks.xml (original)
+++ jakarta/commons/proper/lang/trunk/xdocs/tasks.xml Sun May  1 15:14:55 2005
@@ -31,7 +31,6 @@
 
 
 
-Write user guide
 Improve maven script to generate previous version javadoc as per 
collections
 DateRange/Duration class
 CloneUtils - utility class to enable cloning via various different 
mechanisms



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r165556 - /jakarta/commons/proper/lang/trunk/xdocs/developerguide.xml

[stevencaswell]

Author: stevencaswell
Date: Sun May  1 15:14:24 2005
New Revision: 165556

URL: http://svn.apache.org/viewcvs?rev=165556&view=rev
Log:
spelling correction

Modified:
jakarta/commons/proper/lang/trunk/xdocs/developerguide.xml

Modified: jakarta/commons/proper/lang/trunk/xdocs/developerguide.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/xdocs/developerguide.xml?rev=165556&r1=16&r2=165556&view=diff
==
--- jakarta/commons/proper/lang/trunk/xdocs/developerguide.xml (original)
+++ jakarta/commons/proper/lang/trunk/xdocs/developerguide.xml Sun May  1 
15:14:24 2005
@@ -113,7 +113,7 @@
 enclose with 
.
 
 A longer description about what the class/interface/method is used for 
-and if it is needed how it is done. If it is nessesary include 
+and if it is needed how it is done. If it is necessary include 
 description of the parameters, what they are used for and how. Enclose 
 with 
 where it is needed, try to divide into smaller parts 
(not 
 to small!) to enhance readability of the generated Javadoc.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r165555 - /jakarta/commons/proper/lang/trunk/project.xml

[stevencaswell]

Author: stevencaswell
Date: Sun May  1 15:13:34 2005
New Revision: 16

URL: http://svn.apache.org/viewcvs?rev=16&view=rev
Log:
updated version to 2.1-RC4

Modified:
jakarta/commons/proper/lang/trunk/project.xml

Modified: jakarta/commons/proper/lang/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/project.xml?rev=16&r1=165554&r2=16&view=diff
==
--- jakarta/commons/proper/lang/trunk/project.xml (original)
+++ jakarta/commons/proper/lang/trunk/project.xml Sun May  1 15:13:34 2005
@@ -19,7 +19,7 @@
   
   commons-lang
   Lang
-  2.1-RC3
+  2.1-RC4
   2001
   Java Common Components
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r165554 - /jakarta/commons/proper/lang/trunk/default.properties

[stevencaswell]

Author: stevencaswell
Date: Sun May  1 15:13:09 2005
New Revision: 165554

URL: http://svn.apache.org/viewcvs?rev=165554&view=rev
Log:
updated version to 2.1-RC4

Modified:
jakarta/commons/proper/lang/trunk/default.properties

Modified: jakarta/commons/proper/lang/trunk/default.properties
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/default.properties?rev=165554&r1=165553&r2=165554&view=diff
==
--- jakarta/commons/proper/lang/trunk/default.properties (original)
+++ jakarta/commons/proper/lang/trunk/default.properties Sun May  1 15:13:09 
2005
@@ -29,7 +29,7 @@
 component.title = Core Language Utilities
 
 # The current version number of this component
-component.version = 2.1-RC3
+component.version = 2.1-RC4
 
 # The current year used for the end date in copyrights.
 copyright.end = 2005



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[lang] New VOTE on lang release

[Steven Caswell]

Release candidate 4 is in
http://www.apache.org/~stevencaswell/commons-lang-2.1/

RC4 contains only documentation fixes reported on RC3 (thanks to Michael 
Heuer). There is one minor formatting issue that causes extra spaces after 
some anchors, that appears to be a maven formatting issue.

Again, not sure if another vote is necessary, since plenty of +1s have come 
in for the previous RCs, but I don't want to presume anything:

[ ] +1
[ ] -1


-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org

Re: [lang] (RE)VOTE 2.1 Release

[Steven Caswell]

I have fixed all the items noted below with the exception of the extra space 
behind the links. This is some sort of maven issue that I haven't figured 
out yet. I propose we go ahead and release since there is no material 
problem, just a minor formatting issue. I will call a vot in a separate 
thread.

On 4/26/05, Michael Heuer <[EMAIL PROTECTED]> wrote:
> 
> 
> A few minor nits with the web site:
> 
> Links before commas and periods have an extra space, e.g. lang status
> document . and Maven , JDiff , PMD , FindBugs on index.html. I had
> thought that this issue was resolved in an upgrade to maven and/or the
> maven xdoc plugin?
> 
> Update tasks.html, user guide has been written. (it is quite nice, by the
> way)
> 
> Give userguide.html a header similar to that of developerguide.html.
> 
> userguide.html abbout --> about
> 
> userguide.html use CharSetUtils.delete("testtest", "tr")
> instead of 'CharSetUtils.delete("testtest", "tr")' ? What about the other
> methods used in the text, should they be put in  tags as well?
> 
> developerguide.html nessesary --> necessary
> 
> A non-binding +1 from me.
> 
> michael
> 
> 
> On Tue, 26 Apr 2005, Steven Caswell wrote:
> 
> > Release candidate 3 (and hopefully final :) is in
> > http://www.apache.org/~stevencaswell/commons-lang-2.1/
> >
> > The only changes between RC2 and RC3 are documentation clean-up (thanks 
> to
> > Gary for finding some inconsistencies). It would be good if someone 
> could
> > check the compatibility of the distribution with JDK 1.2.
> >
> > I know Stephen asked for a clirr, and I haven't had time to work on 
> that,
> > but I should be able to get it by tomorrow evening (ET).
> >
> > Not sure if another vote is necessary since I don't recall any -1s, but 
> I'll
> > go ahead and propose it and see what shakes out:
> >
> > [ ] +1
> > [ ] -1
> >
> > --
> > Steven Caswell
> > [EMAIL PROTECTED]
> >
> > Take back the web - http://www.mozilla.org
> >
> 
> 


-- 
Steven Caswell
[EMAIL PROTECTED]

Take back the web - http://www.mozilla.org

svn commit: r165541 - /jakarta/commons/proper/lang/tags/LANG_2_1_RC3

[stevencaswell]

Author: stevencaswell
Date: Sun May  1 13:53:43 2005
New Revision: 165541

URL: http://svn.apache.org/viewcvs?rev=165541&view=rev
Log:
Lang release candidate 3

Added:
jakarta/commons/proper/lang/tags/LANG_2_1_RC3/
  - copied from r165540, jakarta/commons/proper/lang/trunk/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [lang] (RE)VOTE 2.1 Release

[Phil Steitz]

Looks good to go +1

Phil

On 4/27/05, Steven Caswell <[EMAIL PROTECTED]> wrote:
> I have posted the clirr report for review:
> http://www.apache.org/~stevencaswell/commons-lang-2.1/clirr-2.0-to-2.1.txt
> 
> -- Forwarded message --
> From: Steven Caswell <[EMAIL PROTECTED]>
> Date: Apr 26, 2005 7:31 AM
> Subject: [lang] (RE)VOTE 2.1 Release
> To: Jakarta Commons Developers List 
> 
> Release candidate 3 (and hopefully final :) is in
> http://www.apache.org/~stevencaswell/commons-lang-2.1/
> 
> The only changes between RC2 and RC3 are documentation clean-up (thanks to
> Gary for finding some inconsistencies). It would be good if someone could
> check the compatibility of the distribution with JDK 1.2.
> 
> I know Stephen asked for a clirr, and I haven't had time to work on that,
> but I should be able to get it by tomorrow evening (ET).
> 
> Not sure if another vote is necessary since I don't recall any -1s, but I'll
> go ahead and propose it and see what shakes out:
> 
> [ ] +1
> [ ] -1
> 
> --
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org
> 
> --
> Steven Caswell
> [EMAIL PROTECTED]
> 
> Take back the web - http://www.mozilla.org
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

[Paul Libbrecht]

Le 1 mai 05, à 19:36, peter royal a écrit :
On May 1, 2005, at 9:09 AM, Brett Porter wrote:
I've solved this problem. One of the jelly tags was relying on a new
instance being created, but the instance is now being reused. Note 
that
the tag is the same call from the same script, so I assume that this 
is
valid, so I have made the tag not be stateful and it fixed the Maven
problem.
Does anyone know if this is correct behaviour?
Sounds correct to me :)
Yes, this sounds also correct to me...
I think the assumption that a new instance of tag-objects be created 
was correct if one would set not to "cache" tags (using the formerly 
available setCacheTags method); this was probably the default.
SInce the thread-local fixes, all tags are cached and...

I am wondering wether there would be wish to bring back the method 
setCacheTags and actually disable caching in some circumstances. I 
would rather say it's better to keep it out as it makes life-cycle 
easier to write for tags (and one can still clear the contexts).

Brett, I'm really looking forward to your commit (which will include 
Hans' patch, then, correct?).
From there on we should hunt for 1.0!

paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] XMLPropertiesConfiguration.load SAX todo

[Alistair Young]

Thanks Emmanuel,
I've attached a modifed XMLPropertiesConfiguration.java.

I've just done the SAX todo. If it's up to scratch, I'd like to implement
the includes todo as well, if that's ok, though I'll ask your opinion of
my idea before doing anything.

cheers,
Alistair


-- 
Alistair Young
Senior Software Engineer
[EMAIL PROTECTED] Mòr Ostaig
Isle of Skye
Scotland

> Hi Alistair, thank you for offering your help, feel free to submit your
> implementation on this list. We will review it and integrate it in the
> code if it works fine. Alternatively you can open an entry in Bugzilla
> and attach your changes there.
>
> Emmanuel Bourg
>
>
> Alistair Young wrote:
>> Hi folks,
>> I wonder if I could possibly submit a todo implementation for
>> org.apache.commons.configuration.XMLPropertiesConfiguration.
>>
>> I was looking at the XML part as we're thinking of using
>> commons-configuration in the Bodington VLE and saw a todo for converting
>> XMLPropertiesConfiguration.load() from Digester to SAX.
>>
>> I'd like to do the "include" todo as well if that's ok as it's a feature
>> we could use for the VLE.
>>
>> Should I send the modified source to the list?
>>
>> cheers,
>>
>> Alistair
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
/*
 * Copyright 2004 The Apache Software Foundation.
 *
 * Licensed under the Apache License, Version 2.0 (the "License")
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.commons.configuration;

import java.io.*;
import java.net.URL;
import java.util.Iterator;
import java.util.List;
import org.apache.commons.lang.StringEscapeUtils;
import org.apache.commons.lang.StringUtils;
import org.xml.sax.*;
import org.xml.sax.helpers.DefaultHandler;
import javax.xml.parsers.SAXParserFactory;
import javax.xml.parsers.SAXParser;

/**
 * This configuration implements the XML properties format introduced in Java
 * 5.0, see http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html.
 * An XML properties file looks like this:
 *
 * 
 * 
 * 
 * 
 *   Description of the property list
 *   value1
 *   value2
 *   value3
 * 
 * 

Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

[peter royal]

On May 1, 2005, at 9:09 AM, Brett Porter wrote:
I've solved this problem. One of the jelly tags was relying on a new
instance being created, but the instance is now being reused. Note  
that
the tag is the same call from the same script, so I assume that  
this is
valid, so I have made the tag not be stateful and it fixed the Maven
problem.

Does anyone know if this is correct behaviour?
Sounds correct to me :)
-pete

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [configuration] XMLPropertiesConfiguration.load SAX todo

[Emmanuel Bourg]

Hi Alistair, thank you for offering your help, feel free to submit your 
implementation on this list. We will review it and integrate it in the 
code if it works fine. Alternatively you can open an entry in Bugzilla 
and attach your changes there.

Emmanuel Bourg
Alistair Young wrote:
Hi folks,
I wonder if I could possibly submit a todo implementation for
org.apache.commons.configuration.XMLPropertiesConfiguration.
I was looking at the XML part as we're thinking of using
commons-configuration in the Bodington VLE and saw a todo for converting
XMLPropertiesConfiguration.load() from Digester to SAX.
I'd like to do the "include" todo as well if that's ok as it's a feature
we could use for the VLE.
Should I send the modified source to the list?
cheers,
Alistair

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r165507 - in /jakarta/commons/proper/jelly/trunk: src/java/org/apache/commons/jelly/JellyContext.java src/java/org/apache/commons/jelly/impl/TagScript.java src/test/org/apache/commons/jelly/core/BaseMemoryLeakTest.java xdocs/changes.xml

[brett]

Author: brett
Date: Sun May  1 07:05:54 2005
New Revision: 165507

URL: http://svn.apache.org/viewcvs?rev=165507&view=rev
Log:
Submitted By:   Hans Glide
Simplify tag caching

Modified:

jakarta/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/JellyContext.java

jakarta/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/impl/TagScript.java

jakarta/commons/proper/jelly/trunk/src/test/org/apache/commons/jelly/core/BaseMemoryLeakTest.java
jakarta/commons/proper/jelly/trunk/xdocs/changes.xml

Modified: 
jakarta/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/JellyContext.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/JellyContext.java?rev=165507&r1=165506&r2=165507&view=diff
==
--- 
jakarta/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/JellyContext.java
 (original)
+++ 
jakarta/commons/proper/jelly/trunk/src/java/org/apache/commons/jelly/JellyContext.java
 Sun May  1 07:05:54 2005
@@ -92,20 +92,6 @@
 /** Should we export tag libraries to our parents context */
 private boolean exportLibraries = true;
 
-/** Maps a Thread to its local Script data cache. It's 
- * like a ThreadLocal, but it reclaims memory better
- * when the JellyCointext goes out of scope.
- * This isn't a ThreadLocal because of the typical usage scenario of
- * JellyContext. ThreadLocal is meant to be sued as a static variable,
- * we were using it as a local variable.
- * [EMAIL PROTECTED] #setThreadLocalScriptData(Script,Object)}
-  */
-private Map threadLocalScriptData = Collections.synchronizedMap(new 
WeakHashMap());
-// THINKME: Script objects are like Object (for equals and hashCode) I 
think.
-//  It should be asy to optimize hash-map distribution, e.g. by
-//  shifting the hashcode return value (presuming Object.hashcode()
-//  is something like an address)
-
 /**
  * Create a new context with the currentURL set to the rootURL
  */
@@ -390,91 +376,18 @@
 return createChildContext();
 }
 
-
-/** Gets the Script data item that may have previously been stored
- * by the script, in this context, for the current thread.
- *  
- * @return the tag associated with the current context and thread
-  */
-public Object getThreadScriptData(Script script) {
-if( script == null )
-return null;
-Tag tag = (Tag) getThreadScriptDataMap().get(script);
-   if( tag == null && getParent() != null) {
-   return getParent().getThreadScriptData(script);
-   } else {
-   return tag;
-   }
-}
-   
-   /** Gets a per-thread (thread local) Map of data for use by
- * Scripts.
- * @return the thread local Map of Script data */
-   public Map getThreadScriptDataMap() {
-Map rv;
-Thread t = Thread.currentThread();
-Map data = (Map) threadLocalScriptData.get(t);
-if (data == null) {
-rv = new HashMap();
-threadLocalScriptData.put(t, rv);
-} else {
-rv = data;
-}
-   return rv;
-   }
-
-/** Stores an object that lasts for the life of this context
- * and is local to the current thread. This method is
- * mainly intended to store Tag instances. However, any
- * Script that wants to cache data can use this
- * method.
-  */
-public void setThreadScriptData(Script script, Object data) {
-getThreadScriptDataMap().put(script,data);
-}
-
-/** Clears variables set by Tags (basically, variables set in a Jelly 
script)
- * and data stored by [EMAIL PROTECTED] Script} instances.
+/** Clears variables set by Tags.
  * @see #clearVariables()
- * @see #clearThreadScriptData()
- * @see #clearScriptData()
   */
 public void clear() {
-clearScriptData();
 clearVariables();
 }
 
 /** Clears variables set by Tags (variables set while running a Jelly 
script)
  * @see #clear()
- * @see #clearThreadScriptData()
- * @see #clearScriptData()
  */
-public void clearVariables() {
+protected void clearVariables() {
 variables.clear();
-}
-
-/** Clears data cached by [EMAIL PROTECTED] Script} instances, 
- * for this context, for the current thread.
- * The data cleared could be cached Tag instances or other data
- * saved by Script classes.
- * @see #clear()
- * @see #clearVariables()
- * @see #clearScriptData()
- */
-public void clearThreadScriptData() {
-getThreadScriptDataMap().clear();
-}
-
-/** Clears data cached by [EMAIL PROTECTED] Script} instances, 
- * for this context, for all threads. 
- * The data cleared could be

[jelly] SOLVED: Maven issue with Hans memory leak patch

[Brett Porter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I've solved this problem. One of the jelly tags was relying on a new
instance being created, but the instance is now being reused. Note that
the tag is the same call from the same script, so I assume that this is
valid, so I have made the tag not be stateful and it fixed the Maven
problem.

Does anyone know if this is correct behaviour?

I am committing his patch. If the behaviour is not correct, I expect it
can easily be rolled back or some additional fix be made.

Cheers,
Brett
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCdNTxOb5RoQhMkRMRAszTAJ44oyjf/s9go6igGYFtUP6wyldzBwCbBV3P
BRSvDFmK2EyqTX/JH+Zfci8=
=LiXC
-END PGP SIGNATURE-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] requirements and static binding

[robert burrell donkin]

On Sat, 2005-04-30 at 00:35 +1200, Simon Kitching wrote:



> Analysis of the effectiveness of static in the demonstration scenarios:
> 
> 1-4: static fails, but that's expected. When using the static approach,
>you simply must deploy the static adaptor and the target library
>via the same classloader. I don't see that this causes any
>conflict with the requirements listed above.

this is the whole point :)

with the compile time static approach you have to deploy the libraries
correctly. that's the same with dynamic classloading. both static and
dynamic approaches work when they are deployed in perfect conditions.
the real question is how many of the difficult conditions are also
covered. static binding (in theory) covers far fewer of the possible
imperfect permutations than dynamic binding could. given an impl jar, it
would be possible for dynamic binding to (in theory) cover every case
with conventional context classloaders which static binding can and some
that static binding cannot.

it's all a big circle but hopefully now after this long journey, things
can be seen more clearly. we have reached again the original point of
departure and disagreement: does having to change your deployment in
some cases (by adding log4j to the classloader containing the JCL
implementation) count as a fatal flaw or is it simply a pragmatic way of
dealing with a difficult corner case?

i like static binding. it's clean and easier to understand than dynamic.
for child-first classloaders, the deployment configurations required are
much easier. but in a parent-first environment, difficult configurations
are required to allow static binding to vary on a per application basis
in a container. each approach has different strengths and weaknesses. 

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] tech.xml - child-first classloading not considered harmful

[robert burrell donkin]

On Fri, 2005-04-29 at 23:02 +1200, Simon Kitching wrote:
> Hi All,
> 
> The following paragraph is from the "xdocs/tech.xml" document:
> 
> 
> Parent-first loading has been the standard mechanism in the JDK
> class loader, at least since Java 1.2 introduced hierarchical
> classloaders.
> 
> The primary reason for this is safety -- parent-first
> makes it impossible for malicious code to trick the JVM into
> replacing a core class (say, java.security.SecurityManager)
> with a class of the same name loaded from a child classloader.
> 
> 
> I believe this to be incorrect. I don't believe that such substitution
> leads to any kind of security issue at all, and think this paragraph
> should be removed from the document.
> 
> Can anyone show any real security issues resulting from child-first
> loading?

i would suggest that the operative word here is real. it is very
possible for sun to have chosen to recommend parent-first as the default
for the reason given whilst at the same time the threat not being
particularly credible in real life. 

a malicious classloader could perform all manner of nasty tricks. in
this case, it doesn't really matter whether this classloader pretends to
be parent or child first. not sure how credible a threat this is. not
sure how an attacker could manage to insert a malicious classloader.
(maybe other people with more knowledge would like to jump in here...)

consider (instead) a badly written classloader. the threat to the system
from a badly written parent-first classloader is much less than that
from a badly written child-first classloader. bugs in the selection of
which classes must be delegated (for security reasons) may allow
malicious code to replace crucial security classes.  

whether this is a credible threat in real life is another matter.
opinions?

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed

[commons-jelly-tags-xml development]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-xml has an issue affecting its community integration.
This issue affects 12 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define :  Commons Jelly
- commons-jelly-tags-html :  Commons Jelly
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jaxme :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jface :  Commons Jelly
- commons-jelly-tags-jsl :  Commons Jelly
- commons-jelly-tags-swing :  Commons Jelly
- commons-jelly-tags-xml :  Commons Jelly
- commons-jelly-tags-xmlunit :  Commons Jelly
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools


Full details are available at:

http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-xml-01052005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html
Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-01052005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-01052005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-01052005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-01052005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-01052005.jar
-
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:compile:
[echo] Compiling to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes
[echo] 
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==
  
[javac] Compiling 16 source files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports

test:test-resources:
Copying 36 files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes

test:compile:
[javac] Compiling 4 source files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes

test:test:
[junit] Running org.apache.commons.jelly.tags.xml.TestImport
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.993 sec
[junit] Running org.apache.commons.jelly.tags.xml.TestJelly
[junit] some text
[junit] exists = true, readable = true, class=java.io.File
[junit] 
[junit]   Tests run: 15, Failures: 0, Errors: 13, Time elapsed: 0.562 sec
[junit] [ERROR] TEST org.apache.commons.jelly.tags.xml.TestJelly FAILED
[junit] Running org.apache.commons.jelly.tags.xml.TestParser
[junit] 

svn commit: r165467 - /jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/ExtendedBaseRules.java

[skitching]

Author: skitching
Date: Sun May  1 00:12:05 2005
New Revision: 165467

URL: http://svn.apache.org/viewcvs?rev=165467&view=rev
Log:
Javadoc changes only: modified to improve readability.

Modified:

jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/ExtendedBaseRules.java

Modified: 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/ExtendedBaseRules.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/ExtendedBaseRules.java?rev=165467&r1=165466&r2=165467&view=diff
==
--- 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/ExtendedBaseRules.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/java/org/apache/commons/digester/ExtendedBaseRules.java
 Sun May  1 00:12:05 2005
@@ -39,69 +39,100 @@
  *
  * When should you use this rather than the original?
  *
- * These rules are complex and slower but offer more functionality.
- * The RulesBase matching set allows interaction between patterns.
- * This allows sophisticated matching schema to be created
- * but it also means that it can be hard to create and debug mappings
- * for complex schema.
- * This extension introduces universal versions of these patterns
- * that always act independently.
- *
- * Another three kinds of matching pattern are also introduced.
- * The parent matchs allow common method to be easily called for children.
- * The wildcard match allows rules to be specified for all elements.
+ * 
+ * This pattern-matching engine is complex and slower than the basic
+ * default RulesBase class, but offers more functionality:
+ * 
+ * Universal patterns allow patterns to be specified which will match
+ *  regardless of whether there are "better matching" patterns available.
+ * Parent-match patterns (eg "a/b/?") allow matching for all direct
+ *  children of a specified element.
+ * Ancestor-match patterns (eg "a/b/*") allow matching all elements
+ *  nested within a specified element to any nesting depth.
+ * Completely-wild patterns ("*" or "!*") allow matching all elements.
+ * 
+ * 
+ *
+ * Universal Match Patterns
+ * 
+ * The default RulesBase pattern-matching engine always attempts to find
+ * the "best matching pattern", and will ignore rules associated with other
+ * patterns that match but are not "as good". As an example, if the pattern
+ * "a/b/c" is associated with rules 1 and 2, and "*/c" is associated with
+ * rules 3 and 4 then element "a/b/c" will cause only rules 1 and 2 to execute.
+ * Rules 3 and 4 do have matching patterns, but because the patterns are 
shorter
+ * and include wildcard characters they are regarded as being "not as good" as
+ * a direct match. In general, exact patterns are better than wildcard 
patterns,
+ * and among multiple patterns with wildcards, the longest is preferred.
+ * See the RulesBase class for more information.
+ *
+ * This feature of preferring "better" patterns can be a powerful tool.
+ * However it also means that patterns can interact in unexpected ways.
+ *
+ * When using the ExtendedBaseRules, any pattern prefixed with '!' bypasses 
+ * the "best match" feature. Even if there is an exact match or a longer 
+ * wildcard match, patterns prefixed by '!' will still be tested to see if 
+ * they match, and if so their associated Rule objects will be included in
+ * the set of rules to be executed in the normal manner.
+ *
+ * 
+ * Pattern "!*/a/b" matches whenever an 'b' element
+ * is inside an 'a'.
+ * Pattern "!a/b/?" matches any child of a parent
+ * matching "a/b" (see "Parent Match Patterns").
+ * Pattern "!*/a/b/?" matches any child of a parent
+ * matching "!*/a/b" (see "Parent Match Patterns").
+ * Pattern "!a/b/*" matches any element whose path
+ * starts with "a" then "b" (see "Ancestor Match Patterns").
+ * Pattern "!*/a/b/*" matches any elements whose path
+ * contains 'a/b' (see "Ancestor Match Patterns").
+ * 
+ *
+ * Parent Match Patterns
  *
- * The additional matching patterns:
+ * 
+ * These will match direct child elements of a particular parent element.
+ * 
+ * 
+ *  "a/b/c/?" matches any child whose parent matches
+ *  "a/b/c".  Exact parent rules take precedence over Ancestor
+ *  Match patterns.
+ * 
+ * 
+ *  "*/a/b/c/?" matches any child whose parent matches
+ *  "*/a/b/c".  The longest matching still applies to parent
+ *  matches but the length excludes the '?', which effectively means
+ *  that standard wildcard matches with the same level of depth are
+ *  chosen in preference.
+ * 
+ * 
+ * 
+ *
+ * Ancestor Match Patterns
  *
+ * 
+ * These will match elements whose parentage includes a particular sequence
+ * of elements.
  * 
- * Parent Match  - Will match child elements of a particular
- * kind of parent.  This is useful if a parent has a particular method
- * to call.
- * 
- * "a/b/c/?" matches any ch