Re: common-dbcp release version planning consultation
Yes, once we release Commons Pool 2.12.0, which might be within a month or two, not 100% sure yet. Are you looking for a specific fix? Gary On Tue, Aug 15, 2023, 9:50 AM 1309446202 <1309446...@qq.com.invalid> wrote: > Hi, no new version of common-dbcp sofeware has been released for two > years. Are there any plans to release a new version?
Re: [jira] [Deleted] (LANG-1647) Add and ExceptionUtils.isChecked() and isUnchecked()
Because it doubles up the work form the original ticket. We do not need a second ticket to track the same new feature IMO. Gary On Tue, Jul 4, 2023, 12:57 sebb wrote: > Why did you delete this ticket? > > It is referred to in various emails and commit messages, so it is > confusing that the ticket does not exist. > > I think only tickets which are spam should be deleted. > > Sebb > > On Mon, 3 Jul 2023 at 12:04, Gary D. Gregory (Jira) > wrote: > > > > > > [ > https://issues.apache.org/jira/browse/LANG-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > > > Gary D. Gregory deleted LANG-1647: > > -- > > > > > > > Add and ExceptionUtils.isChecked() and isUnchecked() > > > > > > > > > Key: LANG-1647 > > > URL: https://issues.apache.org/jira/browse/LANG-1647 > > > Project: Commons Lang > > > Issue Type: Improvement > > >Reporter: Arturo Bernal > > >Priority: Minor > > > Time Spent: 3.5h > > > Remaining Estimate: 0h > > > > > > The idea it's have a function that check if a given throwable is a > checked exception. There are some similar function in ConcurrentUtils, but > have package visibility and return the same exception. > > > Seem logic have this verification in the class that have this > responsibility - ExceptionUtils > > > > > > > > -- > > This message was sent by Atlassian Jira > > (v8.20.10#820010) >
Re: [jira] [Commented] (LANG-1627) BooleanUtils.xor not behaving as expected with any odd number of true's
PRs are welcome :-)
Gary
On Wed, May 4, 2022, 08:09 Steve Bosman wrote:
> I've started working somewhere where I can work on opensource during
> downtime. I can see this has been open a while and I'm happy to pick it up.
> I'm thinking one PR with some javadoc clarifications to the original method
> for three or more booleans, and if still wanted another PR with the
> requested function.
>
> Would that be okay?
>
> Steve
>
> On Tue, 29 Dec 2020, 19:34 Alberto Scotto (Jira), wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/LANG-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256142#comment-17256142
> > ]
> >
> > Alberto Scotto commented on LANG-1627:
> > --
> >
> > {quote}[https://en.wikipedia.org/wiki/XOR_gate#More_than_two_inputs]
> > {quote}
> > Interesting! So there exists one such boolean function which works as I
> > expect.
> >
> > BTW, my use case is the following:
> >
> > I have a web service which accepts a request with a number of fields, say
> > 3, with the constraint that exactly one among the 3 fields must be not
> null.
> >
> > I think it's a pretty common scenario, so it would make sense to add this
> > other semantic of xor to BooleanUtils. We may call it xorOneHot. I would
> be
> > keen on keeping "xor" in the name so that users can find it when using
> > autocompletion and are looking for "xor".
> >
> > I'm working on an implementation already. Just shout if you'd like me to
> > submit a PR.
> >
> > > BooleanUtils.xor not behaving as expected with any odd number of true's
> > > ---
> > >
> > > Key: LANG-1627
> > > URL: https://issues.apache.org/jira/browse/LANG-1627
> > > Project: Commons Lang
> > > Issue Type: Bug
> > >Affects Versions: 3.11
> > >Reporter: Alberto Scotto
> > >Priority: Major
> > >
> > > Hi,
> > > I was expecting a xor function that takes a variable number of
> arguments
> > to *return true if and only if exactly one among all of the arguments is
> > true*, regardless of the number of arguments.
> > > This holds true given three false's:
> > > {code:java}
> > > @Test
> > > public void threeFalse() {
> > > boolean[] bools = new boolean[]{Boolean.FALSE, Boolean.FALSE,
> > Boolean.FALSE};
> > > assertFalse(BooleanUtils.xor(bools));
> > > }{code}
> > >
> > > It also holds true given 4 true's, as well as for any even number of
> > trues.
> > > {code:java}
> > > @Test
> > > public void fourTrue() {
> > > boolean[] bools = new boolean[]{Boolean.TRUE, Boolean.TRUE,
> > Boolean.TRUE, Boolean.TRUE};
> > > assertFalse(BooleanUtils.xor(bools));
> > > }
> > > {code}
> > > The above tests pass.
> > > But with any odd number of true's that doesn't hold anymore:
> > >
> > > {code:java}
> > > @Test
> > > public void threeTrue() {
> > > boolean[] bools = new boolean[]{Boolean.TRUE, Boolean.TRUE,
> > Boolean.TRUE};
> > > assertFalse(BooleanUtils.xor(bools));
> > > }
> > > {code}
> > > This test fails.
> > > That was totally unexpected to me.
> > > But as it turns out, even
> > > {noformat}
> > > true ^ true ^ true{noformat}
> > > evaluates to true. That was unexpected too to me, at a first sight.
> > > The thing is that xor (I mean the original boolean operator) is a
> binary
> > operator, so if you want to make it n-ary, one simple solution is to
> apply
> > it in two by two: ((a ^ b) ^ c) ^ d
> > > And that's what is done in the implementation of the method
> > BooleanUtils#xor.
> > > But that brings to BooleanUtils.xor(true, true, true) == true, and at
> > the same time BooleanUtils.xor(true, true, true, true) == false, which
> just
> > doesn't sound right to me.
> > > Whether or not you agree with me that that is a bug of the method,
> > please at least update the Javadoc, because right now it is not providing
> > the user enough information. Look:
> > > {code:java}
> > > Performs an xor on a set of booleans.
> > > BooleanUtils.xor(true, true) = false
> > > BooleanUtils.xor(false, false) = false
> > > BooleanUtils.xor(true, false) = true
> > > {code}
> > >
> > > Thanks.
> > > Cheers
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.3.4#803005)
> >
>
Re: [jira] [Work logged] (LANG-1644) Check if number is hexadecimal
@arturobernalg
If you are looking to help this component, may I suggest my email "[lang]
Failing test on Java 16-EA."
Gary
On Wed, Mar 3, 2021, 12:52 ASF GitHub Bot (Jira) wrote:
>
> [
> https://issues.apache.org/jira/browse/LANG-1644?focusedWorklogId=560570=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-560570
> ]
>
> ASF GitHub Bot logged work on LANG-1644:
>
>
> Author: ASF GitHub Bot
> Created on: 03/Mar/21 17:51
> Start Date: 03/Mar/21 17:51
> Worklog Time Spent: 10m
> Work Description: arturobernalg opened a new pull request #727:
> URL: https://github.com/apache/commons-lang/pull/727
>
>
>Checks whether the given String is a hex number.
>
> * NumberUtils.isHexNumber(null)) = false
> * NumberUtils.isHexNumber("")) = false
> * NumberUtils.isHexNumber("0x12345678")) = true
> * NumberUtils.isHexNumber("0x7fff")) = true
> * NumberUtils.isHexNumber("0x7FFF")) = true
> * NumberUtils.isHexNumber("5D0"))= true
> * NumberUtils.isHexNumber("0x")) = false
>
>
>
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> Issue Time Tracking
> ---
>
> Worklog Id: (was: 560570)
> Remaining Estimate: 0h
> Time Spent: 10m
>
> > Check if number is hexadecimal
> > --
> >
> > Key: LANG-1644
> > URL: https://issues.apache.org/jira/browse/LANG-1644
> > Project: Commons Lang
> > Issue Type: Improvement
> >Reporter: Arturo Bernal
> >Priority: Minor
> > Time Spent: 10m
> > Remaining Estimate: 0h
> >
> > IMO would be fine have a method that given a String tell you if is a
> valid hexadecimal number instead of try to create the number. should be
> valid:
> >
> > * 5D0
> > * 0x7FFF
> >
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.3.4#803005)
>
Re: [GitHub] [commons-lang] aherbert commented on pull request #727: LANG-1644 - Check if number is hexadecimal
I am not convinced this belong in Lang. Maybe in a Math module? Maybe in Text? Gary On Wed, Mar 3, 2021, 19:29 GitBox wrote: > > aherbert commented on pull request #727: > URL: > https://github.com/apache/commons-lang/pull/727#issuecomment-790185530 > > >Is the intention that this should match `isCreateable(String)` for all > valid hex numbers and return `true` for all hex cases where a `Number` is > returned from `createNumber(String)`? >```java >public static boolean isCreatable(final String str) >public static Number createNumber(final String str) >``` >If so then you should support the `#` character (and all the other hex > prefixes) and update the javadoc to reflect the intention. > >I would then update the test to use all the hex cases from the tests > for `createNumber` and `isCreateable` to ensure it returns `true` when > those methods succeed. > >Currently your test only covers a range of `int` and `long` values, no > hex variants and does not specify whether BigInteger values are also `true`. > >It will also fail on valid hex numbers such as `0x1L`. > > > > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > >
Re: [GitHub] [commons-beanutils] XenoAmess commented on pull request #80: Rename beanutils2 package to beanutils to be a drop-in replacement for beanutils 1.9.4
Change the GID and AID would be best for your own release to avoid ANY confusion. Gary On Wed, Mar 3, 2021, 10:28 GitBox wrote: > > XenoAmess commented on pull request #80: > URL: > https://github.com/apache/commons-beanutils/pull/80#issuecomment-789798150 > > >I suggest you fork and release on your host... > >Just changing group ID will be fine... > >After all this is apache2 license, right... > >And ossrh is free.. > > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > >
Re: [GitHub] [commons-lang] aakashgupta96 commented on a change in pull request #645: [LANG-1614] - Split fixed-length elements
I think we need to think about defining what kind of boundary we want
between Commons Lang and Commons Text before StringUtils becomes even more
of a kitchen sink.
Gary
On Fri, Nov 20, 2020, 08:20 GitBox wrote:
>
> aakashgupta96 commented on a change in pull request #645:
> URL: https://github.com/apache/commons-lang/pull/645#discussion_r527685407
>
>
>
> ##
> File path: src/main/java/org/apache/commons/lang3/StringUtils.java
> ##
> @@ -7731,6 +7731,48 @@ public static String rotate(final String str, final
> int shift) {
> return substrings.toArray(ArrayUtils.EMPTY_STRING_ARRAY);
> }
>
> +/**
> + * Split a {@link String} into a {@code String []} of fixed-length
> elements.
> + *
> + *
> + * StringUtils.splitEvery("test1",10) = ["test1"]
> + * StringUtils.splitEvery("test2", 4) = ["test","2"]
> + * StringUtils.splitEvery("testAbgTestsABG", -2) =
> ["testAbgTestsABG"]
> + * StringUtils.splitEvery("",10) = [""]
> + * StringUtils.splitEvery(null,4) = {@code null}
> + * StringUtils.splitEvery("testAbgTestsABG",2)=
> ["te","st","Ab","gT","es","ts","AB","G"]
> + *
> + *
> + * @param str {@link String} to split into fixed length elements.
> + * @param length length of the elements into which the String will be
> divided.
> + * @return a {@code String []} of fixed-length elements.
> + */
> +public static String[] splitEvery( final String str, final int length
> ) {
>
> Review comment:
>I think it'll be better to throw `IllegalArgumentException` in case
> `length <1 || length > str.length()`. @arturobernalg Thoughts?
>
>
>
>
>
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>
[jira] [Commented] (IO-686) IOUtils.toByteArray(InputStream) Javadoc does not match code
[
https://issues.apache.org/jira/browse/IO-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193855#comment-17193855
]
Gary Gregory commented on IO-686:
-
In general, we make the Javadoc match the code, as the code evolves.
In this case, that method's Javadoc got out of sync with code. The
method is now used from other call sites where the expected result is
an empty byte array.
Gary
> IOUtils.toByteArray(InputStream) Javadoc does not match code
>
>
> Key: IO-686
> URL: https://issues.apache.org/jira/browse/IO-686
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Alan Moffat
>Priority: Critical
> Fix For: 2.9.0
>
>
> According to the code in the v2.8.0 release, passing null to the method
> should throw an exception, however it is producing an empty byte array
> instead.
> {code:java}
> /**
> * Gets the contents of an InputStream as a byte[].
> *
> * This method buffers the input internally, so there is no need to use a
> * BufferedInputStream.
> *
> *
> * @param input the InputStream to read from
> * @return the requested byte array
> * @throws NullPointerException if the input is null
> * @throws IOException if an I/O error occurs
> */
> public static byte[] toByteArray(final InputStream input) throws IOException {
> try (final ByteArrayOutputStream output = new ByteArrayOutputStream()) {
> copy(input, output);
> return output.toByteArray();
> }
> } {code}
> This can be recreated by the following:
> {code:java}
> @Test
> public void shouldThrowNullPointerException() {
> assertThrows(NullPointerException.class, () ->
> IOUtils.toByteArray((InputStream) null))
> } {code}
> On v2.7 the test passes, on v2.8.0 it fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [GitHub] [commons-collections] kinow commented on pull request #173: Bump actions/checkout from v2.3.1 to v2.3.2
HI All and Alex: This Collections commit *bbee9fbd9b7d4a392ea2a43e8413065195d1823a *[1] should have been -1 since it uses a Java 9 API which is now detected by our build: https://github.com/apache/commons-collections/runs/966117890?check_suite_focus=true Alex: Would mind updating the test to Java 8? Thank you, Gary [1] commit bbee9fbd9b7d4a392ea2a43e8413065195d1823a Author: Alex Herbert 2020-03-18 06:49:15 Committer: Alex Herbert 2020-03-18 06:49:15 Parent: 0feeab0820ff7d01681dab897a0d428eca3de3df (Change Hasher.getBits() to iterator()) Child: 514c2eddfcfe99f114b14e5db510af9f6daead51 (add a testcase for DynamicHasher.NoValuesIterator.nextInt()) Branches: master, origin/dependabot/maven/com.puppycrawl.tools-checkstyle-8.34, origin/dependabot/maven/org.apache.commons-commons-parent-51, origin/dependabot/maven/org.apache.commons-commons-parent-52, origin/dependabot/maven/org.apache.maven.plugins-maven-antrun-plugin-3.0.0, origin/dependabot/maven/org.apache.maven.plugins-maven-pmd-plugin-3.13.0, origin/HEAD, origin/master On Mon, Aug 10, 2020 at 5:49 AM GitBox wrote: > > kinow commented on pull request #173: > URL: > https://github.com/apache/commons-collections/pull/173#issuecomment-671261706 > > >Failures here don't appear related to this change. Looks like the build > is already broken on `master` > > > > This is an automated message from the Apache Git Service. > To respond to the message, please log on to GitHub and use the > URL above to go to the specific comment. > > For queries about this service, please contact Infrastructure at: > us...@infra.apache.org > > >
Re: [GitHub] [commons-codec] aherbert commented on a change in pull request #35: [CODEC-280] Added strict decoding property to BaseNCodec.
On Sat, Jan 25, 2020 at 6:12 PM GitBox wrote:
> aherbert commented on a change in pull request #35: [CODEC-280] Added
> strict decoding property to BaseNCodec.
> URL: https://github.com/apache/commons-codec/pull/35#discussion_r370961690
>
>
>
> ##
> File path: src/test/java/org/apache/commons/codec/net/BCodecTest.java
> ##
> @@ -157,6 +158,7 @@ public void testDecodeObjects() throws Exception {
> }
>
> @Test
> +@Ignore("CODEC-280: Disabled strict decoding by default. The BCodec
> uses the default so this test does not fail the impossible cases.")
>
> Review comment:
>Hi @garydgregory
>
>I received an email from github with another comment from you but
> cannot find it through the web interface so I'll repeat for clarity the
> comment was "I'm all for making Base32 and Base64 carry the same option."
>
>This PR already has the public setStrictDecoding(boolean) for Base32
> and Base64. The unresolved is whether the property should be added to
> BCodec as well. At the moment this test is ignored because BCodec cannot be
> made strict. So either:
>
>1. Drop the test and BCodec is always lenient
>2. Make BCodec always strict (this test will pass)
>3. Make BCodec have configurable strict/lenient decoding
>
>My option would be number 3.
>
I'm fine with that.
Will you do that within the same PR?
Gary
>
>
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>
[jira] [Created] (POOL-380) Deprecate PoolUtils.prefill(KeyedObjectPool, Collection, int) in favor of KeyedObjectPool.addObjects(Collection, int).
Gary Gregory created POOL-380:
-
Summary: Deprecate PoolUtils.prefill(KeyedObjectPool, Collection,
int) in favor of KeyedObjectPool.addObjects(Collection, int).
Key: POOL-380
URL: https://issues.apache.org/jira/browse/POOL-380
Project: Commons Pool
Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory
Deprecate {{PoolUtils.prefill(KeyedObjectPool, Collection, int)}} in favor of
{{KeyedObjectPool.addObjects(Collection, int)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (POOL-356) deadlock if borrowObject gets called to fast and maxIdle is 0
[
https://issues.apache.org/jira/browse/POOL-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16938031#comment-16938031
]
Gary Gregory commented on POOL-356:
---
[~psteitz]
Please update {{changes.xml}}.
> deadlock if borrowObject gets called to fast and maxIdle is 0
> -
>
> Key: POOL-356
> URL: https://issues.apache.org/jira/browse/POOL-356
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.6.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I figured this while creating a unit test for OpenJPA. But also did see this
> in real production with commons-dbcp2. See DBCP-513 for more info.
> See this comment for a precise explanation what happens
> https://issues.apache.org/jira/browse/DBCP-513?focusedCommentId=16660545=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16660545
> The problem is basically that the logic to immediately destroy a pool object
> does not notify the DeLinkedQueue:
> {code}
> if (isClosed() || maxIdleSave > -1 && maxIdleSave <=
> idleObjects.size()) {
> try {
> destroy(p);
> {code}
> But the borrowObject code is locking on that condition...
> {code}
> if (borrowMaxWaitMillis < 0) {
> p = idleObjects.takeFirst();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COLLECTIONS-728) BloomFilter contribution
[ https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated COLLECTIONS-728: - External issue ID: 83 External issue URL: https://github.com/apache/commons-collections/pull/83 > BloomFilter contribution > > > Key: COLLECTIONS-728 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-728 > Project: Commons Collections > Issue Type: Task >Reporter: Claude Warren >Priority: Minor > > Contribution of BloomFilter library comprising base implementation and gated > collections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (COLLECTIONS-679) MultiValuedMap JavaDoc Typo
[ https://issues.apache.org/jira/browse/COLLECTIONS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reopened COLLECTIONS-679: -- > MultiValuedMap JavaDoc Typo > --- > > Key: COLLECTIONS-679 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-679 > Project: Commons Collections > Issue Type: Bug >Reporter: David Mollitor >Priority: Trivial > Fix For: 4.5 > > Time Spent: 20m > Remaining Estimate: 0h > > https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35 > The example code provided refers to a class called _MultiValuedHashMap_. > There is no such class in Commons Collection4. Perhaps > _ArrayListValuedHashMap_ is a better example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (COLLECTIONS-679) MultiValuedMap JavaDoc Typo
[ https://issues.apache.org/jira/browse/COLLECTIONS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved COLLECTIONS-679. -- Resolution: Fixed In git master. Please verify and close. > MultiValuedMap JavaDoc Typo > --- > > Key: COLLECTIONS-679 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-679 > Project: Commons Collections > Issue Type: Bug >Reporter: David Mollitor >Priority: Trivial > Fix For: 4.5 > > Time Spent: 20m > Remaining Estimate: 0h > > https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35 > The example code provided refers to a class called _MultiValuedHashMap_. > There is no such class in Commons Collection4. Perhaps > _ArrayListValuedHashMap_ is a better example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (LANG-1426) JavaDoc issue on StringUtils.truncate
[
https://issues.apache.org/jira/browse/LANG-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LANG-1426.
Fix Version/s: 3.10
Resolution: Fixed
In git master. Please verify and close.
> JavaDoc issue on StringUtils.truncate
> -
>
> Key: LANG-1426
> URL: https://issues.apache.org/jira/browse/LANG-1426
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Jeff
>Priority: Trivial
> Fix For: 3.10
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Two of the examples on the method StringUtils.truncate(String, int, int) are
> incorrect:
> * StringUtils.truncate("abcdefghijklmno", Integer.MIN_VALUE, 10) =
> "abcdefghij"
> * StringUtils.truncate("abcdefghijklmno", Integer.MIN_VALUE,
> Integer.MAX_VALUE) = "abcdefghijklmno"
> Both of the above actually throw IllegalArgumentException's.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (COLLECTIONS-679) MultiValuedMap JavaDoc Typo
[ https://issues.apache.org/jira/browse/COLLECTIONS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed COLLECTIONS-679. Fix Version/s: 4.5 Resolution: Fixed In git master. > MultiValuedMap JavaDoc Typo > --- > > Key: COLLECTIONS-679 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-679 > Project: Commons Collections > Issue Type: Bug >Reporter: David Mollitor >Priority: Trivial > Fix For: 4.5 > > Time Spent: 20m > Remaining Estimate: 0h > > https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35 > The example code provided refers to a class called _MultiValuedHashMap_. > There is no such class in Commons Collection4. Perhaps > _ArrayListValuedHashMap_ is a better example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (BCEL-291) Verifier rejects invokevirtual on array: org.apache.bcel.generic.ClassGenException: [Ljava/lang/Object; does not represent an ObjectType
[
https://issues.apache.org/jira/browse/BCEL-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated BCEL-291:
--
Fix Version/s: (was: 6.4.0)
6.4.1
> Verifier rejects invokevirtual on array:
> org.apache.bcel.generic.ClassGenException: [Ljava/lang/Object; does not
> represent an ObjectType
>
>
> Key: BCEL-291
> URL: https://issues.apache.org/jira/browse/BCEL-291
> Project: Commons BCEL
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Peter Burka
>Priority: Major
> Fix For: 6.4.1
>
>
> If a Java program invokes a java.lang.Object method on a variable whose
> static type is an array, the methodref associated with the invokevirtual will
> refer to an array class.
> When the BCEL verifier encounters such a class, it fails with a
> ClassGenException.
> Test case:
> {noformat}
> public class Bug1 {
> public static Object[] bug(Object[] arg) {
> return arg.clone();
> }
> }
> {noformat}
> Outoput:
> {noformat}
> JustIce by Enver Haase, (C) 2001-2002.
> <http://bcel.sourceforge.net>
> <http://commons.apache.org/bcel>
> Now verifying: Bug1
> Pass 1:
> VERIFIED_OK
> Passed verification.
> Pass 2:
> VERIFIED_OK
> Passed verification.
> Pass 3a, method number 0 ['public void ()']:
> VERIFIED_OK
> Passed verification.
> Pass 3b, method number 0 ['public void ()']:
> VERIFIED_OK
> Passed verification.
> Exception in thread "main" org.apache.bcel.generic.ClassGenException:
> [Ljava/lang/Object; does not represent an ObjectType
> at
> org.apache.bcel.generic.FieldOrMethod.getLoadClassType(FieldOrMethod.java:137)
> at
> org.apache.bcel.verifier.statics.Pass3aVerifier$InstOperandConstraintVisitor.visitLoadClass(Pass3aVerifier.java:521)
> at org.apache.bcel.generic.INVOKEVIRTUAL.accept(INVOKEVIRTUAL.java:85)
> at
> org.apache.bcel.generic.InstructionHandle.accept(InstructionHandle.java:302)
> at
> org.apache.bcel.verifier.statics.Pass3aVerifier.pass3StaticInstructionOperandsChecks(Pass3aVerifier.java:443)
> at
> org.apache.bcel.verifier.statics.Pass3aVerifier.do_verify(Pass3aVerifier.java:208)
> at org.apache.bcel.verifier.PassVerifier.verify(PassVerifier.java:71)
> at org.apache.bcel.verifier.Verifier.doPass3a(Verifier.java:89)
> at org.apache.bcel.verifier.Verifier.main(Verifier.java:216)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-714) PatriciaTrie ignores trailing null characters in keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933426#comment-16933426
]
Gary Gregory commented on COLLECTIONS-714:
--
The current PR fails:
{noformat}
[ERROR] Failures:
[ERROR] PatriciaTrieTest.testNullTerminatedKey1:440 expected:<3> but was:<2>
[ERROR] PatriciaTrieTest.testNullTerminatedKey2:451
[INFO]
[ERROR] Tests run: 24948, Failures: 2, Errors: 0, Skipped: 0
{noformat}
> PatriciaTrie ignores trailing null characters in keys
> -
>
> Key: COLLECTIONS-714
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-714
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
>Affects Versions: 4.3
>Reporter: Rohan Padhye
>Priority: Critical
>
> In Java, strings are not null terminated. The string "x" (of length = 1 char)
> is different from the string "x\u" (of length = 2 chars). However,
> PatriciaTrie does not seem to distinguish between these strings.
> To reproduce:
> {code:java}
> public void testNullTerminatedKey1() {
> Map map = new HashMap<>();
> map.put("x", 0); // key of length 1
> map.put("x\u", 1); // key of length 2
> map.put("x\uy", 2); // key of length 3
> Assert.assertEquals(3, map.size()); // ok, 3 distinct keys
> PatriciaTrie trie = new PatriciaTrie<>(map);
> Assert.assertEquals(3, trie.size()); // fail; actual=2
> }{code}
> In the above example, the resulting trie has only two keys: "x\u" and
> "x\uy". The key "x" gets overwritten. Here is another way to repro the
> bug:
> {code:java}
> public void testNullTerminatedKey2() {
> PatriciaTrie trie = new PatriciaTrie<>();
> trie.put("x", 0);
> Assert.assertTrue(trie.containsKey("x")); // ok
> trie.put("x\u", 1);
> Assert.assertTrue(trie.containsKey("x")); // fail
> }
> {code}
> In the above example, the key "x" suddenly disappears when an entry with key
> "x\u" is inserted.
> The PatriciaTrie docs do not mention anything about null-terminated strings.
> In general, I believe this also breaks the JDK Map contract since the keys
> "x".equals("x\u") is false.
> This bug was found automatically using JQF:
> [https://github.com/rohanpadhye/jqf].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933239#comment-16933239
]
Gary Gregory commented on COMPRESS-494:
---
Oops that's my fault. I meant to say "*Affects Version/s:"*
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.8, 1.18
>Reporter: Anvesh Mora
>Priority: Critical
> Fix For: 1.8, 1.18
>
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932525#comment-16932525
]
Gary Gregory edited comment on COMPRESS-494 at 9/18/19 3:09 PM:
What about 1.19?
Also please use the Jira field "Fix Version/s:".
was (Author: garydgregory):
What about 1.19?
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Anvesh Mora
>Priority: Critical
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932525#comment-16932525
]
Gary Gregory commented on COMPRESS-494:
---
What about 1.19?
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Anvesh Mora
>Priority: Critical
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
> I missed to add version info, below are those:
> version of lib I'm using is: 1.9
> And I did try version 1.18, issue is observed in this version too.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-494) ZipArchieveInputStream component is throwing "Invalid Entry Size"
[
https://issues.apache.org/jira/browse/COMPRESS-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932481#comment-16932481
]
Gary Gregory commented on COMPRESS-494:
---
[~anveshmora]
Please specify which version you are using.
Gary
> ZipArchieveInputStream component is throwing "Invalid Entry Size"
> -
>
> Key: COMPRESS-494
> URL: https://issues.apache.org/jira/browse/COMPRESS-494
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Anvesh Mora
>Priority: Critical
>
> I've observed in my development in certain zip files which we are able to
> extract with with unzip utility on linux is failing with our Compress library.
>
> As of now I've stack-trace to share, I'm gonna add more in here as on when
> discussion begins on this:
>
> {code:java}
> Caused by: java.lang.IllegalArgumentException: invalid entry size
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setSize(ZipArchiveEntry.java:550)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDataDescriptor(ZipArchiveI
> nputStream.java:702)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArc
> hiveInputStream.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInpu
> tStream.java:758)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStre
> am.java:407)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.jav
> a:382)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CONFIGURATION-694) Update Java requirement from version 7 to 8.
[
https://issues.apache.org/jira/browse/CONFIGURATION-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-694:
---
Fix Version/s: (was: 2.6)
2.6.1
> Update Java requirement from version 7 to 8.
>
>
> Key: CONFIGURATION-694
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-694
> Project: Commons Configuration
> Issue Type: Improvement
>Affects Versions: 2.3
> Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.6.1
>
>
> Update Java requirement from version 7 to 8.
> Then the plan is to add support for some type from {{java.time}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-752) Update Apache Commons VFS from 2.3 to 2.4.1
[ https://issues.apache.org/jira/browse/CONFIGURATION-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CONFIGURATION-752: --- Fix Version/s: (was: 2.6) 2.6.1 > Update Apache Commons VFS from 2.3 to 2.4.1 > --- > > Key: CONFIGURATION-752 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-752 > Project: Commons Configuration > Issue Type: Improvement > Reporter: Gary Gregory > Assignee: Gary Gregory >Priority: Major > Fix For: 2.6.1 > > > Update Apache Commons VFS from 2.3 to 2.4.1. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IO-559) FilenameUtils.normalize should verify hostname syntax in UNC path
[
https://issues.apache.org/jira/browse/IO-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930603#comment-16930603
]
Gary Gregory commented on IO-559:
-
I can try to get something one in the next couple of weeks...
> FilenameUtils.normalize should verify hostname syntax in UNC path
> -
>
> Key: IO-559
> URL: https://issues.apache.org/jira/browse/IO-559
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Stefan Bodewig
>Priority: Major
> Fix For: 2.7
>
>
> {{FilenameUtils.normalize}} will accept broken file names as UNC path even if
> their hostname part doesn't match the syntax of a proper hostname. Using
> certain hostnames like "." this may lead to strange side effects.
> Most likely the best fix will be to make {{getPrefixLength}} verify the
> hostname part of a suspected UNC path and return a value of {{NOT_FOUND}} if
> it is not a valid hostname - much like it does for triple slashes.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-760) Properties file using cyclical includes cause a StackOverflowError instead of detecting the misconfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed CONFIGURATION-760.
--
Fix Version/s: 2.6
Resolution: Fixed
In git master.
> Properties file using cyclical includes cause a StackOverflowError instead of
> detecting the misconfiguration
>
>
> Key: CONFIGURATION-760
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-760
> Project: Commons Configuration
> Issue Type: Bug
> Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Properties file using cyclical includes cause a StackOverflowError instead of
> detecting the misconfiguration.
> For example, see
> {{org.apache.commons.configuration2.TestPropertiesConfiguration.testIncludeLoadAllCycliclaReference()}}:
> {noformat}
> java.lang.StackOverflowError
> at java.util.regex.Pattern$Curly.match(Pattern.java:4236)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3800)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4274)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4236)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4796)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern
[jira] [Updated] (CONFIGURATION-760) Properties file using cyclical includes cause a StackOverflowError instead of detecting the misconfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-760:
---
External issue ID: 35
External issue URL: https://github.com/apache/commons-configuration/pull/35
> Properties file using cyclical includes cause a StackOverflowError instead of
> detecting the misconfiguration
>
>
> Key: CONFIGURATION-760
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-760
> Project: Commons Configuration
> Issue Type: Bug
> Reporter: Gary Gregory
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Properties file using cyclical includes cause a StackOverflowError instead of
> detecting the misconfiguration.
> For example, see
> {{org.apache.commons.configuration2.TestPropertiesConfiguration.testIncludeLoadAllCycliclaReference()}}:
> {noformat}
> java.lang.StackOverflowError
> at java.util.regex.Pattern$Curly.match(Pattern.java:4236)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3800)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Curly.match0(Pattern.java:4274)
> at java.util.regex.Pattern$Curly.match(Pattern.java:4236)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4796)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.regex.Pattern$GroupHead.match(Pattern.java:4660)
> at java.util.regex.Pattern$Loop.match(Pattern.java:4787)
> at java.util.regex.Pattern$GroupTail.match(Pattern.java:4719)
> at java.util.regex.Pattern$BranchConn.match(Pattern.java:4570)
> at java.util.regex.Pattern$CharProperty.match(Pattern.java:3779)
> at java.util.regex.Pattern$Branch.match(Pattern.java:4606)
> at java.util.reg
[jira] [Moved] (CONFIGURATION-760) Properties file using cyclical includes cause a StackOverflowError instead of detecting the misconfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory moved IO-627 to CONFIGURATION-760: --- Key: CONFIGURATION-760 (was: IO-627) Workflow: classic default workflow (was: Default workflow, editable Closed status) Project: Commons Configuration (was: Commons IO) > Properties file using cyclical includes cause a StackOverflowError instead of > detecting the misconfiguration > > > Key: CONFIGURATION-760 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-760 > Project: Commons Configuration > Issue Type: Bug > Reporter: Gary Gregory >Priority: Major > > Properties file using cyclical includes cause a StackOverflowError instead of > detecting the misconfiguration -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IO-627) Properties file using cyclical includes cause a StackOverflowError instead of detecting the misconfiguration
Gary Gregory created IO-627: --- Summary: Properties file using cyclical includes cause a StackOverflowError instead of detecting the misconfiguration Key: IO-627 URL: https://issues.apache.org/jira/browse/IO-627 Project: Commons IO Issue Type: Bug Reporter: Gary Gregory Properties file using cyclical includes cause a StackOverflowError instead of detecting the misconfiguration -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IO-624) IOUtils.writeLines updating incompatible issue
[
https://issues.apache.org/jira/browse/IO-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928629#comment-16928629
]
Gary Gregory commented on IO-624:
-
Hello,
If you replace the commons-io jar file with the new one and run your app, all
is well. If you recompile your source, you must adapt.
> IOUtils.writeLines updating incompatible issue
> --
>
> Key: IO-624
> URL: https://issues.apache.org/jira/browse/IO-624
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: xia0c
>Priority: Major
>
> Hi,
> The following code snippets throw an incompatible issue when I try to rolling
> update Commons-io from 2.2 to 2.6.
> {code:java}
> @Test
> public void test() throws IOException{
>
> File TestFile = new File( "test.txt" );
> OutputStream out = null;
> List lines = Arrays.asList("a","b","c");
> try {
> out = new FileOutputStream(TestFile, true);
> IOUtils.writeLines(lines, null, out, null);
> } finally {
> IOUtils.closeQuietly(out);
> }
> {code}
> It throws an error:
> {code:java}
> error: reference to writeLines is ambiguous
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-756) Allow for custom behavior to handle errors loading included properties files.
[
https://issues.apache.org/jira/browse/CONFIGURATION-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed CONFIGURATION-756.
--
Fix Version/s: 2.6
Resolution: Fixed
In git master.
> Allow for custom behavior to handle errors loading included properties files.
> -
>
> Key: CONFIGURATION-756
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-756
> Project: Commons Configuration
> Issue Type: New Feature
> Reporter: Gary Gregory
> Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The properties file format in Commons Configuration allows for a properties
> file to load external properties files through a special key called
> {{"include"}}. This PR allows for a call site to customize what happens when
> an included file does not exist or is in error.
>
> [https://github.com/apache/commons-configuration/pull/34]
> The main change is to re-implement the current behavior for include error
> handing through a new consumer used in {{PropertiesConfiguration}} by
> introducing a functional interface to consume any type and throw
> {{ConfigurationException}}:
> {code:java}
> /**
> * A Configuration task that may throw a ConfigurationException.
> *
> * @param the type of the input to the operation.
> * @since 2.6
> */
> @FunctionalInterface
> public interface ConfigurationConsumer
> {
> /**
> * Performs this operation on the given argument.
> *
> * @param t the input argument
> * @throws ConfigurationException TODO
> */
> void accept(T t) throws ConfigurationException;
> }
> {code}
> The above is the common pattern when you need a consumer to throw a checked
> exception.
> The {{PropertiesConfiguration}} default behavior does not change and is
> implemented as:
> {code:java}
> /**
> * Defines default error handling for the special {@code "include"} key
> by throwing the given exception.
> *
> * @since 2.6
> */
> public static final ConfigurationConsumer
> DEFAULT_INCLUDE_LISTENER = e ->
> {
> throw e;
> };
> {code}
> In addition, a noop implementation is provided for simple use cases and tests:
> {code:java}
> /**
> * Defines error handling as a noop for the special {@code "include"} key.
> *
> * @since 2.6
> */
> public static final ConfigurationConsumer
> NOOP_INCLUDE_LISTENER = e ->
> {
> // noop
> };
> {code}
> You can set an include listener through new methods in
> {{PropertiesConfiguration}} and through the fluent API as well. See the PR
> for details.
> Note that this PR does not address detecting cyclical include files but does
> include a new test method which is decorated with {{@Ignore}}.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-759) Update Spring from 4.3.24.RELEASE to 4.3.25.RELEASE
[ https://issues.apache.org/jira/browse/CONFIGURATION-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-759. -- Resolution: Fixed In git master. > Update Spring from 4.3.24.RELEASE to 4.3.25.RELEASE > --- > > Key: CONFIGURATION-759 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-759 > Project: Commons Configuration > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > > * Update org.springframework:spring-beans from 4.3.24.RELEASE to > 4.3.25.RELEASE. > * Update org.springframework:spring-context from 4.3.24.RELEASE to > 4.3.25.RELEASE. > * Update org.springframework:spring-core from 4.3.24.RELEASE to > 4.3.25.RELEASE. > * Update org.springframework:spring-test from 4.3.24.RELEASE to > 4.3.25.RELEASE. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-759) Update Spring from 4.3.24.RELEASE to 4.3.25.RELEASE
[ https://issues.apache.org/jira/browse/CONFIGURATION-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CONFIGURATION-759: --- Description: * Update org.springframework:spring-beans from 4.3.24.RELEASE to 4.3.25.RELEASE. * Update org.springframework:spring-context from 4.3.24.RELEASE to 4.3.25.RELEASE. * Update org.springframework:spring-core from 4.3.24.RELEASE to 4.3.25.RELEASE. * Update org.springframework:spring-test from 4.3.24.RELEASE to 4.3.25.RELEASE. was: * Update org.springframework:spring-beans from 4.3.24.RELEASE to 4.3.25.RELEASE * Update org.springframework:spring-context from 4.3.24.RELEASE to 4.3.25.RELEASE * Update org.springframework:spring-core from 4.3.24.RELEASE to 4.3.25.RELEASE * Update org.springframework:spring-test from 4.3.24.RELEASE to 4.3.25.RELEASE > Update Spring from 4.3.24.RELEASE to 4.3.25.RELEASE > --- > > Key: CONFIGURATION-759 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-759 > Project: Commons Configuration > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > > * Update org.springframework:spring-beans from 4.3.24.RELEASE to > 4.3.25.RELEASE. > * Update org.springframework:spring-context from 4.3.24.RELEASE to > 4.3.25.RELEASE. > * Update org.springframework:spring-core from 4.3.24.RELEASE to > 4.3.25.RELEASE. > * Update org.springframework:spring-test from 4.3.24.RELEASE to > 4.3.25.RELEASE. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CONFIGURATION-759) Update Spring from 4.3.24.RELEASE to 4.3.25.RELEASE
Gary Gregory created CONFIGURATION-759: -- Summary: Update Spring from 4.3.24.RELEASE to 4.3.25.RELEASE Key: CONFIGURATION-759 URL: https://issues.apache.org/jira/browse/CONFIGURATION-759 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory * Update org.springframework:spring-beans from 4.3.24.RELEASE to 4.3.25.RELEASE * Update org.springframework:spring-context from 4.3.24.RELEASE to 4.3.25.RELEASE * Update org.springframework:spring-core from 4.3.24.RELEASE to 4.3.25.RELEASE * Update org.springframework:spring-test from 4.3.24.RELEASE to 4.3.25.RELEASE -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-758) Update commons-codec:commons-codec from 1.12 to 1.13.
[ https://issues.apache.org/jira/browse/CONFIGURATION-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-758. -- Resolution: Fixed In git master. > Update commons-codec:commons-codec from 1.12 to 1.13. > - > > Key: CONFIGURATION-758 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-758 > Project: Commons Configuration > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > > Update commons-codec:commons-codec from 1.12 to 1.13. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CONFIGURATION-758) Update commons-codec:commons-codec from 1.12 to 1.13.
Gary Gregory created CONFIGURATION-758: -- Summary: Update commons-codec:commons-codec from 1.12 to 1.13. Key: CONFIGURATION-758 URL: https://issues.apache.org/jira/browse/CONFIGURATION-758 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory Update commons-codec:commons-codec from 1.12 to 1.13. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-757) Update org.yaml:snakeyaml from 1.24 to 1.25
[ https://issues.apache.org/jira/browse/CONFIGURATION-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-757. -- Fix Version/s: 2.6 Resolution: Fixed In git master. > Update org.yaml:snakeyaml from 1.24 to 1.25 > --- > > Key: CONFIGURATION-757 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-757 > Project: Commons Configuration > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > Fix For: 2.6 > > > Update org.yaml:snakeyaml from 1.24 to 1.25. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CONFIGURATION-757) Update org.yaml:snakeyaml from 1.24 to 1.25
Gary Gregory created CONFIGURATION-757: -- Summary: Update org.yaml:snakeyaml from 1.24 to 1.25 Key: CONFIGURATION-757 URL: https://issues.apache.org/jira/browse/CONFIGURATION-757 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory Update org.yaml:snakeyaml from 1.24 to 1.25. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928567#comment-16928567
]
Gary Gregory commented on CONFIGURATION-753:
Since this does not feel fully baked, I will proceed with a release without it.
We can always release again later.
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LANG-1453.
Fix Version/s: 3.10
Resolution: Fixed
In git master, please verify and fix.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Fix For: 3.10
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927898#comment-16927898
]
Gary Gregory edited comment on LANG-1453 at 9/11/19 6:50 PM:
-
In git master, please verify and close.
was (Author: garydgregory):
In git master, please verify and fix.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Fix For: 3.10
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-756) Allow for custom behavior to handle errors loading included properties files.
[
https://issues.apache.org/jira/browse/CONFIGURATION-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-756:
---
Description:
The properties file format in Commons Configuration allows for a properties
file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
[https://github.com/apache/commons-configuration/pull/34]
The main change is to re-implement the current behavior for include error
handing through a new consumer used in {{PropertiesConfiguration}} by
introducing a functional interface to consume any type and throw
{{ConfigurationException}}:
{code:java}
/**
* A Configuration task that may throw a ConfigurationException.
*
* @param the type of the input to the operation.
* @since 2.6
*/
@FunctionalInterface
public interface ConfigurationConsumer
{
/**
* Performs this operation on the given argument.
*
* @param t the input argument
* @throws ConfigurationException TODO
*/
void accept(T t) throws ConfigurationException;
}
{code}
The above is the common pattern when you need a consumer to throw a checked
exception.
The {{PropertiesConfiguration}} default behavior does not change and is
implemented as:
{code:java}
/**
* Defines default error handling for the special {@code "include"} key by
throwing the given exception.
*
* @since 2.6
*/
public static final ConfigurationConsumer
DEFAULT_INCLUDE_LISTENER = e ->
{
throw e;
};
{code}
In addition, a noop implementation is provided for simple use cases and tests:
{code:java}
/**
* Defines error handling as a noop for the special {@code "include"} key.
*
* @since 2.6
*/
public static final ConfigurationConsumer
NOOP_INCLUDE_LISTENER = e ->
{
// noop
};
{code}
You can set an include listener through new methods in
{{PropertiesConfiguration}} and through the fluent API as well. See the PR for
details.
Note that this PR does not address detecting cyclical include files but does
include a new test method which is decorated with {{@Ignore}}.
was:
The properties file format in Commons Configuration allows for a properties
file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
* I am reworking the whole PR ATM, please hold... *
[https://github.com/apache/commons-configuration/pull/34]
The main change is to re-implement the current behavior for include error
handing through a new interface defined in {{PropertiesConfiguration}}:
{code:java}
/**
* Defines error handling for the special {@code "include"} key.
*
* @since 2.6
*/
public interface IncludeListener
{
/**
* Defines what to do when an include file is missing.
*
* @param fileName the missing file name.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onFileNotFound(String fileName) throws ConfigurationException;
/**
* Defines what to do when an exception is caught loading a property
file.
*
* @param e The exception.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onLoadException(ConfigurationException e) throws
ConfigurationException;
}
{code}
Where the default behavior does not change and is implemented as:
{code:java}
/**
* Defines the default behavior.
*
* @since 2.6
*/
public static class DefaultIncludeListener implements IncludeListener
{
/**
* The singleton instance.
*/
public static final DefaultIncludeListener INSTANCE = new
DefaultIncludeListener();
@Override
public void onFileNotFound(final String fileName) throws
ConfigurationException
{
throw new ConfigurationException("Cannot resolve include file " +
fileName);
}
@Override
public void onLoadException(ConfigurationException e) throws
ConfigurationException
{
throw e;
}
}
{code}
In addition, a NOOP implementation is provided for simple use cases and tests:
{code:java}
/**
* Implements all methods as noops.
*
* @since 2.6
*/
public static class NoopIncludeListener implements IncludeListener
{
/**
* The singleton instance.
*/
public static final NoopIncludeListener INSTANCE = new
NoopIncludeListener();
@Override
public void on
[jira] [Resolved] (LANG-1406) StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase()
[
https://issues.apache.org/jira/browse/LANG-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LANG-1406.
Fix Version/s: 3.10
Resolution: Fixed
[~michaelryan], [~gtorres]
In git master now. Please verify and close.
Thank you!
Gary
> StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase()
> --
>
> Key: LANG-1406
> URL: https://issues.apache.org/jira/browse/LANG-1406
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Michael Ryan
>Priority: Major
> Fix For: 3.10
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> STEPS TO REPRODUCE:
> {code}
> StringUtils.replaceIgnoreCase("\u0130x", "x", "")
> {code}
> EXPECTED: "\u0130" is returned.
> ACTUAL: StringIndexOutOfBoundsException
> This happens because the replace method is assuming that text.length() ==
> text.toLowerCase().length(), which is not true for certain characters.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1406) StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase()
[
https://issues.apache.org/jira/browse/LANG-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1406:
---
Summary: StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase()
(was: StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase)
> StringIndexOutOfBoundsException in StringUtils.replaceIgnoreCase()
> --
>
> Key: LANG-1406
> URL: https://issues.apache.org/jira/browse/LANG-1406
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Michael Ryan
>Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> STEPS TO REPRODUCE:
> {code}
> StringUtils.replaceIgnoreCase("\u0130x", "x", "")
> {code}
> EXPECTED: "\u0130" is returned.
> ACTUAL: StringIndexOutOfBoundsException
> This happens because the replace method is assuming that text.length() ==
> text.toLowerCase().length(), which is not true for certain characters.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (LANG-1489) Add null-safe APIs as StringUtils.toRootLowerCase(String) and StringUtils.toRootUpperCase(String)
[
https://issues.apache.org/jira/browse/LANG-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LANG-1489.
--
Fix Version/s: 3.10
Resolution: Fixed
In git master.
> Add null-safe APIs as StringUtils.toRootLowerCase(String) and
> StringUtils.toRootUpperCase(String)
> -
>
> Key: LANG-1489
> URL: https://issues.apache.org/jira/browse/LANG-1489
> Project: Commons Lang
> Issue Type: New Feature
> Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> add null-safe APIs as {{StringUtils.toRootLowerCase(String) and
> }}{{StringUtils.toRootUpperCase(String)}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-756) Allow for custom behavior to handle errors loading included properties files.
[
https://issues.apache.org/jira/browse/CONFIGURATION-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-756:
---
Description:
The properties file format in Commons Configuration allows for a properties
file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
* I am reworking the whole PR ATM, please hold... *
[https://github.com/apache/commons-configuration/pull/34]
The main change is to re-implement the current behavior for include error
handing through a new interface defined in {{PropertiesConfiguration}}:
{code:java}
/**
* Defines error handling for the special {@code "include"} key.
*
* @since 2.6
*/
public interface IncludeListener
{
/**
* Defines what to do when an include file is missing.
*
* @param fileName the missing file name.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onFileNotFound(String fileName) throws ConfigurationException;
/**
* Defines what to do when an exception is caught loading a property
file.
*
* @param e The exception.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onLoadException(ConfigurationException e) throws
ConfigurationException;
}
{code}
Where the default behavior does not change and is implemented as:
{code:java}
/**
* Defines the default behavior.
*
* @since 2.6
*/
public static class DefaultIncludeListener implements IncludeListener
{
/**
* The singleton instance.
*/
public static final DefaultIncludeListener INSTANCE = new
DefaultIncludeListener();
@Override
public void onFileNotFound(final String fileName) throws
ConfigurationException
{
throw new ConfigurationException("Cannot resolve include file " +
fileName);
}
@Override
public void onLoadException(ConfigurationException e) throws
ConfigurationException
{
throw e;
}
}
{code}
In addition, a NOOP implementation is provided for simple use cases and tests:
{code:java}
/**
* Implements all methods as noops.
*
* @since 2.6
*/
public static class NoopIncludeListener implements IncludeListener
{
/**
* The singleton instance.
*/
public static final NoopIncludeListener INSTANCE = new
NoopIncludeListener();
@Override
public void onFileNotFound(final String fileName) throws
ConfigurationException
{
// noop
}
@Override
public void onLoadException(ConfigurationException e) throws
ConfigurationException
{
// noop
}
}
{code}
You can set an include listener through new methods in
{{PropertiesConfiguration}} and through the fluent API as well. See the PR for
details.
Note that this PR does not address detecting cyclical include files but does
include a new test method which is decorated with {{@Ignore}}.
was:
The properties file format in Commons Configuration allows for a properties
file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
https://github.com/apache/commons-configuration/pull/34
The main change is to re-implement the current behavior for include error
handing through a new interface defined in {{PropertiesConfiguration}}:
{code:java}
/**
* Defines error handling for the special {@code "include"} key.
*
* @since 2.6
*/
public interface IncludeListener
{
/**
* Defines what to do when an include file is missing.
*
* @param fileName the missing file name.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onFileNotFound(String fileName) throws ConfigurationException;
/**
* Defines what to do when an exception is caught loading a property
file.
*
* @param e The exception.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onLoadException(ConfigurationException e) throws
ConfigurationException;
}
{code}
Where the default behavior does not change and is implemented as:
{code:java}
/**
* Defines the default behavior.
*
* @since 2.6
*/
public static class
[jira] [Commented] (COLLECTIONS-708) Create CollectionUtils.hashCode using Equator
[
https://issues.apache.org/jira/browse/COLLECTIONS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926788#comment-16926788
]
Gary Gregory commented on COLLECTIONS-708:
--
Hi [~Guoping1]
Your best bet is to provide a pull request including unit tests on GitHub
[https://github.com/apache/commons-collections/]
Gary
> Create CollectionUtils.hashCode using Equator
> -
>
> Key: COLLECTIONS-708
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-708
> Project: Commons Collections
> Issue Type: Improvement
> Components: Collection
>Affects Versions: 4.2
>Reporter: Andrei Ivanov
>Priority: Major
>
> Hello,
> After discovering {{CollectionUtils#isEqualCollection}} that uses an
> {{Equator}}, I've started to implement {{Equator}} s for my classes, only to
> discover that I can't generate hashCodes for the collections that hold these
> classes using {{Equator#hash}}.
> I hope something like {{CollectionUtils#hashCode(Collection, Equator)}} can
> be implemented.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926722#comment-16926722
]
Gary Gregory commented on LANG-1453:
Note that this is related to the issues that calling toLowerCase() and
toUpperCase() without using a target Locale leads to unexpected results in some
cases, please see
[https://garygregory.wordpress.com/2015/11/03/java-lowercase-conversion-turkey/]
I think I will create a PR to help with this kind of conversion and add
null-safe APIs as {{StringUtils.toRootLowerCase(String) and
}}{{StringUtils.toRootUpperCase(String)}}{{}}
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (LANG-1489) Add null-safe APIs as StringUtils.toRootLowerCase(String) and StringUtils.toRootUpperCase(String)
Gary Gregory created LANG-1489:
--
Summary: Add null-safe APIs as StringUtils.toRootLowerCase(String)
and StringUtils.toRootUpperCase(String)
Key: LANG-1489
URL: https://issues.apache.org/jira/browse/LANG-1489
Project: Commons Lang
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
add null-safe APIs as {{StringUtils.toRootLowerCase(String) and
}}{{StringUtils.toRootUpperCase(String)}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-756) Allow for custom behavior to handle errors loading included properties files.
[
https://issues.apache.org/jira/browse/CONFIGURATION-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-756:
---
External issue ID: 34
External issue URL: https://github.com/apache/commons-configuration/pull/34
> Allow for custom behavior to handle errors loading included properties files.
> -
>
> Key: CONFIGURATION-756
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-756
> Project: Commons Configuration
> Issue Type: New Feature
> Reporter: Gary Gregory
> Assignee: Gary Gregory
>Priority: Major
>
> The properties file format in Commons Configuration allows for a properties
> file to load external properties files through a special key called
> {{"include"}}. This PR allows for a call site to customize what happens when
> an included file does not exist or is in error.
> https://github.com/apache/commons-configuration/pull/34
> The main change is to re-implement the current behavior for include error
> handing through a new interface defined in {{PropertiesConfiguration}}:
> {code:java}
> /**
> * Defines error handling for the special {@code "include"} key.
> *
> * @since 2.6
> */
> public interface IncludeListener
> {
> /**
> * Defines what to do when an include file is missing.
> *
> * @param fileName the missing file name.
> * @throws ConfigurationException Optionally thrown by the
> implementation to stop processing.
> */
> void onFileNotFound(String fileName) throws ConfigurationException;
> /**
> * Defines what to do when an exception is caught loading a property
> file.
> *
> * @param e The exception.
> * @throws ConfigurationException Optionally thrown by the
> implementation to stop processing.
> */
> void onLoadException(ConfigurationException e) throws
> ConfigurationException;
> }
> {code}
> Where the default behavior does not change and is implemented as:
> {code:java}
> /**
> * Defines the default behavior.
> *
> * @since 2.6
> */
> public static class DefaultIncludeListener implements IncludeListener
> {
> /**
> * The singleton instance.
> */
> public static final DefaultIncludeListener INSTANCE = new
> DefaultIncludeListener();
> @Override
> public void onFileNotFound(final String fileName) throws
> ConfigurationException
> {
> throw new ConfigurationException("Cannot resolve include file " +
> fileName);
> }
> @Override
> public void onLoadException(ConfigurationException e) throws
> ConfigurationException
> {
> throw e;
> }
> }
> {code}
> In addition, a NOOP implementation is provided for simple use cases and tests:
> {code:java}
> /**
> * Implements all methods as noops.
> *
> * @since 2.6
> */
> public static class NoopIncludeListener implements IncludeListener
> {
> /**
> * The singleton instance.
> */
> public static final NoopIncludeListener INSTANCE = new
> NoopIncludeListener();
> @Override
> public void onFileNotFound(final String fileName) throws
> ConfigurationException
> {
> // noop
> }
> @Override
> public void onLoadException(ConfigurationException e) throws
> ConfigurationException
> {
> // noop
> }
> }
> {code}
> You can set an include listener through new methods in
> {{PropertiesConfiguration}} and through the fluent API as well. See the PR
> for details.
> Note that this PR does not address detecting cyclical include files but does
> include a new test method which is decorated with {{@Ignore}}.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-756) Allow for custom behavior to handle errors loading included properties files.
[
https://issues.apache.org/jira/browse/CONFIGURATION-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-756:
---
Description:
The properties file format in Commons Configuration allows for a properties
file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
https://github.com/apache/commons-configuration/pull/34
The main change is to re-implement the current behavior for include error
handing through a new interface defined in {{PropertiesConfiguration}}:
{code:java}
/**
* Defines error handling for the special {@code "include"} key.
*
* @since 2.6
*/
public interface IncludeListener
{
/**
* Defines what to do when an include file is missing.
*
* @param fileName the missing file name.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onFileNotFound(String fileName) throws ConfigurationException;
/**
* Defines what to do when an exception is caught loading a property
file.
*
* @param e The exception.
* @throws ConfigurationException Optionally thrown by the
implementation to stop processing.
*/
void onLoadException(ConfigurationException e) throws
ConfigurationException;
}
{code}
Where the default behavior does not change and is implemented as:
{code:java}
/**
* Defines the default behavior.
*
* @since 2.6
*/
public static class DefaultIncludeListener implements IncludeListener
{
/**
* The singleton instance.
*/
public static final DefaultIncludeListener INSTANCE = new
DefaultIncludeListener();
@Override
public void onFileNotFound(final String fileName) throws
ConfigurationException
{
throw new ConfigurationException("Cannot resolve include file " +
fileName);
}
@Override
public void onLoadException(ConfigurationException e) throws
ConfigurationException
{
throw e;
}
}
{code}
In addition, a NOOP implementation is provided for simple use cases and tests:
{code:java}
/**
* Implements all methods as noops.
*
* @since 2.6
*/
public static class NoopIncludeListener implements IncludeListener
{
/**
* The singleton instance.
*/
public static final NoopIncludeListener INSTANCE = new
NoopIncludeListener();
@Override
public void onFileNotFound(final String fileName) throws
ConfigurationException
{
// noop
}
@Override
public void onLoadException(ConfigurationException e) throws
ConfigurationException
{
// noop
}
}
{code}
You can set an include listener through new methods in
{{PropertiesConfiguration}} and through the fluent API as well. See the PR for
details.
Note that this PR does not address detecting cyclical include files but does
include a new test method which is decorated with {{@Ignore}}.
was:The properties file format in Commons Configuration allows for a
properties file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
> Allow for custom behavior to handle errors loading included properties files.
> -
>
> Key: CONFIGURATION-756
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-756
> Project: Commons Configuration
> Issue Type: New Feature
> Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The properties file format in Commons Configuration allows for a properties
> file to load external properties files through a special key called
> {{"include"}}. This PR allows for a call site to customize what happens when
> an included file does not exist or is in error.
> https://github.com/apache/commons-configuration/pull/34
> The main change is to re-implement the current behavior for include error
> handing through a new interface defined in {{PropertiesConfiguration}}:
> {code:java}
> /**
> * Defines error handling for the special {@code "include"} key.
> *
> * @since 2.6
> */
> public interface IncludeListener
> {
> /**
> * Defines what to do when an include file is missing.
> *
[jira] [Created] (CONFIGURATION-756) Allow for custom behavior to handle errors loading included properties files.
Gary Gregory created CONFIGURATION-756:
--
Summary: Allow for custom behavior to handle errors loading
included properties files.
Key: CONFIGURATION-756
URL: https://issues.apache.org/jira/browse/CONFIGURATION-756
Project: Commons Configuration
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
The properties file format in Commons Configuration allows for a properties
file to load external properties files through a special key called
{{"include"}}. This PR allows for a call site to customize what happens when an
included file does not exist or is in error.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (NET-672) Commons-net updating incompatible issue: unreported exception IOException
[
https://issues.apache.org/jira/browse/NET-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925774#comment-16925774
]
Gary Gregory commented on NET-672:
--
This is a source compatibility issue, not binary compatibility which is our
goal. Please adapt your source.
> Commons-net updating incompatible issue: unreported exception IOException
> -
>
> Key: NET-672
> URL: https://issues.apache.org/jira/browse/NET-672
> Project: Commons Net
> Issue Type: Bug
> Environment:
> {code:java}
> {code}
>
>
>Reporter: xia0c
>Priority: Major
>
> Hi,
> The following code snippets throw an incompatible issue when I try to rolling
> update Commons-net from 2.0 to 3.6.
> {code:java}
> @Test
> public void test(){
> TelnetClient tc1 = new TelnetClient();
> TerminalTypeOptionHandler ttopt = new
> TerminalTypeOptionHandler("VT100", false, false, true, false);
> EchoOptionHandler echoopt = new EchoOptionHandler(true, false, true,
> false);
> SuppressGAOptionHandler gaopt = new SuppressGAOptionHandler(true,
> true, true, true);
> try {
> tc1.addOptionHandler(ttopt);
> tc1.addOptionHandler(echoopt);
> tc1.addOptionHandler(gaopt);
> } catch (InvalidTelnetOptionException e) {
> System.err.println("Error registering option handlers: " +
> e.getMessage());
> }
> }
> {code}
> It throws an error: unreported exception IOException; must be caught or
> declared to be thrown.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1488) Possible serialization failed
[
https://issues.apache.org/jira/browse/LANG-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925735#comment-16925735
]
Gary Gregory commented on LANG-1488:
In the _long_ run this should happen since Java Serialization has fallen out of
favor, but that cannot happen until a _major_ release is done like 4.0.
> Possible serialization failed
> -
>
> Key: LANG-1488
> URL: https://issues.apache.org/jira/browse/LANG-1488
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.tuple.*
>Reporter: Silence Tai
>Priority: Major
> Fix For: 3.10
>
>
> *Pair* fails to properly constrain the generic parameters, requiring them to
> implement the *Serializable* interface, which may cause serialization to fail.
> Example:
> {code:java}
> static class A { }
> @Test
> public void testSerialization() throws Exception {
> final ImmutablePair origPair = ImmutablePair.of(new A(),
> "foo");
> final ByteArrayOutputStream baos = new ByteArrayOutputStream();
> final ObjectOutputStream out = new ObjectOutputStream(baos);
> out.writeObject(origPair);
> out.close();
> baos.close();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (BCEL-318) Add method org.apache.bcel.classfile.ConstantUtf8.clearCache().
[
https://issues.apache.org/jira/browse/BCEL-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed BCEL-318.
-
Resolution: Fixed
> Add method org.apache.bcel.classfile.ConstantUtf8.clearCache().
> ---
>
> Key: BCEL-318
> URL: https://issues.apache.org/jira/browse/BCEL-318
> Project: Commons BCEL
> Issue Type: New Feature
> Reporter: Gary Gregory
> Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.4.0
>
>
> Add {{org.apache.bcel.classfile.ConstantUtf8.clearCache()}}.
> There was previously no way to clear the cache.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Reopened] (BCEL-318) Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
[
https://issues.apache.org/jira/browse/BCEL-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened BCEL-318:
---
> Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
>
>
> Key: BCEL-318
> URL: https://issues.apache.org/jira/browse/BCEL-318
> Project: Commons BCEL
> Issue Type: New Feature
> Reporter: Gary Gregory
> Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.4.0
>
>
> Add {{org.apache.bcel.classfile.ConstantUtf8.clearCache()}}.
> There was previously no way to clear the cache.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (BCEL-318) Add method org.apache.bcel.classfile.ConstantUtf8.clearCache().
[
https://issues.apache.org/jira/browse/BCEL-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated BCEL-318:
--
Summary: Add method org.apache.bcel.classfile.ConstantUtf8.clearCache().
(was: Add org.apache.bcel.classfile.ConstantUtf8.clearCache().)
> Add method org.apache.bcel.classfile.ConstantUtf8.clearCache().
> ---
>
> Key: BCEL-318
> URL: https://issues.apache.org/jira/browse/BCEL-318
> Project: Commons BCEL
> Issue Type: New Feature
> Reporter: Gary Gregory
> Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.4.0
>
>
> Add {{org.apache.bcel.classfile.ConstantUtf8.clearCache()}}.
> There was previously no way to clear the cache.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (IO-625) FileUtils.copyDirectoryToDirectory does not reflect srcDir in exception message when srcDir is not a directory
[ https://issues.apache.org/jira/browse/IO-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved IO-625. - Fix Version/s: 2.7 Resolution: Fixed In git master. > FileUtils.copyDirectoryToDirectory does not reflect srcDir in exception > message when srcDir is not a directory > -- > > Key: IO-625 > URL: https://issues.apache.org/jira/browse/IO-625 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.6 >Reporter: Mikko Maunu >Priority: Trivial > Fix For: 2.7 > > Attachments: FileUtilsCopyDirectoryToDirectoryTestCase.java > > Time Spent: 1h 50m > Remaining Estimate: 0h > > When destDir parameter to FileUtils.copyDirectoryToDirectory method is not a > directory, exception message contains srcDir instead of destDir. > Related issue is, that based on Javadocs one would expect IOException instead > of IllegalArgumentException. Changing type of the exception would probably > break some clients. Fixing message seems reasonable. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IO-621) Updating source incompatible issue
[
https://issues.apache.org/jira/browse/IO-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated IO-621:
Summary: Updating source incompatible issue (was: Updating incompatible
issue)
> Updating source incompatible issue
> --
>
> Key: IO-621
> URL: https://issues.apache.org/jira/browse/IO-621
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: xia0c
>Priority: Critical
> Labels: performance
>
> Hi,
> The following code snippets throw an incompatible issue when I try to rolling
> update Commons IO from 2.4 to 2.6.
> {code:java}
> @Test
> public void DemoTest(){
>
> LineIterator it = null;
> File TestFile = new File("TestFile");
> try {
> it = FileUtils.lineIterator(TestFile , "UTF-8");
> while (it.hasNext()) {
> String line = it.nextLine();
> }
> } catch (IOException e) {
> e.printStackTrace();
> } finally {
> if (it != null)
> it.close();
> }
> }
> {code}
> Thanks a lot.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (IO-621) Updating incompatible issue
[
https://issues.apache.org/jira/browse/IO-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved IO-621.
-
Resolution: Won't Fix
[~lingchao],
Ah, I see. This is a _source_ incompatible change but it _is_ *binary
compatible,* therefore it will not be reverted. You must therefore update you
source code.
In general, we only keep binary compatibility between minor releases. We do not
guarantee source compatibility.
Thank you,
Gary
> Updating incompatible issue
> ---
>
> Key: IO-621
> URL: https://issues.apache.org/jira/browse/IO-621
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: xia0c
>Priority: Critical
> Labels: performance
>
> Hi,
> The following code snippets throw an incompatible issue when I try to rolling
> update Commons IO from 2.4 to 2.6.
> {code:java}
> @Test
> public void DemoTest(){
>
> LineIterator it = null;
> File TestFile = new File("TestFile");
> try {
> it = FileUtils.lineIterator(TestFile , "UTF-8");
> while (it.hasNext()) {
> String line = it.nextLine();
> }
> } catch (IOException e) {
> e.printStackTrace();
> } finally {
> if (it != null)
> it.close();
> }
> }
> {code}
> Thanks a lot.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IO-621) Updating incompatible issue
[
https://issues.apache.org/jira/browse/IO-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16925192#comment-16925192
]
Gary Gregory commented on IO-621:
-
How so?
> Updating incompatible issue
> ---
>
> Key: IO-621
> URL: https://issues.apache.org/jira/browse/IO-621
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: xia0c
>Priority: Critical
> Labels: performance
>
> Hi,
> The following code snippets throw an incompatible issue when I try to rolling
> update Commons IO from 2.4 to 2.6.
> {code:java}
> @Test
> public void DemoTest(){
>
> LineIterator it = null;
> File TestFile = new File("TestFile");
> try {
> it = FileUtils.lineIterator(TestFile , "UTF-8");
> while (it.hasNext()) {
> String line = it.nextLine();
> }
> } catch (IOException e) {
> e.printStackTrace();
> } finally {
> if (it != null)
> it.close();
> }
> }
> {code}
> Thanks a lot.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-755) [CVE-2014-0114] Update Apache Commons BeanUtils from 1.9.3 to 1.9.4.
[ https://issues.apache.org/jira/browse/CONFIGURATION-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-755. -- Fix Version/s: 2.6 Assignee: Gary Gregory Resolution: Fixed In git master. > [CVE-2014-0114] Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. > > > Key: CONFIGURATION-755 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-755 > Project: Commons Configuration > Issue Type: New Feature > Reporter: Gary Gregory > Assignee: Gary Gregory >Priority: Major > Fix For: 2.6 > > > Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. > This picks up [BEANUTILS-520]: BeanUtils mitigation of CVE-2014-0114. > (CVE-2019-10086 for commons-beanutils). Thanks to Melloware. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CONFIGURATION-755) [CVE-2014-0114] Update Apache Commons BeanUtils from 1.9.3 to 1.9.4.
[ https://issues.apache.org/jira/browse/CONFIGURATION-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CONFIGURATION-755: --- Summary: [CVE-2014-0114] Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. (was: Update Apache Commons BeanUtils from 1.9.3 to 1.9.4.) > [CVE-2014-0114] Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. > > > Key: CONFIGURATION-755 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-755 > Project: Commons Configuration > Issue Type: New Feature > Reporter: Gary Gregory >Priority: Major > > Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. > This picks up [BEANUTILS-520]: BeanUtils mitigation of CVE-2014-0114. > (CVE-2019-10086 for commons-beanutils). Thanks to Melloware. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CONFIGURATION-755) Update Apache Commons BeanUtils from 1.9.3 to 1.9.4.
Gary Gregory created CONFIGURATION-755: -- Summary: Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. Key: CONFIGURATION-755 URL: https://issues.apache.org/jira/browse/CONFIGURATION-755 Project: Commons Configuration Issue Type: New Feature Reporter: Gary Gregory Update Apache Commons BeanUtils from 1.9.3 to 1.9.4. This picks up [BEANUTILS-520]: BeanUtils mitigation of CVE-2014-0114. (CVE-2019-10086 for commons-beanutils). Thanks to Melloware. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (LANG-1487) Add ClassLoaderUtils with toString() implementations for URLClassLoader
[ https://issues.apache.org/jira/browse/LANG-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1487: --- External issue ID: 453 External issue URL: https://github.com/apache/commons-lang/pull/453 Description: Please see GH PR https://github.com/apache/commons-lang/pull/453 > Add ClassLoaderUtils with toString() implementations for URLClassLoader > --- > > Key: LANG-1487 > URL: https://issues.apache.org/jira/browse/LANG-1487 > Project: Commons Lang > Issue Type: New Feature > Reporter: Gary Gregory >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Please see GH PR https://github.com/apache/commons-lang/pull/453 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (LANG-1487) Add ClassLoaderUtils with toString() implementations for URLClassLoader
Gary Gregory created LANG-1487: -- Summary: Add ClassLoaderUtils with toString() implementations for URLClassLoader Key: LANG-1487 URL: https://issues.apache.org/jira/browse/LANG-1487 Project: Commons Lang Issue Type: New Feature Reporter: Gary Gregory -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (LANG-1486) Generify builder classes Diffable, DiffBuilder, and DiffResult
[ https://issues.apache.org/jira/browse/LANG-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LANG-1486. -- Fix Version/s: 3.10 Assignee: Gary Gregory Resolution: Fixed In git master. > Generify builder classes Diffable, DiffBuilder, and DiffResult > -- > > Key: LANG-1486 > URL: https://issues.apache.org/jira/browse/LANG-1486 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* > Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 3.10 > > Time Spent: 40m > Remaining Estimate: 0h > > Generify builder classes: > - org.apache.commons.lang3.builder.Diffable > - org.apache.commons.lang3.builder.DiffBuilder > - org.apache.commons.lang3.builder.DiffResult > After the introduction of [LANG-1485], new APIs typed to `Object` were added. > This feels like wrong and can be resolved with generics. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (LANG-1486) Generify builder classes Diffable, DiffBuilder, and DiffResult
[ https://issues.apache.org/jira/browse/LANG-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LANG-1486: --- External issue ID: 452 External issue URL: https://github.com/apache/commons-lang/pull/452 > Generify builder classes Diffable, DiffBuilder, and DiffResult > -- > > Key: LANG-1486 > URL: https://issues.apache.org/jira/browse/LANG-1486 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* > Reporter: Gary Gregory >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Generify builder classes: > - org.apache.commons.lang3.builder.Diffable > - org.apache.commons.lang3.builder.DiffBuilder > - org.apache.commons.lang3.builder.DiffResult > After the introduction of [LANG-1485], new APIs typed to `Object` were added. > This feels like wrong and can be resolved with generics. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (LANG-1486) Generify builder classes Diffable, DiffBuilder, and DiffResult
Gary Gregory created LANG-1486: -- Summary: Generify builder classes Diffable, DiffBuilder, and DiffResult Key: LANG-1486 URL: https://issues.apache.org/jira/browse/LANG-1486 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Reporter: Gary Gregory Generify builder classes: - org.apache.commons.lang3.builder.Diffable - org.apache.commons.lang3.builder.DiffBuilder - org.apache.commons.lang3.builder.DiffResult After the introduction of [LANG-1485], new APIs typed to `Object` were added. This feels like wrong and can be resolved with generics. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (LANG-1485) DiffResult should expose its Left & Right objects with getters
[ https://issues.apache.org/jira/browse/LANG-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LANG-1485. Fix Version/s: 3.10 Resolution: Fixed [~nicolasbd], In git master; please verify and close. Gary > DiffResult should expose its Left & Right objects with getters > -- > > Key: LANG-1485 > URL: https://issues.apache.org/jira/browse/LANG-1485 > Project: Commons Lang > Issue Type: Wish > Components: lang.builder.* >Affects Versions: 3.9 >Reporter: Nicolas BARTHE-DEJEAN >Priority: Trivial > Fix For: 3.10 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Using a `DiffResult` object outside of any `Diffable` interface, I should be > able to access the two objects of the diff. > Currently, this is impossible since the two fields `Object lhs` and `Object > rhs` are private and the class doesn't provide any getter to return them. > > PR on Github : https://github.com/apache/commons-lang/pull/451 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (LANG-1485) DiffResult should expose its Left & Right objects with getters
[ https://issues.apache.org/jira/browse/LANG-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16923500#comment-16923500 ] Gary Gregory commented on LANG-1485: We welcome PRs on GitHub, with unit tests of course ;) > DiffResult should expose its Left & Right objects with getters > -- > > Key: LANG-1485 > URL: https://issues.apache.org/jira/browse/LANG-1485 > Project: Commons Lang > Issue Type: Wish > Components: lang.builder.* >Affects Versions: 3.9 >Reporter: Nicolas BARTHE-DEJEAN >Priority: Trivial > > Using a `DiffResult` object outside of any `Diffable` interface, I should be > able to access the two objects of the diff. > Currently, this is impossible since the two fields `Object lhs` and `Object > rhs` are private and the class doesn't provide any getter to return them. > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CSV-251) CSVPrinter don't handle byte[] correctly for postgres
[
https://issues.apache.org/jira/browse/CSV-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922583#comment-16922583
]
Gary Gregory commented on CSV-251:
--
ATM, Commons CSV does not depend on Commons Codec which contains the Hex class.
I am not sure we should copy and past this code here or depend on Commons Codec
as a Maven dependency. I usually favor dependencies over copying code. Any
thoughts from the community?
> CSVPrinter don't handle byte[] correctly for postgres
> -
>
> Key: CSV-251
> URL: https://issues.apache.org/jira/browse/CSV-251
> Project: Commons CSV
> Issue Type: Improvement
> Components: Printer
> Environment: java version
> ```
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> ```
> apache.commons.csv: 1.6
> clojure: 1.9.0
> postgres: 10.7
>
>Reporter: saitouena
>Priority: Minor
>
> I passed byte[] values for CSVPrinter.printRecords with
> CSVFormat.POSTGRESQL_CSV, but it use Object.toString(printed [B@ in
> clojure). As a result, data were discarded.
> I don't know about other RDBs, but at least postgres supports
> [https://www.postgresql.org/docs/9.3/datatype-binary.html] hexstring format.
> Workaround: Wrap byte[] with the class that has proper toString method like
> this.
> ```
> public string toString()
> { return "\\x" + encodeHexString(this.bytedata); }
> ```
> I used apache.commons.csv from Clojure. I'll make a minimal repro case in
> Java if needed. I have clojure code for now.
> clojure code:
> ```
> (deftype ByteArrayForCopyIn [^"[B" bs]
> Object
> (toString [self] (str "\\x" (Hex/encodeHexString bs
> (let [sb (StringBuilder.)
> values [(.getBytes "hoge")]]
> (with-open [^CSVPrinter p (CSVPrinter. sb CSVFormat/POSTGRESQL_CSV)]
> (.printRecords p values)))
> ```
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CSV-236) Allow duplicate headers in CSV File
[ https://issues.apache.org/jira/browse/CSV-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922511#comment-16922511 ] Gary Gregory commented on CSV-236: -- [~esend7881], I added the test `org.apache.commons.csv.CSVFormatTest.testJiraCsv236()` which passes in git master. May you please try 1.8-SNAPSHOT and report your results here? Thank you, Gary > Allow duplicate headers in CSV File > --- > > Key: CSV-236 > URL: https://issues.apache.org/jira/browse/CSV-236 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Affects Versions: Discussion >Reporter: Eric K. Sender >Priority: Major > Original Estimate: 24h > Remaining Estimate: 24h > > Currently if a CSV file has a duplicate column header, a runtime exception is > thrown: > [https://github.com/apache/commons-csv/blob/546fd69eaa6b3fd2c9da8b4222a3822f1ab53abd/src/main/java/org/apache/commons/csv/CSVParser.java#L492] > I think that may be a bit harsh reaction, as there could be some columns > whose data is relative to its column order. I understand the header map uses > the column name as the key, however I anticipate one could flip the map to be > a Map so its column number is the key. > Anyway I am curious what the genesis of this decision was to use column > headers as the key and if it's worthwhile to flip the map and allow for > duplicate column names. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (CODEC-262) Update jackson dependency to current
[ https://issues.apache.org/jira/browse/CODEC-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CODEC-262. -- Resolution: Invalid Commons Codec does not depend on Jackson. Check pom.xml. > Update jackson dependency to current > > > Key: CODEC-262 > URL: https://issues.apache.org/jira/browse/CODEC-262 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.13 >Reporter: Morey Straus >Priority: Major > Labels: security > > commons-codec installs jackson 1.9.13, which is a six year old version and no > longer maintained. Please update to jackson 2.x -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (CONFIGURATION-754) Update Apache Commons Text from 1.7 to 1.8.
[ https://issues.apache.org/jira/browse/CONFIGURATION-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-754. -- Fix Version/s: 2.6 Resolution: Fixed In git master. > Update Apache Commons Text from 1.7 to 1.8. > --- > > Key: CONFIGURATION-754 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-754 > Project: Commons Configuration > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (CONFIGURATION-754) Update Apache Commons Text from 1.7 to 1.8.
Gary Gregory created CONFIGURATION-754: -- Summary: Update Apache Commons Text from 1.7 to 1.8. Key: CONFIGURATION-754 URL: https://issues.apache.org/jira/browse/CONFIGURATION-754 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (TEXT-158) Incorrect values for Jaccard similarity with empty strings
[
https://issues.apache.org/jira/browse/TEXT-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated TEXT-158:
--
Fix Version/s: (was: 1.8)
1.8.1
> Incorrect values for Jaccard similarity with empty strings
> --
>
> Key: TEXT-158
> URL: https://issues.apache.org/jira/browse/TEXT-158
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.8.1
>
>
> In a discussion part of TEXT-126, it was
> [pointed|https://github.com/apache/commons-text/pull/103#discussion_r263988298]
> that the Jaccard similarity returns 0.0, and the distance 1.0. While in
> other libraries it returns the opposite for each.
> {code:java}
> package br.eti.kinoshita.tests.text;
> import java.util.Collections;
> public class EditDistances {
> public static void main(String[] args) {
> System.out.println("Testing jaccard sim/dis with empty strings");
> System.out.println("---");
> org.simmetrics.metrics.Jaccard j1 = new
> org.simmetrics.metrics.Jaccard<>();
> float s1 = j1.compare(Collections.emptySet(), Collections.emptySet());
> System.out.println("Simmetrics Jaccard similarity: " + s1);
> float d1 = j1.distance(Collections.emptySet(),
> Collections.emptySet());
> System.out.println("Simmetrics Jaccard distance: " + d1);
>
> System.out.println("---");
>
> info.debatty.java.stringsimilarity.Jaccard j2 = new
> info.debatty.java.stringsimilarity.Jaccard();
> double s2 = j2.similarity("", "");
> System.out.println("javastringsimilarity Jaccard similarity: " + s2);
> double d2 = j2.distance("", "");
> System.out.println("javastringsimilarity Jaccard distance: " + d2);
>
> System.out.println("---");
>
> org.apache.commons.text.similarity.JaccardSimilarity j3_1 = new
> org.apache.commons.text.similarity.JaccardSimilarity();
> double s3 = j3_1.apply("", "");
> System.out.println("commons-text Jaccard similarity: " + s3);
> org.apache.commons.text.similarity.JaccardDistance j3_2 = new
> org.apache.commons.text.similarity.JaccardDistance();
> double d3 = j3_2.apply("", "");
> System.out.println("commons-text Jaccard distance: " + d3);
> }
> }{code}
> Produces:
> {noformat}
> Testing jaccard sim/dis with empty strings
> ---
> Simmetrics Jaccard similarity: 1.0
> Simmetrics Jaccard distance: 0.0
> ---
> javastringsimilarity Jaccard similarity: 1.0
> javastringsimilarity Jaccard distance: 0.0
> ---
> commons-text Jaccard similarity: 0.0
> commons-text Jaccard distance: 1.0{noformat}
> We need to confirm what's the correct output for similarity and distance with
> empty strings. And either document why we are returning what we are
> returning, or fix it as a bug for the next release.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (VFS-729) Upgrade hadoop to 2.7.4 or later; will use current 3.2.0
[
https://issues.apache.org/jira/browse/VFS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920540#comment-16920540
]
Gary Gregory edited comment on VFS-729 at 9/2/19 12:10 AM:
---
Updated to 3.2.0. All better all the way to Java 13.
Please verify and close.
Java 14-EA fails in a different place which we can take up elsewhere:
{noformat}
Tests run: 89, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.35 sec - in
org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.826 sec <<<
FAILURE! - in
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
junit.framework.TestSuite@ab2e887(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1)
Time elapsed: 3.826 sec <<< ERROR!
java.lang.IllegalStateException: Not initialized
at
org.apache.jackrabbit.core.security.simple.SimpleSecurityManager.checkInitialized(SimpleSecurityManager.java:265)
at
org.apache.jackrabbit.core.security.simple.SimpleSecurityManager.close(SimpleSecurityManager.java:169)
at
org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1101)
at
org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:1081)
at
org.apache.jackrabbit.core.TransientRepository.stopRepository(TransientRepository.java:261)
at
org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:334)
at
org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:349)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.getSession(WebdavProviderTestCase.java:146)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.importFiles(WebdavProviderTestCase.java:163)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.setUpClass(WebdavProviderTestCase.java:213)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.access$100(WebdavProviderTestCase.java:55)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:245)
at
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:131)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
was (Author: garydgregory):
Updated to 3.2.0. All better all the way to Java 13.
Java 14-EA fails in a different place which we can take up elsewhere:
{noformat}
Tests run: 89, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.35 sec - in
org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.826 sec <<<
FAILURE! - in
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
junit.framework.TestSuite@ab2e887(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1)
Time elapsed: 3.826 sec <<< ERROR!
java.lang.IllegalStateException: Not initialized
at
org.apache.jackrabbit.core.security.simple.SimpleSecurityManager.checkInitialized(SimpleSecurityManager.java:265)
at
org.apache.jackrabbit.core.security.simple.SimpleSecurityManager.close(SimpleSecurityManager.java:169)
at
org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1101)
at
org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:1081)
at
org.apache.jackrabbit.core.TransientRepository.stopRepository(TransientRepository.java:261)
at
org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:334)
at
org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:349)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.getSes
[jira] [Resolved] (VFS-729) Upgrade hadoop to 2.7.4 or later; will use current 3.2.0
[
https://issues.apache.org/jira/browse/VFS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-729.
--
Fix Version/s: 2.4.2
Resolution: Fixed
Updated to 3.2.0. All better all the way to Java 13.
Java 14-EA fails in a different place which we can take up elsewhere:
{noformat}
Tests run: 89, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.35 sec - in
org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
Running org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.826 sec <<<
FAILURE! - in
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase
junit.framework.TestSuite@ab2e887(org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1)
Time elapsed: 3.826 sec <<< ERROR!
java.lang.IllegalStateException: Not initialized
at
org.apache.jackrabbit.core.security.simple.SimpleSecurityManager.checkInitialized(SimpleSecurityManager.java:265)
at
org.apache.jackrabbit.core.security.simple.SimpleSecurityManager.close(SimpleSecurityManager.java:169)
at
org.apache.jackrabbit.core.RepositoryImpl.doShutdown(RepositoryImpl.java:1101)
at
org.apache.jackrabbit.core.RepositoryImpl.shutdown(RepositoryImpl.java:1081)
at
org.apache.jackrabbit.core.TransientRepository.stopRepository(TransientRepository.java:261)
at
org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:334)
at
org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:349)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.getSession(WebdavProviderTestCase.java:146)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.importFiles(WebdavProviderTestCase.java:163)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.setUpClass(WebdavProviderTestCase.java:213)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase.access$100(WebdavProviderTestCase.java:55)
at
org.apache.commons.vfs2.provider.webdav.test.WebdavProviderTestCase$1.setUp(WebdavProviderTestCase.java:245)
at
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:131)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
> Upgrade hadoop to 2.7.4 or later; will use current 3.2.0
>
>
> Key: VFS-729
> URL: https://issues.apache.org/jira/browse/VFS-729
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Michiel Hendriks
>Priority: Minor
> Fix For: 2.4.2
>
>
> The reason why the Travis builds currently fail for JDK 13/EA is due to this
> Hadoop issue: HADOOP-14586
> I've tested it locally (JDK 13, Build 33) with Hadoop 2.7.4 and all tests
> pass. As this does bump the Hadoop dependency from 2.6 to >=2.7.4 you
> probably want to do this for a VFS 2.5 release and in the mean time disable
> the 13/EA builds in Travis.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (VFS-729) Upgrade hadoop to 2.7.4 or later; will use current 3.2.0
[ https://issues.apache.org/jira/browse/VFS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-729: - Summary: Upgrade hadoop to 2.7.4 or later; will use current 3.2.0 (was: Upgrade hadoop to 2.7.4 or later (current is 3.2.0)) > Upgrade hadoop to 2.7.4 or later; will use current 3.2.0 > > > Key: VFS-729 > URL: https://issues.apache.org/jira/browse/VFS-729 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Michiel Hendriks >Priority: Minor > > The reason why the Travis builds currently fail for JDK 13/EA is due to this > Hadoop issue: HADOOP-14586 > I've tested it locally (JDK 13, Build 33) with Hadoop 2.7.4 and all tests > pass. As this does bump the Hadoop dependency from 2.6 to >=2.7.4 you > probably want to do this for a VFS 2.5 release and in the mean time disable > the 13/EA builds in Travis. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (VFS-729) Upgrade hadoop to 2.7.4 or later (current is 3.2.0)
[ https://issues.apache.org/jira/browse/VFS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-729: - Summary: Upgrade hadoop to 2.7.4 or later (current is 3.2.0) (was: Upgrade hadoop to 2.7.4 or later) > Upgrade hadoop to 2.7.4 or later (current is 3.2.0) > --- > > Key: VFS-729 > URL: https://issues.apache.org/jira/browse/VFS-729 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Michiel Hendriks >Priority: Minor > > The reason why the Travis builds currently fail for JDK 13/EA is due to this > Hadoop issue: HADOOP-14586 > I've tested it locally (JDK 13, Build 33) with Hadoop 2.7.4 and all tests > pass. As this does bump the Hadoop dependency from 2.6 to >=2.7.4 you > probably want to do this for a VFS 2.5 release and in the mean time disable > the 13/EA builds in Travis. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CSV-250) Cannot locate field mapping on class org.apache.commons.csv.CSVRecord
[ https://issues.apache.org/jira/browse/CSV-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920416#comment-16920416 ] Gary Gregory commented on CSV-250: -- [~debriter], Do you have a stack trace? Gary > Cannot locate field mapping on class org.apache.commons.csv.CSVRecord > - > > Key: CSV-250 > URL: https://issues.apache.org/jira/browse/CSV-250 > Project: Commons CSV > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Slawomir Lisznianski >Priority: Major > > After upgrading from 1.6 to 1.7, parser invocations started to throw > IllegalArgumentException: > "Cannot locate field mapping on class org.apache.commons.csv.CSVRecord" > Reverting the project back to 1.6 resolved the problem. > javac 11.0.4 > openjdk version "11.0.4" 2019-07-16 > OpenJDK Runtime Environment (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3) > OpenJDK 64-Bit Server VM (build 11.0.4+11-post-Ubuntu-1ubuntu218.04.3, mixed > mode, sharing) > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (BCEL-327) Update signature scanning in Utility to support TypeParameters. #32
Gary Gregory created BCEL-327: - Summary: Update signature scanning in Utility to support TypeParameters. #32 Key: BCEL-327 URL: https://issues.apache.org/jira/browse/BCEL-327 Project: Commons BCEL Issue Type: Improvement Reporter: Gary Gregory Update signature scanning in Utility to support TypeParameters. #32 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (BCEL-327) Update signature scanning in Utility to support TypeParameters. #32
[ https://issues.apache.org/jira/browse/BCEL-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BCEL-327. - Fix Version/s: 6.4.0 Resolution: Fixed In git master. > Update signature scanning in Utility to support TypeParameters. #32 > --- > > Key: BCEL-327 > URL: https://issues.apache.org/jira/browse/BCEL-327 > Project: Commons BCEL > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > Fix For: 6.4.0 > > > Update signature scanning in Utility to support TypeParameters. #32 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (VFS-444) ResourceFileProvider "res://" failed to obtain FileObject from resolved FileName
[
https://issues.apache.org/jira/browse/VFS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-444.
--
Fix Version/s: (was: 2.0)
2.4.2
Resolution: Fixed
[~elmuerte] [[~eepgwde], [~kalgon]]:
In git master. Please verify and close.
[~elmuerte]: Thank you for the patch and patience! :)
Gary
> ResourceFileProvider "res://" failed to obtain FileObject from resolved
> FileName
>
>
> Key: VFS-444
> URL: https://issues.apache.org/jira/browse/VFS-444
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
> Linux x 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
>Reporter: Walter Eaves
>Priority: Major
> Labels: common-configuration
> Fix For: 2.4.2
>
> Original Estimate: 168h
> Time Spent: 20m
> Remaining Estimate: 167h 40m
>
> Given
> // See if we can find it in the resources.
> String s0 = "res://config.xml";
> FileName n0 = mgr.resolveURI(s0);
> FileObject c1 = mgr.resolveFile(new File(n0.getBaseName()), n0.getPath());
> logger.info("c1: " + c1 + " : " + c1.exists());
> The code seems to have worked because, I can see the logger has the right URL
> in the SoftResFilesCache
> 12:43:29,734 DEBUG [StandardFileSystemManager] Skipping provider
> "org.apache.commons.vfs2.provider.webdav.WebdavFileProvider" because required
> class "org.apache.jackrabbit.webdav.client.methods.DavMethod" is not
> available.
> 12:43:29,765 DEBUG [SoftRefFilesCache] putFile:
> file:///misc/build2/fpstats0/fpstats-experimental/config.xml
> 12:43:29,767 DEBUG [SoftRefFilesCache] putFile: file:///config.xml
> 12:43:29,767 INFO [Version] c1: file:///config.xml : false
> The file is there!
> But I cannot get a FileObject that gives me the absolute path.
> This would be useful for me. I want to be able to resolve a file out of the
> resources: jar files and classes/ directories. And keep that in reserve as I
> try and resolve the same file in -Duser.home and elsewhere.
> If it worked, and I believed it, I could then use the "res://config.xml" it
> for commons-configuration.
> But I can't.
> I just don't understand the API - is it complete? I can resolve a URL and get
> a FileName, but it won't tell me the FileSystem(s) without that I can't
> resolve it in this SoftResFilesCache.
> If it were me, I would just open the SoftResFilesCache and add a search for
> the base filename of a URL across all FileSystems.
> I use a filesystems to find things. I give it a hint where I saw it last and
> I want to track if it is still there and whether it has changed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (COMPRESS-493) Update optional library com.github.luben:zstd-jni from 1.4.0-1 to 1.4.3-1
[
https://issues.apache.org/jira/browse/COMPRESS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed COMPRESS-493.
-
Fix Version/s: 1.20
Resolution: Fixed
In git master.
> Update optional library com.github.luben:zstd-jni from 1.4.0-1 to 1.4.3-1
> -
>
> Key: COMPRESS-493
> URL: https://issues.apache.org/jira/browse/COMPRESS-493
> Project: Commons Compress
> Issue Type: Improvement
> Reporter: Gary Gregory
>Priority: Major
> Fix For: 1.20
>
>
> Update Optional library {{com.github.luben:zstd-jni}} from 1.4.0-1 to 1.4.3-1.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (COMPRESS-493) Update optional library com.github.luben:zstd-jni from 1.4.0-1 to 1.4.3-1
[
https://issues.apache.org/jira/browse/COMPRESS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated COMPRESS-493:
--
Summary: Update optional library com.github.luben:zstd-jni from 1.4.0-1 to
1.4.3-1 (was: Update Optional library com.github.luben:zstd-jni from 1.4.0-1
to 1.4.3-1)
> Update optional library com.github.luben:zstd-jni from 1.4.0-1 to 1.4.3-1
> -
>
> Key: COMPRESS-493
> URL: https://issues.apache.org/jira/browse/COMPRESS-493
> Project: Commons Compress
> Issue Type: Improvement
> Reporter: Gary Gregory
>Priority: Major
>
> Update Optional library {{com.github.luben:zstd-jni}} from 1.4.0-1 to 1.4.3-1.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (COMPRESS-493) Update Optional library com.github.luben:zstd-jni from 1.4.0-1 to 1.4.3-1
Gary Gregory created COMPRESS-493:
-
Summary: Update Optional library com.github.luben:zstd-jni from
1.4.0-1 to 1.4.3-1
Key: COMPRESS-493
URL: https://issues.apache.org/jira/browse/COMPRESS-493
Project: Commons Compress
Issue Type: Improvement
Reporter: Gary Gregory
Update Optional library {{com.github.luben:zstd-jni}} from 1.4.0-1 to 1.4.3-1.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (BCEL-325) ClassDumper crashes on a module-info.class
[ https://issues.apache.org/jira/browse/BCEL-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BCEL-325. - Fix Version/s: 6.4.0 Resolution: Fixed > ClassDumper crashes on a module-info.class > -- > > Key: BCEL-325 > URL: https://issues.apache.org/jira/browse/BCEL-325 > Project: Commons BCEL > Issue Type: Bug > Components: Main >Affects Versions: 6.3.1 >Reporter: Mark Roberts >Priority: Major > Fix For: 6.4.0 > > > Looks like support missing for some of the newer Class/Module flags. > I am working on changes to support these feautures. > (Possibly related, PreformanceTest fails for me when trying to build/run on > Java 9.) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (BCEL-326) Add missing Java 9 and Java 11 class file attributes. #33
[ https://issues.apache.org/jira/browse/BCEL-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated BCEL-326: -- External issue ID: 33 > Add missing Java 9 and Java 11 class file attributes. #33 > - > > Key: BCEL-326 > URL: https://issues.apache.org/jira/browse/BCEL-326 > Project: Commons BCEL > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > > Add missing Java 9 and Java 11 class file attributes. #33 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (BCEL-326) Add missing Java 9 and Java 11 class file attributes. #33
Gary Gregory created BCEL-326: - Summary: Add missing Java 9 and Java 11 class file attributes. #33 Key: BCEL-326 URL: https://issues.apache.org/jira/browse/BCEL-326 Project: Commons BCEL Issue Type: Improvement Reporter: Gary Gregory Add missing Java 9 and Java 11 class file attributes. #33 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (BCEL-326) Add missing Java 9 and Java 11 class file attributes. #33
[ https://issues.apache.org/jira/browse/BCEL-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BCEL-326. - Fix Version/s: 6.4.0 Resolution: Fixed In git master. > Add missing Java 9 and Java 11 class file attributes. #33 > - > > Key: BCEL-326 > URL: https://issues.apache.org/jira/browse/BCEL-326 > Project: Commons BCEL > Issue Type: Improvement > Reporter: Gary Gregory >Priority: Major > Fix For: 6.4.0 > > > Add missing Java 9 and Java 11 class file attributes. #33 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
[ https://issues.apache.org/jira/browse/LANG-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16917082#comment-16917082 ] Gary Gregory commented on LANG-696: --- It looks like you need to adjust some of the tests. > Deprecate ClassUtils getShortClassName in favor of Class getSimpleName > -- > > Key: LANG-696 > URL: https://issues.apache.org/jira/browse/LANG-696 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.6 >Reporter: Gary Gregory > Assignee: Gary Gregory >Priority: Major > Fix For: Discussion > > Time Spent: 10m > Remaining Estimate: 0h > > Added two null-safe ClassUtils.getSimpleName() APIs. > ------ Forwarded message -- > From: Gary Gregory > Date: Mon, Apr 11, 2011 at 10:18 AM > Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName > To: Commons Developers List > Hi All: > Should we deprecate ClassUtils getShortClassName in favor of Class > getSimpleName? > The behavior of getShortClassName is undocumented for arrays in the Javadoc > and is different from getSimpleName. > When I replace the guts of getShortClassName to call getSimpleName, one test > fails: > junit.framework.ComparisonFailure: null > expected:<[ToStringStyleTest.]Person[name=John Q. ...> but > was:<[]Person[name=John Q. ...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > org.apache.commons.lang3.builder.ShortPrefixToStringStyleTest.testPerson(ShortPrefixToStringStyleTest.java:86) > For now, I've made a note in the Javdoc to consider using getSimpleName. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (VFS-728) Update Apache Commons Compress from 1.18 to 1.19
[ https://issues.apache.org/jira/browse/VFS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-728. Fix Version/s: 2.4.2 Resolution: Fixed > Update Apache Commons Compress from 1.18 to 1.19 > > > Key: VFS-728 > URL: https://issues.apache.org/jira/browse/VFS-728 > Project: Commons VFS > Issue Type: Improvement > Reporter: Gary Gregory > Assignee: Gary Gregory >Priority: Major > Fix For: 2.4.2 > > > Update Apache Commons Compress from 1.18 to 1.19 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (VFS-728) Update Apache Commons Compress from 1.18 to 1.19
Gary Gregory created VFS-728: Summary: Update Apache Commons Compress from 1.18 to 1.19 Key: VFS-728 URL: https://issues.apache.org/jira/browse/VFS-728 Project: Commons VFS Issue Type: Improvement Reporter: Gary Gregory Assignee: Gary Gregory Update Apache Commons Compress from 1.18 to 1.19 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (VFS-727) Creation of singleton file system manager from providers
[ https://issues.apache.org/jira/browse/VFS-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved VFS-727. -- Fix Version/s: 2.4.2 Resolution: Fixed [~elmuerte] Thank you for your PRs :) In git master. Please verify and close. Gary > Creation of singleton file system manager from providers > > > Key: VFS-727 > URL: https://issues.apache.org/jira/browse/VFS-727 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.4.1 >Reporter: Michiel Hendriks >Priority: Major > Fix For: 2.4.2 > > Time Spent: 40m > Remaining Estimate: 0h > > A lot of file provides have a call to VFS.getManager() in their findFile(...) > implemention, mostly to strip of the scheme. > This is bad in two ways. > 1) it creates a global FileSystemManager if it does not exist yet, and could > result in an exception because not all default providers can be loaded (e.g. > no commons http results in class not found exceptions). This obviously also > introduces a global state. > 2) the result of VFS.getManager().getSchemes() is not the same as the schemes > registered in the file system manager that contains the registered provider. > All calls to VFS.getManager().getSchemes() should be replaced by calls to > getContext().getFileSystemManager().getSchemes() -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (POOL-326) Threading issue, NullPointerException and IllegalStateException in GenericKeyedObjectPool
[ https://issues.apache.org/jira/browse/POOL-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916639#comment-16916639 ] Gary Gregory commented on POOL-326: --- [~struberg], I agree WRT NSE vs. ISE, it is a separate detail, which is why I created a separate issue. > Threading issue, NullPointerException and IllegalStateException in > GenericKeyedObjectPool > - > > Key: POOL-326 > URL: https://issues.apache.org/jira/browse/POOL-326 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Chris Allison >Priority: Major > Fix For: 2.6.1 > > Attachments: ObjectPoolIssue.java, pool-326.patch > > > I'll included a test to help reproduce this issue. Take a look at the > embedded comments as it's extremely difficult to reproduce. I've seen the > provided test show the failure on more than one PC so I believe it will show > the problem. > Example stack trace for error on return: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at threading_pool.ObjectPoolIssue.run(ObjectPoolIssue.java:63) > at threading_pool.ObjectPoolIssue.main(ObjectPoolIssue.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) > Caused by: java.lang.NullPointerException > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:474) > at threading_pool.ObjectPoolIssue$Task.call(ObjectPoolIssue.java:112) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Example stack trace for error on borrow: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at threading_pool.ObjectPoolIssue.run(ObjectPoolIssue.java:63) > at threading_pool.ObjectPoolIssue.main(ObjectPoolIssue.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) > Caused by: java.lang.NullPointerException > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:1146) > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:438) > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:279) > at threading_pool.ObjectPoolIssue$Task.call(ObjectPoolIssue.java:108) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (POOL-326) Threading issue, NullPointerException and IllegalStateException in GenericKeyedObjectPool
[
https://issues.apache.org/jira/browse/POOL-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916200#comment-16916200
]
Gary Gregory commented on POOL-326:
---
[~psteitz]
May you please copy the performance code you are using in
{{org.apache.commons.pool2.performance}}? It seems like a good idea to keep
this code in the main repo.
> Threading issue, NullPointerException and IllegalStateException in
> GenericKeyedObjectPool
> -
>
> Key: POOL-326
> URL: https://issues.apache.org/jira/browse/POOL-326
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2
>Reporter: Chris Allison
>Priority: Major
> Fix For: 2.6.1
>
> Attachments: ObjectPoolIssue.java, pool-326.patch
>
>
> I'll included a test to help reproduce this issue. Take a look at the
> embedded comments as it's extremely difficult to reproduce. I've seen the
> provided test show the failure on more than one PC so I believe it will show
> the problem.
> Example stack trace for error on return:
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at threading_pool.ObjectPoolIssue.run(ObjectPoolIssue.java:63)
> at threading_pool.ObjectPoolIssue.main(ObjectPoolIssue.java:23)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NullPointerException
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:474)
> at threading_pool.ObjectPoolIssue$Task.call(ObjectPoolIssue.java:112)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Example stack trace for error on borrow:
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at threading_pool.ObjectPoolIssue.run(ObjectPoolIssue.java:63)
> at threading_pool.ObjectPoolIssue.main(ObjectPoolIssue.java:23)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NullPointerException
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:1146)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:438)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:279)
> at threading_pool.ObjectPoolIssue$Task.call(ObjectPoolIssue.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (POOL-326) Threading issue, NullPointerException and IllegalStateException in GenericKeyedObjectPool
[ https://issues.apache.org/jira/browse/POOL-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916184#comment-16916184 ] Gary Gregory commented on POOL-326: --- I did the ISE bit in [POOL-374] since it is related to this issue but not critical to it. > Threading issue, NullPointerException and IllegalStateException in > GenericKeyedObjectPool > - > > Key: POOL-326 > URL: https://issues.apache.org/jira/browse/POOL-326 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Chris Allison >Priority: Major > Fix For: 2.6.1 > > Attachments: ObjectPoolIssue.java, pool-326.patch > > > I'll included a test to help reproduce this issue. Take a look at the > embedded comments as it's extremely difficult to reproduce. I've seen the > provided test show the failure on more than one PC so I believe it will show > the problem. > Example stack trace for error on return: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at threading_pool.ObjectPoolIssue.run(ObjectPoolIssue.java:63) > at threading_pool.ObjectPoolIssue.main(ObjectPoolIssue.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) > Caused by: java.lang.NullPointerException > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.returnObject(GenericKeyedObjectPool.java:474) > at threading_pool.ObjectPoolIssue$Task.call(ObjectPoolIssue.java:112) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Example stack trace for error on borrow: > java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at threading_pool.ObjectPoolIssue.run(ObjectPoolIssue.java:63) > at threading_pool.ObjectPoolIssue.main(ObjectPoolIssue.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) > Caused by: java.lang.NullPointerException > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:1146) > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:438) > at > org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:279) > at threading_pool.ObjectPoolIssue$Task.call(ObjectPoolIssue.java:108) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian Jira (v8.3.2#803003)
