[jira] [Commented] (COMPRESS-439) Compressing and decompressing using Pack200 does not produce the original input
[ https://issues.apache.org/jira/browse/COMPRESS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323665#comment-16323665 ] Valentin Brandl commented on COMPRESS-439: -- Thanks for the heads up and sorry for not reading the documentation well enough. > Compressing and decompressing using Pack200 does not produce the original > input > --- > > Key: COMPRESS-439 > URL: https://issues.apache.org/jira/browse/COMPRESS-439 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.14, 1.15 > Environment: Windows 7; > # java -version > java version "1.8.0_151" > Java(TM) SE Runtime Environment (build 1.8.0_151-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode) >Reporter: Valentin Brandl >Priority: Minor > Attachments: Test.java > > > I just tested different compressors using > [JUnitQuickcheck|https://github.com/pholser/junit-quickcheck]. > The tests should compress and then decompress some input and the result > should be equal to the input. > For gzip, bzip2, deflate and xz, this works as intended but pack200 seems to > have some problems. > I will attach the testcase I wrote. > It seems that for empty input, the result won't be empty. > Test output: > ``` > input.length = 0 > input = [] > compressed.length = 19 > compressed = [-54, -2, -48, 13, 7, -106, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 3, 45, > 0] > decompressed.length = 29 > decompressed = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 7, 0, 80, 65, 67, 75, 50, 48, 48] > ``` -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323469#comment-16323469
]
Matthew McGillis edited comment on NET-650 at 1/12/18 3:08 AM:
---
Well this is the details of the exception:
{noformat}
java.net.UnknownHostException: imap.server.test.com
at java.net.InetAddress.getAllByName0(InetAddress.java:1280)
at java.net.InetAddress.getAllByName(InetAddress.java:1192)
at java.net.InetAddress.getAllByName(InetAddress.java:1126)
at java.net.InetAddress.getByName(InetAddress.java:1076)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:202)
at imapproxy.main(imapproxy.java:45)
{noformat}
So it looks like your connect code calls InetAddress directly to resolve the
name which will happen on the server that code is run from. Which is not what
we need.
I have attached a new program that works at a socket level in both cases:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy imap.server.test.com user1 userpass
* OK IMAP4rev1 proxy server ready
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy 10.250.3.127 user1 userpass
* OK IMAP4rev1 proxy server ready
{noformat}
Let me know if that doesn't help I'm not going to have time to work out a patch
but hopefully the above should turn into a simple replacement in the
appropriate place.
was (Author: msm):
Well this is the details of the exception:
{noformat}
java.net.UnknownHostException: zimbra07.loadtest.synacor.com
at java.net.InetAddress.getAllByName0(InetAddress.java:1280)
at java.net.InetAddress.getAllByName(InetAddress.java:1192)
at java.net.InetAddress.getAllByName(InetAddress.java:1126)
at java.net.InetAddress.getByName(InetAddress.java:1076)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:202)
at imapproxy.main(imapproxy.java:45)
{noformat}
So it looks like your connect code calls InetAddress directly to resolve the
name which will happen on the server that code is run from. Which is not what
we need.
I have attached a new program that works at a socket level in both cases:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy imap.server.test.com user1 userpass
* OK IMAP4rev1 proxy server ready
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy 10.250.3.127 user1 userpass
* OK IMAP4rev1 proxy server ready
{noformat}
Let me know if that doesn't help I'm not going to have time to work out a patch
but hopefully the above should turn into a simple replacement in the
appropriate place.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
> Attachments: imapproxy.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323469#comment-16323469
]
Matthew McGillis edited comment on NET-650 at 1/12/18 2:53 AM:
---
Well this is the details of the exception:
{noformat}
java.net.UnknownHostException: zimbra07.loadtest.synacor.com
at java.net.InetAddress.getAllByName0(InetAddress.java:1280)
at java.net.InetAddress.getAllByName(InetAddress.java:1192)
at java.net.InetAddress.getAllByName(InetAddress.java:1126)
at java.net.InetAddress.getByName(InetAddress.java:1076)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:202)
at imapproxy.main(imapproxy.java:45)
{noformat}
So it looks like your connect code calls InetAddress directly to resolve the
name which will happen on the server that code is run from. Which is not what
we need.
I have attached a new program that works at a socket level in both cases:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy imap.server.test.com user1 userpass
* OK IMAP4rev1 proxy server ready
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy 10.250.3.127 user1 userpass
* OK IMAP4rev1 proxy server ready
{noformat}
Let me know if that doesn't help I'm not going to have time to work out a patch
but hopefully the above should turn into a simple replacement in the
appropriate place.
was (Author: msm):
Well this is the details of the exception:
{noformat}
java.net.UnknownHostException: zimbra07.loadtest.synacor.com
at java.net.InetAddress.getAllByName0(InetAddress.java:1280)
at java.net.InetAddress.getAllByName(InetAddress.java:1192)
at java.net.InetAddress.getAllByName(InetAddress.java:1126)
at java.net.InetAddress.getByName(InetAddress.java:1076)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:202)
at imapproxy.main(imapproxy.java:45)
{noformat}
So it looks like your connect code calls InetAddress directly to resolve the
name which will happen on the server that code is run from. Which is not what
we need.
I have attached a new program that works at a socket level in both cases:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy imap.server.test.com user1 userpass
* OK IMAP4rev1 proxy server ready
palladium:commons-net-3.6 matthew$ java -DsocksProxyHost=localhost
-DsocksProxyPort=16003 -cp .:./commons-net-3.6.jar socketproxy 10.250.3.127
user1 userpass
* OK IMAP4rev1 proxy server ready
{noformat}
Let me know if that doesn't help I'm not going to have time to work out a patch
but hopefully the above should turn into a simple replacement in the
appropriate place.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
> Attachments: imapproxy.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew McGillis updated NET-650:
-
Attachment: socketproxy.java
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
> Attachments: imapproxy.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323469#comment-16323469
]
Matthew McGillis commented on NET-650:
--
Well this is the details of the exception:
{noformat}
java.net.UnknownHostException: zimbra07.loadtest.synacor.com
at java.net.InetAddress.getAllByName0(InetAddress.java:1280)
at java.net.InetAddress.getAllByName(InetAddress.java:1192)
at java.net.InetAddress.getAllByName(InetAddress.java:1126)
at java.net.InetAddress.getByName(InetAddress.java:1076)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:202)
at imapproxy.main(imapproxy.java:45)
{noformat}
So it looks like your connect code calls InetAddress directly to resolve the
name which will happen on the server that code is run from. Which is not what
we need.
I have attached a new program that works at a socket level in both cases:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar socketproxy imap.server.test.com user1 userpass
* OK IMAP4rev1 proxy server ready
palladium:commons-net-3.6 matthew$ java -DsocksProxyHost=localhost
-DsocksProxyPort=16003 -cp .:./commons-net-3.6.jar socketproxy 10.250.3.127
user1 userpass
* OK IMAP4rev1 proxy server ready
{noformat}
Let me know if that doesn't help I'm not going to have time to work out a patch
but hopefully the above should turn into a simple replacement in the
appropriate place.
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
> Attachments: imapproxy.java, socketproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
[
https://issues.apache.org/jira/browse/NET-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323283#comment-16323283
]
Sebb commented on NET-650:
--
Any suggestions for a patch?
> IMAPClient over proxy doesn't properly resolve DNS
> --
>
> Key: NET-650
> URL: https://issues.apache.org/jira/browse/NET-650
> Project: Commons Net
> Issue Type: Bug
> Components: IMAP
>Affects Versions: 3.6
>Reporter: Matthew McGillis
> Attachments: imapproxy.java
>
>
> IMAPClient when configured to use a socks proxy is not able to resolve DNS
> names through the proxy.
> See attached sample code, if I use it with:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
> connect error: java.net.UnknownHostException: imap.server.test.com: unknown
> error
> {noformat}
> vs if I use it with the appropriate IP:
> {noformat}
> $ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
> .:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
> * OK IMAP4rev1 proxy server ready
> IMAP: 10.250.3.127 143
> LOGIN ***
> OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
> ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
> LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
> SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
> completed
> AAAB LOGOUT
> * BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
> AAAB OK LOGOUT completed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes
[ https://issues.apache.org/jira/browse/COMPRESS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323178#comment-16323178 ] Christopher Hunt commented on COMPRESS-407: --- I don't understand why you changed the default block size to a single record as it is the default when receiving data from the `tar` command. However, creating an explicit TarArchiveOutputStream with a block size does indeed work for me. Thanks. > Validate Block and Record Sizes > --- > > Key: COMPRESS-407 > URL: https://issues.apache.org/jira/browse/COMPRESS-407 > Project: Commons Compress > Issue Type: Sub-task > Components: Archivers >Reporter: Simon Spero > Fix For: 1.15 > > > Reject record sizes not equal to 512 bytes; require block sizes to be > multiples of 512 bytes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (NET-650) IMAPClient over proxy doesn't properly resolve DNS
Matthew McGillis created NET-650:
Summary: IMAPClient over proxy doesn't properly resolve DNS
Key: NET-650
URL: https://issues.apache.org/jira/browse/NET-650
Project: Commons Net
Issue Type: Bug
Components: IMAP
Affects Versions: 3.6
Reporter: Matthew McGillis
Attachments: imapproxy.java
IMAPClient when configured to use a socks proxy is not able to resolve DNS
names through the proxy.
See attached sample code, if I use it with:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar imapproxy imap.server.test.com user1 userpass
connect error: java.net.UnknownHostException: imap.server.test.com: unknown
error
{noformat}
vs if I use it with the appropriate IP:
{noformat}
$ java -DsocksProxyHost=localhost -DsocksProxyPort=16003 -cp
.:./commons-net-3.6.jar imapproxy 10.250.3.127 user1 userpass
* OK IMAP4rev1 proxy server ready
IMAP: 10.250.3.127 143
LOGIN ***
OK [CAPABILITY IMAP4rev1 ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE
ESEARCH ESORT I18NLEVEL=1 ID IDLE LIST-EXTENDED LIST-STATUS LITERAL+
LOGIN-REFERRALS MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR
SEARCHRES SORT THREAD=ORDEREDSUBJECT UIDPLUS UNSELECT WITHIN XLIST] LOGIN
completed
AAAB LOGOUT
* BYE 10.250.3.127 Zimbra IMAP4rev1 server closing connection
AAAB OK LOGOUT completed
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMPRESS-440) Speed up decoder for deflate64
[
https://issues.apache.org/jira/browse/COMPRESS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated COMPRESS-440:
-
Description:
With the buffer applied in COMPRESS-438 the decompression speed is actually
quite all right, but there's still room for improvement. I was quite curious
what the bounds for pure-java inflater would be and hacked a quick experiment
with ZipFile using jzlib's implementation [1] to decompress a large-ish archive
(openjdk8 repository).
The results for deflate, deflate64 and java's built-in decompressor are below.
{code}
Java (Inflater):
archive.zip 4.38 sec., 444,357,134 archived => 731,621,181 decompressed
jzlib's pure-java inflater:
archive.zip 6.65 sec., 444,357,134 archived => 731,621,181 decompressed
current deflate64 in commons-compress (with my allocation-reducing patch):
archive64.zip 11.35 sec., 443,209,798 archived => 731,630,120 decompressed
{code}
[1] http://www.jcraft.com/jzlib/
> Speed up decoder for deflate64
> --
>
> Key: COMPRESS-440
> URL: https://issues.apache.org/jira/browse/COMPRESS-440
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Dawid Weiss
>Priority: Minor
>
> With the buffer applied in COMPRESS-438 the decompression speed is actually
> quite all right, but there's still room for improvement. I was quite curious
> what the bounds for pure-java inflater would be and hacked a quick experiment
> with ZipFile using jzlib's implementation [1] to decompress a large-ish
> archive (openjdk8 repository).
> The results for deflate, deflate64 and java's built-in decompressor are below.
> {code}
> Java (Inflater):
> archive.zip 4.38 sec., 444,357,134 archived => 731,621,181 decompressed
> jzlib's pure-java inflater:
> archive.zip 6.65 sec., 444,357,134 archived => 731,621,181 decompressed
> current deflate64 in commons-compress (with my allocation-reducing patch):
> archive64.zip 11.35 sec., 443,209,798 archived => 731,630,120 decompressed
> {code}
> [1] http://www.jcraft.com/jzlib/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (COMPRESS-440) Speed up decoder for deflate64
Dawid Weiss created COMPRESS-440: Summary: Speed up decoder for deflate64 Key: COMPRESS-440 URL: https://issues.apache.org/jira/browse/COMPRESS-440 Project: Commons Compress Issue Type: Improvement Reporter: Dawid Weiss Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[
https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322403#comment-16322403
]
Gilles commented on COMMONSSITE-100:
Still, MathJax does not work anymore...
Comparing pages between the live site and the latest generated ones; this line
is missing from the latter:
{code:html}
http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML";>
{code}
> "mvn site" fails with commons-parent 43
> ---
>
> Key: COMMONSSITE-100
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-100
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles
>
> See [this post|http://markmail.org/message/zgfb5h774aigatx2].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (RNG-46) Benign incompatibility (?)
[
https://issues.apache.org/jira/browse/RNG-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated RNG-46:
--
Summary: Benign incompatibility (?) (was: Benign binary incompatibility
(?))
> Benign incompatibility (?)
> --
>
> Key: RNG-46
> URL: https://issues.apache.org/jira/browse/RNG-46
> Project: Commons RNG
> Issue Type: Bug
>Reporter: Gilles
>Priority: Blocker
> Labels: compatibility, incompatibility
> Fix For: 1.1
>
>
> Clirr reports this error:
> {{Removed org.apache.commons.rng.sampling.distribution.SamplerBase from the
> list of superclasses}}
> for this class:
> {{org.apache.commons.rng.sampling.distribution.BoxMullerLogNormalSampler}}
> It is quite true.
> However, no functionality inherited from {{SamplerBase}} could have been used
> since a {{null}} was passed to its constructor (i.e. any call to a method
> from the base class would trigger a {{NullPointerException}}).
> Moreover:
> * {{SamplerBase}} is only meant for internal usage,
> * it only contains {{protected}} methods,
> * {{BoxMullerLogNormalSampler}} is going to be flagged as {{@deprecated}} in
> the next release.
> Hence, I think that it is quite safe to release a 1.1 version (i.e. no change
> in major number!) despite this incompatibility.
> Please confirm.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (RNG-46) Benign binary incompatibility (?)
Gilles created RNG-46:
-
Summary: Benign binary incompatibility (?)
Key: RNG-46
URL: https://issues.apache.org/jira/browse/RNG-46
Project: Commons RNG
Issue Type: Bug
Reporter: Gilles
Priority: Blocker
Fix For: 1.1
Clirr reports this error:
{{Removed org.apache.commons.rng.sampling.distribution.SamplerBase from the
list of superclasses}}
for this class:
{{org.apache.commons.rng.sampling.distribution.BoxMullerLogNormalSampler}}
It is quite true.
However, no functionality inherited from {{SamplerBase}} could have been used
since a {{null}} was passed to its constructor (i.e. any call to a method from
the base class would trigger a {{NullPointerException}}).
Moreover:
* {{SamplerBase}} is only meant for internal usage,
* it only contains {{protected}} methods,
* {{BoxMullerLogNormalSampler}} is going to be flagged as {{@deprecated}} in
the next release.
Hence, I think that it is quite safe to release a 1.1 version (i.e. no change
in major number!) despite this incompatibility.
Please confirm.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
[
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-246.
Resolution: Fixed
Adds the concept of severity to an AmbiguousException:
The only *non-severe* case is when there is at least one null argument and at
most one method/ctor is having a corresponding 'Object' parameter.
We thus consider that ambiguity is benign in presence of null arguments but in
the case where the 'catch all' type Object is applicable more than once.
In other words:
If all arguments are valid instances - no null argument -, ambiguity is severe.
If there is at least one null argument, the ambiguity is severe if more than
one method has a
corresponding parameter of class 'Object'.
src/main/java/org/apache/commons/jexl3/internal/introspection/Introspector.java
src/main/java/org/apache/commons/jexl3/internal/introspection/MethodKey.java
src/test/java/org/apache/commons/jexl3/IssuesTest200.java
Committed revision 1820883.
> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
> defined yet raises an exception
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
> with the following stack trace:
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
> null
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
> at
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>
> at
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>
> at MyUberspect.getMethod(MyUberspect.java:168)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
> at
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
> at
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
>
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}}
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is
> an Integer it is not possible to differentiate between {{public JexlOperator
> selfAdd(Collection x, Object y)}} and {{public JexlOperator
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying
> to perform {{selfAdd}} on the null variable? What questions me more is that
> this error is intermittent and sometimes there is an exception and sometimes
> there is not, so at the moment I have no test case to reproduce. So I think
> this is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[ https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322243#comment-16322243 ] Gilles commented on COMMONSSITE-100: Fixed by setting version to 2.8: https://github.com/mojohaus/clirr-maven-plugin/issues/7 > "mvn site" fails with commons-parent 43 > --- > > Key: COMMONSSITE-100 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-100 > Project: Commons All > Issue Type: Bug > Components: Commons Parent Pom >Reporter: Gilles > > See [this post|http://markmail.org/message/zgfb5h774aigatx2]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[
https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1635#comment-1635
]
Gilles commented on COMMONSSITE-100:
Problem is caused by "clirr"; here is the output when using the {{-e}} switch:
{noformat}
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-site of goal org.apache.maven.plugins:maven-site-plugin:3.7:site failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: java.lang.NullPointerException
at
org.codehaus.mojo.clirr.ClirrReportGenerator$ApiChangeComparator.compare(ClirrReportGenerator.java:64)
at
org.codehaus.mojo.clirr.ClirrReportGenerator$ApiChangeComparator.compare(ClirrReportGenerator.java:57)
at java.util.TimSort.binarySort(TimSort.java:296)
at java.util.TimSort.sort(TimSort.java:221)
at java.util.Arrays.sort(Arrays.java:1438)
at java.util.List.sort(List.java:478)
at java.util.Collections.sort(Collections.java:175)
at
org.codehaus.mojo.clirr.ClirrReportGenerator.doApiChangesTable(ClirrReportGenerator.java:600)
at
org.codehaus.mojo.clirr.ClirrReportGenerator.doApiChanges(ClirrReportGenerator.java:453)
at
org.codehaus.mojo.clirr.ClirrReportGenerator.generateReport(ClirrReportGenerator.java:186)
at org.codehaus.mojo.clirr.ClirrReport.doReport(ClirrReport.java:316)
at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:227)
at org.codehaus.mojo.clirr.ClirrReport.generate(ClirrReport.java:363)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
at
org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:184)
at
org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:133)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
... 21 more
{noformat}
> "mvn site" fails with commons-parent 43
> ---
>
> Key: COMMONSSITE-100
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-100
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles
>
> See [this post|http://markmail.org/message/zgfb5h774aigatx2].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[
https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322218#comment-16322218
]
Gilles commented on COMMONSSITE-100:
As of now (commit 5de2d1af79fabca56b5fa8fca159938fa023ae6a)
{noformat}
$ mvn clean site
{noformat}
fails.
Excerpt of console output:
{noformat}
[...]
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Commons RNG . SUCCESS [ 21.958 s]
[INFO] Apache Commons RNG Client API .. SUCCESS [ 17.909 s]
[INFO] Apache Commons RNG Core SUCCESS [ 29.075 s]
[INFO] Apache Commons RNG Simple .. SUCCESS [ 23.959 s]
[INFO] Apache Commons RNG Sampling FAILURE [01:14 min]
[INFO] Apache Commons RNG JMH . SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 02:47 min
[INFO] Finished at: 2018-01-11T13:52:12+01:00
[INFO] Final Memory: 92M/850M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7:site (default-site) on project
commons-rng-sampling: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.7:site failed.
NullPointerException -> [Help 1]
[...]
{noformat}
> "mvn site" fails with commons-parent 43
> ---
>
> Key: COMMONSSITE-100
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-100
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles
>
> See [this post|http://markmail.org/message/zgfb5h774aigatx2].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (POOL-336) GenericObjectPool's borrowObject lock if create() fails with Error
[
https://issues.apache.org/jira/browse/POOL-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wolfgang Glas closed POOL-336.
--
Closing issue, because the original problem is solved and other problems are
raised against mariadb-connector-j
> GenericObjectPool's borrowObject lock if create() fails with Error
> --
>
> Key: POOL-336
> URL: https://issues.apache.org/jira/browse/POOL-336
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.3, 2.5.0
> Environment: mariadb-connector-j
>Reporter: Wolfgang Glas
> Labels: patch
> Fix For: 2.5.1
>
> Attachments: 0001-Add-a-test-case-for-POOL-336.patch,
> 0002-Fix-POOL-336.patch
>
>
> We've spotted exactly the same problem as described in POOL-303 for a pool
> using mariadb-connector-j-2.1.2 with a pool configured to a size, which
> exactly reflects the normal quantity of used DB connections.
> After weeks of monitoring the situation, we were able to see the same problem
> as described in POOL-303. After some more drilldown efforts we concluded,
> that the problem is triggered, because mariadb-connector-j throws instances
> of Throwables derived from {{java.lang.Error}}, which are not instances of
> {{java.lang.Execption}}.
> This leads to a leak of {{makeCount}} in GenericObjectPool.create(), because
> {{makeCount}} is only decremented, when an instance of
> {{java.lang.Exception}} is thrown and not when an instance of
> {{java.langError}} is thrown.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (RNG-45) Example code (sampling)
Gilles created RNG-45:
-
Summary: Example code (sampling)
Key: RNG-45
URL: https://issues.apache.org/jira/browse/RNG-45
Project: Commons RNG
Issue Type: Wish
Reporter: Gilles
Priority: Trivial
Fix For: 1.1
Attachments: ProbabilityDensityApproximation.java
I've added a few figures to the userguide (see commit
5de2d1af79fabca56b5fa8fca159938fa023ae6a).
The Java code that generates the data is a fairly trivial example of usage of
the samplers provided in module {{commons-rng-sampling}}.
It is attached to this page.
Do you think it's worth adding it to the repository (in
{{commons-rng-examples}})?
If so, should I also add the script that generated the plots (it calls the
"gnuplot" software)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (RNG-43) Log-normal samplers
[
https://issues.apache.org/jira/browse/RNG-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved RNG-43.
---
Resolution: Implemented
commit 4d83aacba2a5aa3fd09b9ed3037202a483a16146 (in "master" branch).
> Log-normal samplers
> ---
>
> Key: RNG-43
> URL: https://issues.apache.org/jira/browse/RNG-43
> Project: Commons RNG
> Issue Type: Improvement
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.1
>
>
> In relation to RNG-41, I propose to create a {{LogNormalSampler}} base class:
> {noformat}
> class LogNormalSampler {
> protected LogNormalSampler(NormalizedGaussianSampler gaussian,
>double scale,
>double shape) {
> // ...
> }
> }
> {noformat}
> Derived (public) classes will differ by the algorithm used to generate
> normalized Gaussian deviates.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[ https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-468. -- Resolution: Fixed > Request for native support for socks proxy routing with Commons net FTP > --- > > Key: NET-468 > URL: https://issues.apache.org/jira/browse/NET-468 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 1.4, 2.0, 3.0.1, 3.1, 3.4 > Environment: We use commons net in out products for all > communication to an FTP server. OS : All. No other environment specifications. >Reporter: Ramya Rajendiran > Attachments: imapproxy.java, sockclient-proxy3.diff, > sockclient-proxy4.diff, sockclient-proxy5.diff, sockclient-proxy6.diff, > sockclient-proxy7.diff > > > Commons net currently does not natively support connection to an FTP server > via a socks proxy. The only way of achieving this would be to work at the > socket level as observed here > http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM > properties socksProxyPort and socksProxyPortHost) > However, a major side effect of this all connections on this JVM will go > through the socks proxy since this setting is at the JVM level. This is > sometimes undesirable as the business requirements are such that only certain > applications on the JVM need to go through the socks proxy. There are no > existing workarounds to conditionally prevent other applications to not be > routed through the socks proxy. This makes our application which consumes the > commons net unusable for such businesses. > Providing native support for socks proxy with commons net for FTP, will go a > long way in supporting such common scenarios and business continuity. > Therefore raising this enhancement request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[ https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16321991#comment-16321991 ] Sebb commented on NET-468: -- Thanks for confirming that the code works with a numeric IP address. I think the DNS resolution is best dealt with as a separate issue please. > Request for native support for socks proxy routing with Commons net FTP > --- > > Key: NET-468 > URL: https://issues.apache.org/jira/browse/NET-468 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 1.4, 2.0, 3.0.1, 3.1, 3.4 > Environment: We use commons net in out products for all > communication to an FTP server. OS : All. No other environment specifications. >Reporter: Ramya Rajendiran > Attachments: imapproxy.java, sockclient-proxy3.diff, > sockclient-proxy4.diff, sockclient-proxy5.diff, sockclient-proxy6.diff, > sockclient-proxy7.diff > > > Commons net currently does not natively support connection to an FTP server > via a socks proxy. The only way of achieving this would be to work at the > socket level as observed here > http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM > properties socksProxyPort and socksProxyPortHost) > However, a major side effect of this all connections on this JVM will go > through the socks proxy since this setting is at the JVM level. This is > sometimes undesirable as the business requirements are such that only certain > applications on the JVM need to go through the socks proxy. There are no > existing workarounds to conditionally prevent other applications to not be > routed through the socks proxy. This makes our application which consumes the > commons net unusable for such businesses. > Providing native support for socks proxy with commons net for FTP, will go a > long way in supporting such common scenarios and business continuity. > Therefore raising this enhancement request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (RNG-44) Invalid links on web site
[ https://issues.apache.org/jira/browse/RNG-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16321985#comment-16321985 ] Sebb commented on RNG-44: - bq. Is there a problem with the above definitions? IDK. They work OK for the parent. Only does not work for modules. In theory Maven could detect that the uses Git, but maybe it fails to do so, or maybe it needs some help. Or maybe it does not handle Git URLs for modules. These are questions for the Maven project. > Invalid links on web site > - > > Key: RNG-44 > URL: https://issues.apache.org/jira/browse/RNG-44 > Project: Commons RNG > Issue Type: Bug >Reporter: Gilles >Priority: Minor > Labels: web-site > Fix For: 1.1 > > > On [that > page|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/source-repository.html] > (and similar for the other maven modules), the "Web Browser Access" link > points to a non-existing project (because the module name is appended to the > URL of the git repository). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (RNG-44) Invalid links on web site
[
https://issues.apache.org/jira/browse/RNG-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16321865#comment-16321865
]
Gilles commented on RNG-44:
---
bq. e.g. where can I find a link to
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/index.html
on the page: http://commons.apache.org/proper/commons-rng/index.html
In the menu: "Project Information" -> "Project Modules".
bq. a missing property that tells Maven the entry is a git repo
It seems that the information should be available to maven:
{noformat}
scm:git:http://git-wip-us.apache.org/repos/asf/commons-rng.git
scm:git:https://git-wip-us.apache.org/repos/asf/commons-rng.git
https://git-wip-us.apache.org/repos/asf?p=commons-rng.git
{noformat}
Is there a problem with the above definitions?
> Invalid links on web site
> -
>
> Key: RNG-44
> URL: https://issues.apache.org/jira/browse/RNG-44
> Project: Commons RNG
> Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
> Labels: web-site
> Fix For: 1.1
>
>
> On [that
> page|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/source-repository.html]
> (and similar for the other maven modules), the "Web Browser Access" link
> points to a non-existing project (because the module name is appended to the
> URL of the git repository).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
