[jira] [Commented] (COMPRESS-637) changes-report.html does not reflect release 1.22
[ https://issues.apache.org/jira/browse/COMPRESS-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17657005#comment-17657005 ] Matt Sicker commented on COMPRESS-637: -- Oh that must be generated from somewhere. Everything else on the website [https://commons.apache.org/proper/commons-compress/] explicitly says 1.22. Can the site be patched directly, or does something need to be fixed in commons-compress itself first? Please note this was the first time I ever finished a release at Commons, so I have no idea what implicit steps are missing here; you'll need to be more explicit. > changes-report.html does not reflect release 1.22 > - > > Key: COMPRESS-637 > URL: https://issues.apache.org/jira/browse/COMPRESS-637 > Project: Commons Compress > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.22 >Reporter: MrBump >Priority: Trivial > Fix For: 1.22 > > > Webpage about releases still does not reflect that Compress 1.22 has been > released: > https://commons.apache.org/proper/commons-compress/changes-report.html > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-637) changes-report.html does not reflect release 1.22
[ https://issues.apache.org/jira/browse/COMPRESS-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656758#comment-17656758 ] Matt Sicker commented on COMPRESS-637: -- What are you talking about? I published the site from 1.22 already I thought? > changes-report.html does not reflect release 1.22 > - > > Key: COMPRESS-637 > URL: https://issues.apache.org/jira/browse/COMPRESS-637 > Project: Commons Compress > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.22 >Reporter: MrBump >Priority: Trivial > Fix For: 1.22 > > > Webpage about releases still does not reflect that Compress 1.22 has been > released: > https://commons.apache.org/proper/commons-compress/changes-report.html > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-637) changes-report.html does not reflect release 1.22
[ https://issues.apache.org/jira/browse/COMPRESS-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17656249#comment-17656249 ] Matt Sicker commented on COMPRESS-637: -- How does that get updated? I don't recall seeing anything in the release guide. > changes-report.html does not reflect release 1.22 > - > > Key: COMPRESS-637 > URL: https://issues.apache.org/jira/browse/COMPRESS-637 > Project: Commons Compress > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.22 >Reporter: MrBump >Priority: Trivial > Fix For: 1.22 > > > Webpage about releases still does not reflect that Compress 1.22 has been > released: > https://commons.apache.org/proper/commons-compress/changes-report.html > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated COMPRESS-603:
-
Assignee: Peter Lee
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.22
>
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved COMPRESS-603.
--
Fix Version/s: 1.22
Resolution: Fixed
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Priority: Major
> Fix For: 1.22
>
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17510087#comment-17510087
]
Matt Sicker commented on COMPRESS-603:
--
Alright, I finally had a chance to verify this, and I can confirm that your
commit fixes the issue. I reproduced the problem with a basic unit test which
fails with 1.21 but passes with a snapshot of 1.22. Thanks!
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Priority: Major
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489035#comment-17489035
]
Matt Sicker commented on COMPRESS-603:
--
I see two potential things that may be contributing to my initial issue:
# In my affected code, I extract a tarball to a directory created via
{{{}Files.createTempDirectory().toFile(){}}}; on Linux, this ends up somewhere
in {{{}/tmp{}}}, though I wonder how this would work if the Java tmpdir is a
symlink.
# The affected tarball I was initially notified about has a more complex
directory structure, but the exception was thrown when the {{./}} directory
entry at the beginning of the tar file was attempted to be made. Running {{tar
tf}} on the file shows something like:
{{./}}
{{./foo/}}
{{./foo/bar/}}
{{./foo/bar/baz.txt}}
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Priority: Major
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488585#comment-17488585
]
Matt Sicker commented on COMPRESS-603:
--
I'll have to reproduce this issue again. I'll get further details from there.
Did you use GNU tar, bsdtar, or something else when you first tried to create
foo.tar yourself? I used GNU tar for the attached file, though it might be an
issue with other tar files.
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Priority: Major
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488298#comment-17488298
]
Matt Sicker commented on COMPRESS-603:
--
Added a basic test file.
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Priority: Major
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
[
https://issues.apache.org/jira/browse/COMPRESS-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated COMPRESS-603:
-
Attachment: test.tar.gz
> Expander does not support archives with archive entries beginning with ./
> -
>
> Key: COMPRESS-603
> URL: https://issues.apache.org/jira/browse/COMPRESS-603
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.21
>Reporter: Matt Sicker
>Priority: Major
> Attachments: test.tar.gz
>
>
> Suppose I create a tar file from a directory like so:
>
> {code:java}
> tar -cf foo.tar ./foo{code}
> When I try to extract the tar entries using the Expander class, that throws a
> java.io.IOException: Expanding ./ would create file outside of ...
> When I create the tar file without the leading ./, then Expander doesn't
> complain.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (COMPRESS-603) Expander does not support archives with archive entries beginning with ./
Matt Sicker created COMPRESS-603:
Summary: Expander does not support archives with archive entries
beginning with ./
Key: COMPRESS-603
URL: https://issues.apache.org/jira/browse/COMPRESS-603
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.21
Reporter: Matt Sicker
Suppose I create a tar file from a directory like so:
{code:java}
tar -cf foo.tar ./foo{code}
When I try to extract the tar entries using the Expander class, that throws a
java.io.IOException: Expanding ./ would create file outside of ...
When I create the tar file without the leading ./, then Expander doesn't
complain.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CODEC-296) Add support for Blake3 family of hashes
[ https://issues.apache.org/jira/browse/CODEC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved CODEC-296. --- Resolution: Fixed Merged to master for the next release. > Add support for Blake3 family of hashes > --- > > Key: CODEC-296 > URL: https://issues.apache.org/jira/browse/CODEC-296 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 1.16 > > > Brief historical context: the original Blake hash algorithm was a finalist in > the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], > has several variants, the most popular seem to be Blake2b and Blake2s, though > there are a few others that are tuned and tweaked for different use cases. > This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third > version of the hash algorithm which unifies the variants into a single > interface along with further tuned security parameters for increased > performance with negligible impact on security. > Blake3 is extremely versatile and offers interfaces to use it as a message > digest (hash) function, pseudorandom function (PRF), a message authentication > code (MAC), a key derivation function (KDF), and an extensible output > function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) > while remaining secure which makes it handy for less security-intensive > contexts, too, like file hashing. > While implementing a MessageDigestSpi is fairly straightforward, a MacSpi > needs to be loaded from a signed jar which would complicate things a bit > here. A generic commons API here might be easiest to deal with (previous idea > of SHO API is a higher level feature). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CODEC-296) Add support for Blake3 family of hashes
[ https://issues.apache.org/jira/browse/CODEC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated CODEC-296: -- Fix Version/s: 1.16 > Add support for Blake3 family of hashes > --- > > Key: CODEC-296 > URL: https://issues.apache.org/jira/browse/CODEC-296 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Fix For: 1.16 > > > Brief historical context: the original Blake hash algorithm was a finalist in > the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], > has several variants, the most popular seem to be Blake2b and Blake2s, though > there are a few others that are tuned and tweaked for different use cases. > This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third > version of the hash algorithm which unifies the variants into a single > interface along with further tuned security parameters for increased > performance with negligible impact on security. > Blake3 is extremely versatile and offers interfaces to use it as a message > digest (hash) function, pseudorandom function (PRF), a message authentication > code (MAC), a key derivation function (KDF), and an extensible output > function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) > while remaining secure which makes it handy for less security-intensive > contexts, too, like file hashing. > While implementing a MessageDigestSpi is fairly straightforward, a MacSpi > needs to be loaded from a signed jar which would complicate things a bit > here. A generic commons API here might be easiest to deal with (previous idea > of SHO API is a higher level feature). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CODEC-296) Add support for Blake3 family of hashes
[ https://issues.apache.org/jira/browse/CODEC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated CODEC-296: -- Description: Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security. Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing. While implementing a MessageDigestSpi is fairly straightforward, a MacSpi needs to be loaded from a signed jar which would complicate things a bit here. A generic commons API here might be easiest to deal with (previous idea of SHO API is a higher level feature). was: Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security. Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing. While implementing a MessageDigestSpi is fairly straightforward, a MacSpi needs to be loaded from a signed jar which would complicate things a bit here. A more appropriate cryptographic API that encompasses all the above functionality would be an interface like the [stateful hash object (SHO)|https://github.com/noiseprotocol/sho_spec/blob/master/output/sho.pdf] from the noise protocol. > Add support for Blake3 family of hashes > --- > > Key: CODEC-296 > URL: https://issues.apache.org/jira/browse/CODEC-296 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > > Brief historical context: the original Blake hash algorithm was a finalist in > the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], > has several variants, the most popular seem to be Blake2b and Blake2s, though > there are a few others that are tuned and tweaked for different use cases. > This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third > version of the hash algorithm which unifies the variants into a single > interface along with further tuned security parameters for increased > performance with negligible impact on security. > Blake3 is extremely versatile and offers interfaces to use it as a message > digest (hash) function, pseudorandom function (PRF), a message authentication > code (MAC), a key derivation function (KDF), and an extensible output > function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) > while remaining secure which makes it handy for less security-intensive > contexts, too, like file hashing. > While implementing a MessageDigestSpi is fairly straightforward, a MacSpi > needs to be loaded from a signed jar which would complicate things a bit > here. A generic commons API here might be easiest to deal with (previous idea > of SHO API is a higher level feature). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CODEC-296) Add support for Blake3 family of hashes
[ https://issues.apache.org/jira/browse/CODEC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated CODEC-296: -- Description: Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security. Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing. While implementing a MessageDigestSpi is fairly straightforward, a MacSpi needs to be loaded from a signed jar which would complicate things a bit here. A more appropriate cryptographic API that encompasses all the above functionality would be an interface like the [stateful hash object (SHO)|https://github.com/noiseprotocol/sho_spec/blob/master/output/sho.pdf] from the noise protocol. was: Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security. Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing. I've previously ported the reference public domain Rust implementation to Java for another use case, so the algorithm itself is pretty simple to add here. This library doesn't define any interfaces for these concerns, though the Java crypto API does have some equivalents for most of those use cases, but they might be overkill for this. > Add support for Blake3 family of hashes > --- > > Key: CODEC-296 > URL: https://issues.apache.org/jira/browse/CODEC-296 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > > Brief historical context: the original Blake hash algorithm was a finalist in > the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], > has several variants, the most popular seem to be Blake2b and Blake2s, though > there are a few others that are tuned and tweaked for different use cases. > This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third > version of the hash algorithm which unifies the variants into a single > interface along with further tuned security parameters for increased > performance with negligible impact on security. > Blake3 is extremely versatile and offers interfaces to use it as a message > digest (hash) function, pseudorandom function (PRF), a message authentication > code (MAC), a key derivation function (KDF), and an extensible output > function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) > while remaining secure which makes it handy for less security-intensive > contexts, too, like file hashing. > While implementing a MessageDigestSpi is fairly straightforward, a MacSpi > needs to be loaded from a signed jar which would complicate things a bit > here. A more appropriate cryptographic API that encompasses all the above > functionality would be an interface like the [stateful hash object > (SHO)|https://github.com/noiseprotocol/sho_spec/blob/master/output/sho.pdf] > from the noise protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CODEC-296) Add support for Blake3 family of hashes
Matt Sicker created CODEC-296: - Summary: Add support for Blake3 family of hashes Key: CODEC-296 URL: https://issues.apache.org/jira/browse/CODEC-296 Project: Commons Codec Issue Type: New Feature Reporter: Matt Sicker Assignee: Matt Sicker Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security. Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing. I've previously ported the reference public domain Rust implementation to Java for another use case, so the algorithm itself is pretty simple to add here. This library doesn't define any interfaces for these concerns, though the Java crypto API does have some equivalents for most of those use cases, but they might be overkill for this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FUNCTOR-31) Clean up API for Java 8
[ https://issues.apache.org/jira/browse/FUNCTOR-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899506#comment-16899506 ] Matt Sicker commented on FUNCTOR-31: Upon further exploration, if we went to Java 8 for this component, then a lot of other code can be removed or refactored into lambdas. All the adapter classes are unnecessary thanks to SAM and lambda functions in general. The aggregator classes can likely be combined functionally with the Java 8 Collector API. The comparators and composites are also available in Java 8 already. The generator classes seem related to collectors and streams. The collection classes look useful since Java 8 never provided functional versions of Iterator despite being similar to Stream/Spliterator. The range types as well. Some expansion on other common type classes would be super useful, though not necessarily part of this. What remains after removing all that is hard to say. > Clean up API for Java 8 > --- > > Key: FUNCTOR-31 > URL: https://issues.apache.org/jira/browse/FUNCTOR-31 > Project: Commons Functor > Issue Type: New Feature >Reporter: Matt Sicker >Priority: Major > > All the interfaces from commons-functor-api have equivalent interfaces in > java.util.function. Several functor implementation classes in the core module > can also be simplified thanks to lambda functions. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (FUNCTOR-31) Clean up API for Java 8
Matt Sicker created FUNCTOR-31: -- Summary: Clean up API for Java 8 Key: FUNCTOR-31 URL: https://issues.apache.org/jira/browse/FUNCTOR-31 Project: Commons Functor Issue Type: New Feature Reporter: Matt Sicker All the interfaces from commons-functor-api have equivalent interfaces in java.util.function. Several functor implementation classes in the core module can also be simplified thanks to lambda functions. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IO-596) Add DeleteFiles utility class for more robust file deletion strategies
Matt Sicker created IO-596: -- Summary: Add DeleteFiles utility class for more robust file deletion strategies Key: IO-596 URL: https://issues.apache.org/jira/browse/IO-596 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Matt Sicker Assignee: Matt Sicker Particularly for Windows environments where deleting files can turn into a hassle due to the inability to remove open files, I would like to provide a file deletion utility class that has the ability to retry deletions with exponential backoff, force override file attributes to allow for deletion, and deleting as much as possible while accumulating errors. This functionality was originally inspired by and based on functionality in Jenkins hudson.Util class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IO-596) Add DeleteFiles utility class for more robust file deletion strategies
[ https://issues.apache.org/jira/browse/IO-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729211#comment-16729211 ] Matt Sicker commented on IO-596: Added link to PR. > Add DeleteFiles utility class for more robust file deletion strategies > -- > > Key: IO-596 > URL: https://issues.apache.org/jira/browse/IO-596 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: Matt Sicker >Assignee: Matt Sicker >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Particularly for Windows environments where deleting files can turn into a > hassle due to the inability to remove open files, I would like to provide a > file deletion utility class that has the ability to retry deletions with > exponential backoff, force override file attributes to allow for deletion, > and deleting as much as possible while accumulating errors. > This functionality was originally inspired by and based on functionality in > Jenkins hudson.Util class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IO-595) Add similar util class as FileUtils for java.nio.file.Path
[ https://issues.apache.org/jira/browse/IO-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16727081#comment-16727081 ] Matt Sicker commented on IO-595: Added some proposals to the description. > Add similar util class as FileUtils for java.nio.file.Path > -- > > Key: IO-595 > URL: https://issues.apache.org/jira/browse/IO-595 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: Matt Sicker >Priority: Major > > There are several utility methods in FileUtils that are not present in the > Java 7 Files API for Path. These would make up a useful basis for a PathUtils > class to complement Java's java.nio.file package. Below is a listing of > method ideas adapted from FileUtils for Path that are not already covered by > java.nio.file.Files or trivially adapted to something there. > * touch(Path) > * contentEquals(Path, Path) > * copyDirectoryToDirectory(Path, Path, CopyOption...) > * copyDirectory(Path, Path, CopyOption...) > * copyDirectory(Path, Path, PathMatcher, CopyOption...) > * deleteDirectory(Path) > * deleteQuietly(Path) > * directoryContains(Path, Path) > * cleanDirectory(Path) > * waitFor(Path, long, TimeUnit) > * forceDelete(Path) > * forceDeleteOnExit(Path) > * forceMkdir(Path) > * forceMkdirParent(Path) > * sizeOfDirectory(Path) - probably just return BigInteger only -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IO-595) Add similar util class as FileUtils for java.nio.file.Path
[ https://issues.apache.org/jira/browse/IO-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated IO-595: --- Description: There are several utility methods in FileUtils that are not present in the Java 7 Files API for Path. These would make up a useful basis for a PathUtils class to complement Java's java.nio.file package. Below is a listing of method ideas adapted from FileUtils for Path that are not already covered by java.nio.file.Files or trivially adapted to something there. * touch(Path) * contentEquals(Path, Path) * copyDirectoryToDirectory(Path, Path, CopyOption...) * copyDirectory(Path, Path, CopyOption...) * copyDirectory(Path, Path, PathMatcher, CopyOption...) * deleteDirectory(Path) * deleteQuietly(Path) * directoryContains(Path, Path) * cleanDirectory(Path) * waitFor(Path, long, TimeUnit) * forceDelete(Path) * forceDeleteOnExit(Path) * forceMkdir(Path) * forceMkdirParent(Path) * sizeOfDirectory(Path) - probably just return BigInteger only was:There are several utility methods in FileUtils that are not present in the Java 7 Files API for Path. These would make up a useful basis for a PathUtils class to complement Java's java.nio.file package. > Add similar util class as FileUtils for java.nio.file.Path > -- > > Key: IO-595 > URL: https://issues.apache.org/jira/browse/IO-595 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Reporter: Matt Sicker >Priority: Major > > There are several utility methods in FileUtils that are not present in the > Java 7 Files API for Path. These would make up a useful basis for a PathUtils > class to complement Java's java.nio.file package. Below is a listing of > method ideas adapted from FileUtils for Path that are not already covered by > java.nio.file.Files or trivially adapted to something there. > * touch(Path) > * contentEquals(Path, Path) > * copyDirectoryToDirectory(Path, Path, CopyOption...) > * copyDirectory(Path, Path, CopyOption...) > * copyDirectory(Path, Path, PathMatcher, CopyOption...) > * deleteDirectory(Path) > * deleteQuietly(Path) > * directoryContains(Path, Path) > * cleanDirectory(Path) > * waitFor(Path, long, TimeUnit) > * forceDelete(Path) > * forceDeleteOnExit(Path) > * forceMkdir(Path) > * forceMkdirParent(Path) > * sizeOfDirectory(Path) - probably just return BigInteger only -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IO-595) Add similar util class as FileUtils for java.nio.file.Path
Matt Sicker created IO-595: -- Summary: Add similar util class as FileUtils for java.nio.file.Path Key: IO-595 URL: https://issues.apache.org/jira/browse/IO-595 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Matt Sicker There are several utility methods in FileUtils that are not present in the Java 7 Files API for Path. These would make up a useful basis for a PathUtils class to complement Java's java.nio.file package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IO-576) FileUtils.deleteDirectory() doesn't specify how it handles links
[ https://issues.apache.org/jira/browse/IO-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726932#comment-16726932 ] Matt Sicker commented on IO-576: Looking into the source, it does not recurse into symbolic links, though it does call delete on the symbolic link itself. The specific behavior of following links seems to be undefined (though it is supported in the NIO2 API). I wonder if this would be better served by an equivalent util class around Path instead of File. > FileUtils.deleteDirectory() doesn't specify how it handles links > > > Key: IO-576 > URL: https://issues.apache.org/jira/browse/IO-576 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.5 > Environment: Linux >Reporter: david cogen >Priority: Major > Labels: documentation > > If the directory I specify to FileUtils.deleteDirectory() contains a symbolic > link, does it follow the link and delete all the files the link points to? > (I HOPE not!) > But without the promise, I consider this too dangerous to contemplate using. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (POOL-335) Make abandoned logging stack trace requirements configurable
[ https://issues.apache.org/jira/browse/POOL-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved POOL-335. -- Resolution: Fixed Added to master. > Make abandoned logging stack trace requirements configurable > > > Key: POOL-335 > URL: https://issues.apache.org/jira/browse/POOL-335 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.5 > > > The feature introduced by POOL-320 causes abandoned connection logs to only > output the class names of the call stack. This feature would make this > configurable along with reverting the default behavior to use the full stack > trace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (POOL-335) Make abandoned logging stack trace requirements configurable
[ https://issues.apache.org/jira/browse/POOL-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated POOL-335: - Fix Version/s: (was: 2.4.4) 2.5 > Make abandoned logging stack trace requirements configurable > > > Key: POOL-335 > URL: https://issues.apache.org/jira/browse/POOL-335 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 2.4.3 >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.5 > > > The feature introduced by POOL-320 causes abandoned connection logs to only > output the class names of the call stack. This feature would make this > configurable along with reverting the default behavior to use the full stack > trace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (POOL-335) Make abandoned logging stack trace requirements configurable
Matt Sicker created POOL-335: Summary: Make abandoned logging stack trace requirements configurable Key: POOL-335 URL: https://issues.apache.org/jira/browse/POOL-335 Project: Commons Pool Issue Type: New Feature Affects Versions: 2.4.3 Reporter: Matt Sicker Assignee: Matt Sicker Fix For: 2.4.4 The feature introduced by POOL-320 causes abandoned connection logs to only output the class names of the call stack. This feature would make this configurable along with reverting the default behavior to use the full stack trace. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (POOL-320) Use more efficient stack walking mechanisms for usage tracking
[ https://issues.apache.org/jira/browse/POOL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved POOL-320. -- Resolution: Fixed > Use more efficient stack walking mechanisms for usage tracking > -- > > Key: POOL-320 > URL: https://issues.apache.org/jira/browse/POOL-320 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.4.2 >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.4.3 > > > When usage tracking is enabled, pooled object users are discovered by > creating an exception. This is slower than optimal which could be done via > various strategies such as a SecurityManager, reflection on the internal > Reflection class, or for Java 9 users, the new StackWalker API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (POOL-320) Use more efficient stack walking mechanisms for usage tracking
[ https://issues.apache.org/jira/browse/POOL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reopened POOL-320: -- Reopening to mark as resolved instead of closed as all other issues marked for 2.4.3 are only resolved. > Use more efficient stack walking mechanisms for usage tracking > -- > > Key: POOL-320 > URL: https://issues.apache.org/jira/browse/POOL-320 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.4.2 >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.4.3 > > > When usage tracking is enabled, pooled object users are discovered by > creating an exception. This is slower than optimal which could be done via > various strategies such as a SecurityManager, reflection on the internal > Reflection class, or for Java 9 users, the new StackWalker API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (POOL-320) Use more efficient stack walking mechanisms for usage tracking
[ https://issues.apache.org/jira/browse/POOL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed POOL-320. Resolution: Fixed Fix Version/s: 2.4.3 Added in subversion revision 1785520 in trunk. > Use more efficient stack walking mechanisms for usage tracking > -- > > Key: POOL-320 > URL: https://issues.apache.org/jira/browse/POOL-320 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.4.2 >Reporter: Matt Sicker >Assignee: Matt Sicker > Fix For: 2.4.3 > > > When usage tracking is enabled, pooled object users are discovered by > creating an exception. This is slower than optimal which could be done via > various strategies such as a SecurityManager, reflection on the internal > Reflection class, or for Java 9 users, the new StackWalker API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (POOL-320) Use more efficient stack walking mechanisms for usage tracking
[ https://issues.apache.org/jira/browse/POOL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated POOL-320: - Assignee: Matt Sicker > Use more efficient stack walking mechanisms for usage tracking > -- > > Key: POOL-320 > URL: https://issues.apache.org/jira/browse/POOL-320 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.4.2 >Reporter: Matt Sicker >Assignee: Matt Sicker > > When usage tracking is enabled, pooled object users are discovered by > creating an exception. This is slower than optimal which could be done via > various strategies such as a SecurityManager, reflection on the internal > Reflection class, or for Java 9 users, the new StackWalker API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (POOL-320) Use more efficient stack walking mechanisms for usage tracking
Matt Sicker created POOL-320: Summary: Use more efficient stack walking mechanisms for usage tracking Key: POOL-320 URL: https://issues.apache.org/jira/browse/POOL-320 Project: Commons Pool Issue Type: Improvement Affects Versions: 2.4.2 Reporter: Matt Sicker When usage tracking is enabled, pooled object users are discovered by creating an exception. This is slower than optimal which could be done via various strategies such as a SecurityManager, reflection on the internal Reflection class, or for Java 9 users, the new StackWalker API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[
https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412100#comment-15412100
]
Matt Sicker commented on DBCP-454:
--
I don't think that partial thing is correct, either. I get the following error
when installing this new version in Karaf 3.0.4:
{noformat}
java.lang.Exception: Could not start bundle
mvn:org.apache.commons/commons-dbcp2/2.2 in feature(s) commons-dbcp2-2.2:
Unresolved constraint in bundle org.apache.commons.dbcp2 [269]: Unable to
resolve 269.0: missing requirement [269.0] osgi.wiring.package;
(&(osgi.wiring.package=javax.transaction.xa)(version>=1.1.0)(partial=true))
at
org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:521)[20:org.apache.karaf.features.core:3.0.4]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:476)[20:org.apache.karaf.features.core:3.0.4]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:417)[20:org.apache.karaf.features.core:3.0.4]
at Proxy3ddcd89e_6018_4343_b5b3_8693418616e1.installFeature(Unknown
Source)[:]
at Proxy1c5ca9a8_a504_40c1_a273_6f4767d76de4.installFeature(Unknown
Source)[:]
at
org.apache.karaf.kar.internal.KarServiceImpl.installFeatures(KarServiceImpl.java:215)[109:org.apache.karaf.kar.core:3.0.4]
at
org.apache.karaf.kar.internal.KarServiceImpl.install(KarServiceImpl.java:96)[109:org.apache.karaf.kar.core:3.0.4]
at
org.apache.karaf.kar.internal.KarServiceImpl.install(KarServiceImpl.java:84)[109:org.apache.karaf.kar.core:3.0.4]
at Proxy670dd4c1_ba32_408b_9988_4daea71b6bc9.install(Unknown Source)[:]
at Proxye95b24d0_c408_4277_a3ea_4b500b9f30a0.install(Unknown Source)[:]
at
org.apache.karaf.deployer.kar.KarArtifactInstaller.install(KarArtifactInstaller.java:50)[111:org.apache.karaf.deployer.kar:3.0.4]
at Proxy370ffdac_0056_40be_877f_c9735fc99d7c.install(Unknown Source)[:]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:931)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:865)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:482)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[7:org.apache.felix.fileinstall:3.5.0]
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.commons.dbcp2 [269]: Unable to resolve 269.0: missing requirement
[269.0] osgi.wiring.package;
(&(osgi.wiring.package=javax.transaction.xa)(version>=1.1.0)(partial=true))
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2037)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:518)[20:org.apache.karaf.features.core:3.0.4]
... 16 more
{noformat}
I've installed the transaction feature first which imports JTA 1.1.0, so it's
definitely available.
> OSGi declarations contain multiple import headers for javax.transaction
> ---
>
> Key: DBCP-454
> URL: https://issues.apache.org/jira/browse/DBCP-454
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: OSGi
>Reporter: Philipp Marx
>Assignee: Matt Sicker
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: patch
>
>
> In DBCP-445 an issue for "javax.transaction" import-packages was addressed.
> Though with the fix for this issue the import-packages will contain
> "javax.transaction" twice:
> Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s
> ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging,
> org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact
> ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact
> ion;version="1.1.0"
> Thus the bundle can't be loaded as duplicate import declarations are
> prohibited and i.e. Felix will complain about this and refus
[jira] [Comment Edited] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[
https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15412100#comment-15412100
]
Matt Sicker edited comment on DBCP-454 at 8/8/16 5:18 PM:
--
I don't think that partial thing is correct, either. I get the following error
when installing this new version in Karaf 3.0.4:
{noformat}
java.lang.Exception: Could not start bundle
mvn:org.apache.commons/commons-dbcp2/2.2 in feature(s) commons-dbcp2-2.2:
Unresolved constraint in bundle org.apache.commons.dbcp2 [269]: Unable to
resolve 269.0: missing requirement [269.0] osgi.wiring.package;
(&(osgi.wiring.package=javax.transaction.xa)(version>=1.1.0)(partial=true))
at
org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:521)[20:org.apache.karaf.features.core:3.0.4]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:476)[20:org.apache.karaf.features.core:3.0.4]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:417)[20:org.apache.karaf.features.core:3.0.4]
at Proxy3ddcd89e_6018_4343_b5b3_8693418616e1.installFeature(Unknown
Source)[:]
at Proxy1c5ca9a8_a504_40c1_a273_6f4767d76de4.installFeature(Unknown
Source)[:]
at
org.apache.karaf.kar.internal.KarServiceImpl.installFeatures(KarServiceImpl.java:215)[109:org.apache.karaf.kar.core:3.0.4]
at
org.apache.karaf.kar.internal.KarServiceImpl.install(KarServiceImpl.java:96)[109:org.apache.karaf.kar.core:3.0.4]
at
org.apache.karaf.kar.internal.KarServiceImpl.install(KarServiceImpl.java:84)[109:org.apache.karaf.kar.core:3.0.4]
at Proxy670dd4c1_ba32_408b_9988_4daea71b6bc9.install(Unknown Source)[:]
at Proxye95b24d0_c408_4277_a3ea_4b500b9f30a0.install(Unknown Source)[:]
at
org.apache.karaf.deployer.kar.KarArtifactInstaller.install(KarArtifactInstaller.java:50)[111:org.apache.karaf.deployer.kar:3.0.4]
at Proxy370ffdac_0056_40be_877f_c9735fc99d7c.install(Unknown Source)[:]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:931)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:865)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:482)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[7:org.apache.felix.fileinstall:3.5.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[7:org.apache.felix.fileinstall:3.5.0]
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.commons.dbcp2 [269]: Unable to resolve 269.0: missing requirement
[269.0] osgi.wiring.package;
(&(osgi.wiring.package=javax.transaction.xa)(version>=1.1.0)(partial=true))
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.Felix.startBundle(Felix.java:2037)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942)[org.apache.felix.framework-4.2.1.jar:]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:518)[20:org.apache.karaf.features.core:3.0.4]
... 16 more
{noformat}
I've installed the transaction feature first which imports JTA 1.1.0, so it's
definitely available.
Also, some info about this partial/mandatory hack:
http://apache-geronimo.328035.n3.nabble.com/Understanding-the-quot-partial-true-mandatory-partial-quot-trick-td396729.html
was (Author: jvz):
I don't think that partial thing is correct, either. I get the following error
when installing this new version in Karaf 3.0.4:
{noformat}
java.lang.Exception: Could not start bundle
mvn:org.apache.commons/commons-dbcp2/2.2 in feature(s) commons-dbcp2-2.2:
Unresolved constraint in bundle org.apache.commons.dbcp2 [269]: Unable to
resolve 269.0: missing requirement [269.0] osgi.wiring.package;
(&(osgi.wiring.package=javax.transaction.xa)(version>=1.1.0)(partial=true))
at
org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:521)[20:org.apache.karaf.features.core:3.0.4]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:476)[20:org.apache.karaf.features.core:3.0.4]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:417)[20:org.apache.karaf.featur
[jira] [Reopened] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reopened DBCP-454: -- > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.2 > > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404834#comment-15404834 ] Matt Sicker commented on DBCP-454: -- I've created DBCP-467 to add such a test here at least. Maybe it could end up being generified to a sort of commons-osgi-itest type of artifact that can be included as a test-scoped dependency on each commons project. Then each project can reuse those generic tests. > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.2 > > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DBCP-467) Add OSGi integration tests
Matt Sicker created DBCP-467: Summary: Add OSGi integration tests Key: DBCP-467 URL: https://issues.apache.org/jira/browse/DBCP-467 Project: Commons Dbcp Issue Type: Improvement Environment: OSGi 4.3 or 5.0 Reporter: Matt Sicker It would be nice to have a proper integration test with an OSGi container such as Felix, Equinox, or even Karaf. This test should verify that DBCP installs properly into an OSGi container and can be used as such. This test could use [pax exam|https://ops4j1.jira.com/wiki/display/PAXEXAM4/Documentation] or something simpler if feasible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404817#comment-15404817 ] Matt Sicker commented on DBCP-454: -- It would be really neat to make a more commons-friendly generic unit test that can be copied around to make sure that each component properly installs into an OSGi container. > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.2 > > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404789#comment-15404789 ] Matt Sicker commented on DBCP-454: -- Yeah, basically. That's how pax-exam is supposed to work by default which sounds rather out of place when you're trying to integration test modules in the same repository (e.g., snapshot builds). I might be reading the documentation wrong, but even that is unhelpful as all the examples are too trivial. > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.2 > > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404769#comment-15404769 ] Matt Sicker commented on DBCP-454: -- Log4j doesn't require any dependencies, but dbcp does, so it makes it a lot more complicated than the AbstractLoadBundleTest from Log4j. I figured pax-exam would provide the capability of adding all those dependencies for me, but then I got other errors instead that are unrelated to dbcp or osgi. [Here's a related test|https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-itest/src/test/java/org/ops4j/pax/jdbc/test/pool/PoolDbcp2Test.java] that would fail if dbcp itself was exporting the wrong headers (as with this bug). The thing is with pax projects is that these types of tests are run in a separate maven module, presumably to prevent the issues I was having, and that would require a restructuring of dbcp which is rather complicated. > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Fix For: 2.2 > > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[
https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved DBCP-454.
--
Resolution: Fixed
Fix Version/s: 2.2
Fixed in revision 1754999. I gave up on trying to make a pax-exam unit test as
it's far too complicated to get working for this type of use case. Right now,
the best way to verify that this works is to simply install the jar (and
dependencies) to a Karaf container and make sure you can run {{bundle:start}}
on it. More proper OSGi tests are included in the [pax-jdbc
version|https://github.com/ops4j/org.ops4j.pax.jdbc/tree/master/pax-jdbc-pool-dbcp2]
of dbcp2.
> OSGi declarations contain multiple import headers for javax.transaction
> ---
>
> Key: DBCP-454
> URL: https://issues.apache.org/jira/browse/DBCP-454
> Project: Commons Dbcp
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: OSGi
>Reporter: Philipp Marx
>Assignee: Matt Sicker
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: patch
>
>
> In DBCP-445 an issue for "javax.transaction" import-packages was addressed.
> Though with the fix for this issue the import-packages will contain
> "javax.transaction" twice:
> Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s
> ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging,
> org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact
> ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact
> ion;version="1.1.0"
> Thus the bundle can't be loaded as duplicate import declarations are
> prohibited and i.e. Felix will complain about this and refuse to install the
> bundle. The fix is quite simple by appending the '*' to the end (see attached
> patch).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (DBCP-466) Upgrade test scoped Geronimo Transaction to 2.2.1
[
https://issues.apache.org/jira/browse/DBCP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed DBCP-466.
Resolution: Invalid
Well, it worked the first time for some reason, but when I built again,
everything exploded. Nevermind.
> Upgrade test scoped Geronimo Transaction to 2.2.1
> -
>
> Key: DBCP-466
> URL: https://issues.apache.org/jira/browse/DBCP-466
> Project: Commons Dbcp
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Matt Sicker
>
> An old comment states,
> {quote}
>Cannot update this currently; anything later causes failures:
>java.lang.NoClassDefFoundError:
>Could not initialize class
> org.apache.geronimo.transaction.manager.TransactionManagerImpl
> {quote}
> However, upon testing with 2.2.1, this is no longer an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DBCP-466) Upgrade test scoped Geronimo Transaction to 2.2.1
Matt Sicker created DBCP-466:
Summary: Upgrade test scoped Geronimo Transaction to 2.2.1
Key: DBCP-466
URL: https://issues.apache.org/jira/browse/DBCP-466
Project: Commons Dbcp
Issue Type: Improvement
Affects Versions: 2.2
Reporter: Matt Sicker
An old comment states,
{quote}
Cannot update this currently; anything later causes failures:
java.lang.NoClassDefFoundError:
Could not initialize class
org.apache.geronimo.transaction.manager.TransactionManagerImpl
{quote}
However, upon testing with 2.2.1, this is no longer an issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404640#comment-15404640 ] Matt Sicker commented on DBCP-454: -- It looks like version 1.1 is needed at least (DBCP-445), so a version range would be more appropriate anyways. That's the problem with Java EE APIs; they aren't versioned properly for OSGi. > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404568#comment-15404568 ] Matt Sicker commented on DBCP-454: -- I cam across this issue during the 2.2 rc1. I came to the same conclusion as the patch here (see the duplicate ticket). I'm trying to get a working unit test using pax-exam, but it's a bit more difficult than I expected. > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Assignee: Matt Sicker >Priority: Blocker > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (DBCP-465) OSGi import-package has repeated packages causing a runtime failure
[
https://issues.apache.org/jira/browse/DBCP-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed DBCP-465.
Resolution: Fixed
> OSGi import-package has repeated packages causing a runtime failure
> ---
>
> Key: DBCP-465
> URL: https://issues.apache.org/jira/browse/DBCP-465
> Project: Commons Dbcp
> Issue Type: Bug
> Environment: Karaf 3.0.4, Java 8, DBCP 2.2 rc1
>Reporter: Matt Sicker
>Assignee: Matt Sicker
>Priority: Blocker
>
> Building from trunk or 2.2rc1, here's the import-package manifest:
> {code}
> Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s
> ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging,
> org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact
> ion;version="1.1.0",javax.transaction.xa;version="1.1.0";partial=true
> ;mandatory:=partial
> {code}
> As can be seen, the JTA packages are being imported twice. This is causing a
> runtime failure in Karaf on startup of this bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-454) OSGi declarations contain multiple import headers for javax.transaction
[ https://issues.apache.org/jira/browse/DBCP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated DBCP-454: - Priority: Blocker (was: Trivial) > OSGi declarations contain multiple import headers for javax.transaction > --- > > Key: DBCP-454 > URL: https://issues.apache.org/jira/browse/DBCP-454 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 2.2 > Environment: OSGi >Reporter: Philipp Marx >Priority: Blocker > Attachments: patch > > > In DBCP-445 an issue for "javax.transaction" import-packages was addressed. > Though with the fix for this issue the import-packages will contain > "javax.transaction" twice: > Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s > ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging, > org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact > ion.xa;version="1.1.0";partial=true;mandatory:=partial,javax.transact > ion;version="1.1.0" > Thus the bundle can't be loaded as duplicate import declarations are > prohibited and i.e. Felix will complain about this and refuse to install the > bundle. The fix is quite simple by appending the '*' to the end (see attached > patch). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DBCP-465) OSGi import-package has repeated packages causing a runtime failure
[
https://issues.apache.org/jira/browse/DBCP-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404385#comment-15404385
]
Matt Sicker commented on DBCP-465:
--
It appears the issue was because of where the {{*}} was located in the
{{Import-Package}} instruction in the pom. Putting it at the end generate the
correct manifest. I'd like to add a unit test, though, and that's less trivial.
> OSGi import-package has repeated packages causing a runtime failure
> ---
>
> Key: DBCP-465
> URL: https://issues.apache.org/jira/browse/DBCP-465
> Project: Commons Dbcp
> Issue Type: Bug
> Environment: Karaf 3.0.4, Java 8, DBCP 2.2 rc1
>Reporter: Matt Sicker
>Priority: Blocker
>
> Building from trunk or 2.2rc1, here's the import-package manifest:
> {code}
> Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s
> ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging,
> org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact
> ion;version="1.1.0",javax.transaction.xa;version="1.1.0";partial=true
> ;mandatory:=partial
> {code}
> As can be seen, the JTA packages are being imported twice. This is causing a
> runtime failure in Karaf on startup of this bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DBCP-465) OSGi import-package has repeated packages causing a runtime failure
Matt Sicker created DBCP-465:
Summary: OSGi import-package has repeated packages causing a
runtime failure
Key: DBCP-465
URL: https://issues.apache.org/jira/browse/DBCP-465
Project: Commons Dbcp
Issue Type: Bug
Environment: Karaf 3.0.4, Java 8, DBCP 2.2 rc1
Reporter: Matt Sicker
Priority: Blocker
Building from trunk or 2.2rc1, here's the import-package manifest:
{code}
Import-Package: javax.management,javax.naming,javax.naming.spi,javax.s
ql,javax.transaction,javax.transaction.xa,org.apache.commons.logging,
org.apache.commons.pool2,org.apache.commons.pool2.impl,javax.transact
ion;version="1.1.0",javax.transaction.xa;version="1.1.0";partial=true
;mandatory:=partial
{code}
As can be seen, the JTA packages are being imported twice. This is causing a
runtime failure in Karaf on startup of this bundle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-436) Avoid executing ROLLBACK when transaction is not active
[
https://issues.apache.org/jira/browse/DBCP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398498#comment-15398498
]
Matt Sicker commented on DBCP-436:
--
I updated the fix version to 2.3, but it looks like you guys wanna close this.
> Avoid executing ROLLBACK when transaction is not active
> ---
>
> Key: DBCP-436
> URL: https://issues.apache.org/jira/browse/DBCP-436
> Project: Commons Dbcp
> Issue Type: Improvement
>Reporter: Michael Mikhulya
> Labels: performance
> Fix For: 2.3
>
>
> {{rollbackOnReturn}} terminates the transaction by calling {{rollback}} on
> the connection as it is returned to the pool.
> It hurts performance.
> I suggest to don't call {{rollback}} if transaction is not active.
> Such improvement is done in HikariCP:
> https://github.com/brettwooldridge/HikariCP/issues/177
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-436) Avoid executing ROLLBACK when transaction is not active
[
https://issues.apache.org/jira/browse/DBCP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated DBCP-436:
-
Fix Version/s: 2.3
> Avoid executing ROLLBACK when transaction is not active
> ---
>
> Key: DBCP-436
> URL: https://issues.apache.org/jira/browse/DBCP-436
> Project: Commons Dbcp
> Issue Type: Improvement
>Reporter: Michael Mikhulya
> Labels: performance
> Fix For: 2.3
>
>
> {{rollbackOnReturn}} terminates the transaction by calling {{rollback}} on
> the connection as it is returned to the pool.
> It hurts performance.
> I suggest to don't call {{rollback}} if transaction is not active.
> Such improvement is done in HikariCP:
> https://github.com/brettwooldridge/HikariCP/issues/177
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBCP-427) Examines 'SQLException's thrown by underlying connections or statements for fatal (disconnection) errors
[ https://issues.apache.org/jira/browse/DBCP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated DBCP-427: - Fix Version/s: (was: 2.2) 2.3 > Examines 'SQLException's thrown by underlying connections or statements for > fatal (disconnection) errors > > > Key: DBCP-427 > URL: https://issues.apache.org/jira/browse/DBCP-427 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Vladimir Konkov >Priority: Minor > Fix For: 2.3 > > Attachments: DBCP-427_initial_impl.diff > > > Affected cases: > 1. Ability to detect severed connection without need for validity check (it > can be time demand). > 2. Not all fatal errors detected with simple validation query or isValid() > call. For example: > Broken XA connections of MS SQL Server and Oracle Database (and may be other) > pass validation for both isValid() and simple validation query such as 'SELEC > 1 FROM DUAL' but throw fatal errors on data and/or transaction manipulation > calls. Such errors gone only after reconnect. In case of use DBCP for polling > application has no chance to cleanup broken connection. > By providing infractructure for check thrown exceptions and mark > PoolableConnection as poisoned we can cleanup pool on validation phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DBCP-388) Support AbandonedConfig in SharedPoolDataSource
[ https://issues.apache.org/jira/browse/DBCP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated DBCP-388: - Fix Version/s: (was: 2.2) 2.3 > Support AbandonedConfig in SharedPoolDataSource > --- > > Key: DBCP-388 > URL: https://issues.apache.org/jira/browse/DBCP-388 > Project: Commons Dbcp > Issue Type: Improvement >Affects Versions: 1.4 > Environment: Linux and Java 1.6 >Reporter: Michael Kerr >Priority: Minor > Labels: features > Fix For: 2.3 > > > BasicDataSource has support for AbandonedConfig > SharedPoolDataSource does not currently support reclaiming abandoned > connections. > It would be helpful if the user can extend the underlying connection pool to > add features like abandoned connection management. This is possible with > BasicDataSource. > Currently the only solution is to extend classes or replace classes in the > Apache package namespace. > Thanks for looking, > Michael -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DBCP-436) Avoid executing ROLLBACK when transaction is not active
[
https://issues.apache.org/jira/browse/DBCP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated DBCP-436:
-
Fix Version/s: (was: 2.2)
> Avoid executing ROLLBACK when transaction is not active
> ---
>
> Key: DBCP-436
> URL: https://issues.apache.org/jira/browse/DBCP-436
> Project: Commons Dbcp
> Issue Type: Improvement
>Reporter: Michael Mikhulya
> Labels: performance
>
> {{rollbackOnReturn}} terminates the transaction by calling {{rollback}} on
> the connection as it is returned to the pool.
> It hurts performance.
> I suggest to don't call {{rollback}} if transaction is not active.
> Such improvement is done in HikariCP:
> https://github.com/brettwooldridge/HikariCP/issues/177
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DBCP-446) NullPointerException thrown when calling ManagedConnection.isClosed()
[ https://issues.apache.org/jira/browse/DBCP-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15394320#comment-15394320 ] Matt Sicker commented on DBCP-446: -- I'll be working on starting the release this week, so if the release candidate goes well, it should be released by next week. > NullPointerException thrown when calling ManagedConnection.isClosed() > - > > Key: DBCP-446 > URL: https://issues.apache.org/jira/browse/DBCP-446 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.4, 2.1.1 >Reporter: feng yang >Priority: Critical > Fix For: 2.2 > > > Hello all, > I'm using commons-dbcp 1.4, and I found this exception. I don't if it's > reported already before, I have done some searches in google, but nothing > found. > Here is the call stack. > 2015-08-18 15:01:50,091 [Thread-49] console : ERROR - ... 44 more > 2015-08-18 16:04:57,963 [Thread-45] console : ERROR - > java.lang.NullPointerException > 2015-08-18 16:04:57,965 [Thread-45] console : ERROR - at > org.apache.commons.dbcp.DelegatingConnection.isClosed(DelegatingConnection.java:386) > 2015-08-18 16:04:57,965 [Thread-45] console : ERROR - at > org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.releaseConnection(LogicalConnectionImpl.java:237) > 2015-08-18 16:04:57,965 [Thread-45] console : ERROR - at > org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.aggressiveRelease(LogicalConnectionImpl.java:200) > 2015-08-18 16:04:57,965 [Thread-45] console : ERROR - at > org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:272) > 2015-08-18 16:04:57,965 [Thread-45] console : ERROR - at > org.hibernate.engine.transaction.internal.TransactionCoordinatorImpl.afterTransaction(TransactionCoordinatorImpl.java:144) > 2015-08-18 16:04:57,965 [Thread-45] console : ERROR - at > org.hibernate.engine.transaction.internal.jta.JtaTransaction.afterAfterCompletion(JtaTransaction.java:179) > 2015-08-18 16:04:57,966 [Thread-45] console : ERROR - at > org.hibernate.engine.transaction.spi.AbstractTransactionImpl.rollback(AbstractTransactionImpl.java:219) > So when I debugged it, it created a ManagedConnection, which is a sub-class > of DelegatingConnection, and the _conn is initialized with null, and the > _closed is false by default. So when hibernate calls the isClosed(), it > throws a nullpointer exception. > Could you guys tell me if in your side, or the hibernate side ? > Do not hesitate to contact me if you need more information. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101759#comment-14101759 ] Matt Sicker commented on POOL-266: -- You can avoid introducing more APIs by using the JDK loggers. Alternatively, using the setLogWriter methods in JDBC, Log4j 2.1 will have PrintWriter/PrintStream/etc. loggers which can be set by the user. > Common Pool does not use log api > > > Key: POOL-266 > URL: https://issues.apache.org/jira/browse/POOL-266 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier > > Common pool does not use log api (logback,slf4j, log4j, log4j2, commons > logging,...). Errors are printed directly with System.out or System.err. So > it's difficult to have information in the same log file as other application > log file. > Is there any reason to not use log api ? > If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
