[jira] [Commented] (COMPRESS-188) Improved Exceptionhandling for unsupported zip compression methods
[ https://issues.apache.org/jira/browse/COMPRESS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408760#comment-13408760 ] Stefan Bodewig commented on COMPRESS-188: - I think ZipMethod could be an enum. I'm not sure whether you have checked the "license to the ASF" checkbox when attaching the file. There used to be a feather logo but I don't see one anymore. Could you please confirm you are licensing the path tothe ASF? Thanks. > Improved Exceptionhandling for unsupported zip compression methods > -- > > Key: COMPRESS-188 > URL: https://issues.apache.org/jira/browse/COMPRESS-188 > Project: Commons Compress > Issue Type: Improvement > Components: Compressors >Affects Versions: 1.4.1 >Reporter: Harald Kuhn >Priority: Minor > Attachments: UnsupportedZipFeatureException.java.patch > > > If an unsupported zip compression methods, the created exception is not very > helpfull for analysing why a zip archive could not be opend. Giving a name or > description of the method can be very helpful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-190) Git settings for commons-compress
[
https://issues.apache.org/jira/browse/COMPRESS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-190.
-
Resolution: Fixed
Fix Version/s: 1.5
added with svn revision 1358629
Any reason you didn't simply add those yourself?
> Git settings for commons-compress
> -
>
> Key: COMPRESS-190
> URL: https://issues.apache.org/jira/browse/COMPRESS-190
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Jukka Zitting
>Priority: Trivial
> Labels: git
> Fix For: 1.5
>
> Attachments: 0001-COMPRESS-190-Git-settings-for-commons-compress.patch
>
>
> For people using the commons-compress.git mirror it would be useful to have
> basic {{.gitignore}} and {{.gitattributes}} files present at the root of the
> Commons Compress checkout.
> The following settings work fine for me on a Windows/Eclipse environment:
> {code:none}
> $ cat .gitignore
> target
> .project
> .classpath
> .settings
> $ cat .gitattributes
> src/test/resources/longfile_gnu.ar eol=lf
> src/test/resources/longfile_bsd.ar eol=lf
> src/test/resources/longpath/minotaur.ar eol=lf
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-192) Allow setting of the zip encoding in ArchiveStreamFactory
[ https://issues.apache.org/jira/browse/COMPRESS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-192. - Resolution: Fixed Fix Version/s: 1.5 added with svn revision 1358626, thanks > Allow setting of the zip encoding in ArchiveStreamFactory > - > > Key: COMPRESS-192 > URL: https://issues.apache.org/jira/browse/COMPRESS-192 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Jukka Zitting >Priority: Minor > Labels: encoding, zip > Fix For: 1.5 > > Attachments: > 0001-COMPRESS-192-Allow-setting-of-the-zip-encoding-in-Ar.patch > > > When using the ArchiveStreamFactory it's currently not possible to control > the encoding used by zip archive streams. Having that feature available in > ArchiveStreamFactory would be useful for TIKA-936. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[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&focusedCommentId=13408692#comment-13408692 ] Gary D. Gregory commented on NET-468: - I've attached a version 6 of the patch. See previous comment for a summary of changes over version 5. What is still missing is a functional test. Class names ending with "FunctionalTest" will not be run as part of the normal build but should be run by developers. A FunctionalTest class can depend on external resources. Thank you, Gary > 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 > 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: sockclient-proxy3.diff, sockclient-proxy4.diff, > sockclient-proxy5.diff, sockclient-proxy6.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 ] Gary D. Gregory updated NET-468: Attachment: sockclient-proxy6.diff New version of the patch: - Fix misspelled words. - Add testing for side effects to the new test org.apache.commons.net.SocketClientTest - Add missing @since tags - Fix formatting of if statements - Other small improvements > 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 > 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: sockclient-proxy3.diff, sockclient-proxy4.diff, > sockclient-proxy5.diff, sockclient-proxy6.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-421) Update JavaDoc in ListUtils to discribe generified methods
[
https://issues.apache.org/jira/browse/COLLECTIONS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated COLLECTIONS-421:
Attachment: COLLECTIONS-421.patch
Sorry, I've created this issue with the wrong type. Should be Improvement.
I've attached a patch. It just contains JavaDoc changes.
> Update JavaDoc in ListUtils to discribe generified methods
> --
>
> Key: COLLECTIONS-421
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-421
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Reporter: Benedikt Ritter
>Priority: Trivial
> Attachments: COLLECTIONS-421.patch
>
>
> The JavaDoc of {{ListUtils.lazyList()}} and {{ListUtils.fixedSizeList}} still
> refer to the old methods prior to generics. This should be updated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-421) Update JavaDoc in ListUtils to discribe generified methods
Benedikt Ritter created COLLECTIONS-421:
---
Summary: Update JavaDoc in ListUtils to discribe generified methods
Key: COLLECTIONS-421
URL: https://issues.apache.org/jira/browse/COLLECTIONS-421
Project: Commons Collections
Issue Type: Bug
Components: Collection
Reporter: Benedikt Ritter
Priority: Trivial
The JavaDoc of {{ListUtils.lazyList()}} and {{ListUtils.fixedSizeList}} still
refer to the old methods prior to generics. This should be updated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-423) [BeanUtils2] Wrap checked exceptions from BeanAccessor.get() into BeanReflectionException
[
https://issues.apache.org/jira/browse/SANDBOX-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated SANDBOX-423:
Attachment: SANDBOX-423v2.patch
I finally had the time to do some more work on this issue.
I have attached a new patch file.
We discussed to throw exceptions as soon as possible to get rid of all the
try/catch code in {{DefaultBeanAccessor}}. I started to implement that, but
things got way out of hand, so I decided to go back to the first solution to
make it easier to review.
We can change the exception handling later.
One thing I don't like about my solution is, that an {{IntrospectionException}}
will be wrapped in a {{NoSuchPropertyException}}, but this is due to the
Introspection API.
Also constructing a Property[Setter|Getter]InvocationException feels clumsy
because one has to pass in both, the property name and the property accessor
method name. Maybe you have a suggestion how to improve that?
TIA
Benedikt
> [BeanUtils2] Wrap checked exceptions from BeanAccessor.get() into
> BeanReflectionException
> -
>
> Key: SANDBOX-423
> URL: https://issues.apache.org/jira/browse/SANDBOX-423
> Project: Commons Sandbox
> Issue Type: Sub-task
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Fix For: Nightly Builds
>
> Attachments: SANDBOX-423.patch, SANDBOX-423v2.patch
>
>
> * Change method signature of BeanAccessor.get()
> * in DefaultBeanAccessor.get() catch all checked exceptions
> * modify GetPropertyTestCase accordingly
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-812) In RealVector, dotProduct and outerProduct return wrong results due to misuse of sparse iterators
[
https://issues.apache.org/jira/browse/MATH-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408651#comment-13408651
]
Gilles commented on MATH-812:
-
bq. [...] robustness should probably be preferred over speed in default
implementations.
+1
> In RealVector, dotProduct and outerProduct return wrong results due to misuse
> of sparse iterators
> -
>
> Key: MATH-812
> URL: https://issues.apache.org/jira/browse/MATH-812
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: linear, sparse
> Fix For: 3.1
>
>
> In class {{RealVector}}, the default implementation of {{RealMatrix
> outerProduct(RealVector)}} uses sparse iterators on the entries of the two
> vectors. The rationale behind this is that {{0d * x == 0d}} is {{true}} for
> all {{double x}}. This assumption is in fact false, since {{0d * NaN == NaN}}.
> Proposed fix is to loop through *all* entries of both vectors. This can have
> a significant impact on the CPU cost, but robustness should probably be
> preferred over speed in default implementations.
> Same issue occurs with {{double dotProduct(RealVector)}}, which uses sparse
> iterators for {{this}} only.
> Another option would be to through an exception if {{isNaN()}} is {{true}},
> in which case caching could be used for both {{isNaN()}} and {{isInfinite()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-795) Refactoring ArrayRealVectorTest, RealVectorTest, SparseRealVectorTest
[
https://issues.apache.org/jira/browse/MATH-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408644#comment-13408644
]
Sébastien Brisard commented on MATH-795:
As of {{r1358547}}, refactoring should be complete. This refactring revealed
some bugs, see MATH-812.
> Refactoring ArrayRealVectorTest, RealVectorTest, SparseRealVectorTest
> -
>
> Key: MATH-795
> URL: https://issues.apache.org/jira/browse/MATH-795
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
>Priority: Minor
> Fix For: 3.1
>
>
> The above mentioned tests contain a lot of duplicate code. Besides, some of
> the unit tests are no longer _unit_ tests, since they test many different
> functionalities.
> It is proposed to refactor these tests. The duplicate code should be factored
> out to the abstract class {{RealVectorAbstractTest}}. Then some tests could
> be splitted in smaller units.
> Besides readability, the benefit would be to ease the implementation of other
> kinds of vector. This refactoring should also lead to a natural resolution of
> MATH-625.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-812) In RealVector, dotProduct and outerProduct return wrong results due to misuse of sparse iterators
Sébastien Brisard created MATH-812:
--
Summary: In RealVector, dotProduct and outerProduct return wrong
results due to misuse of sparse iterators
Key: MATH-812
URL: https://issues.apache.org/jira/browse/MATH-812
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Fix For: 3.1
In class {{RealVector}}, the default implementation of {{RealMatrix
outerProduct(RealVector)}} uses sparse iterators on the entries of the two
vectors. The rationale behind this is that {{0d * x == 0d}} is {{true}} for all
{{double x}}. This assumption is in fact false, since {{0d * NaN == NaN}}.
Proposed fix is to loop through *all* entries of both vectors. This can have a
significant impact on the CPU cost, but robustness should probably be preferred
over speed in default implementations.
Same issue occurs with {{double dotProduct(RealVector)}}, which uses sparse
iterators for {{this}} only.
Another option would be to through an exception if {{isNaN()}} is {{true}}, in
which case caching could be used for both {{isNaN()}} and {{isInfinite()}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-195) Additional command-line utility classes
Sebb created COMPRESS-195: - Summary: Additional command-line utility classes Key: COMPRESS-195 URL: https://issues.apache.org/jira/browse/COMPRESS-195 Project: Commons Compress Issue Type: New Feature Reporter: Sebb Attachments: Archiver.java There is a Lister command-line utility which can be used to list the contents of any archive. It might be useful to have corresponding simple extraction / creation utilities for archive and compressed formats. For example: + archive contents of a directory (see attached) + extract archive into directory + compress/decompress files The existing Lister class is the only main() class at present, and is set as the default entry point for the jar. This means users don't have to provide the class name on the command line. It would be useful to extend this feature to cover the other command-line utilities. For example, create a new Main class as the default entry point, but delegate to the existing class if there are 1 or two parameters. Otherwise, delegate to the appropriate new utility class, e.g. based on a command-line flag. Users would still be able to invoke the individual classes directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-195) Additional command-line utility classes
[ https://issues.apache.org/jira/browse/COMPRESS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated COMPRESS-195: -- Attachment: Archiver.java Sample archiver class > Additional command-line utility classes > --- > > Key: COMPRESS-195 > URL: https://issues.apache.org/jira/browse/COMPRESS-195 > Project: Commons Compress > Issue Type: New Feature >Reporter: Sebb > Attachments: Archiver.java > > > There is a Lister command-line utility which can be used to list the contents > of any archive. > It might be useful to have corresponding simple extraction / creation > utilities for archive and compressed formats. > For example: > + archive contents of a directory (see attached) > + extract archive into directory > + compress/decompress files > The existing Lister class is the only main() class at present, and is set as > the default entry point for the jar. This means users don't have to provide > the class name on the command line. > It would be useful to extend this feature to cover the other command-line > utilities. > For example, create a new Main class as the default entry point, but delegate > to the existing class if there are 1 or two parameters. > Otherwise, delegate to the appropriate new utility class, e.g. based on a > command-line flag. > Users would still be able to invoke the individual classes directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-810) StringUtils.join() endIndex, bugged for loop
[
https://issues.apache.org/jira/browse/LANG-810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13408623#comment-13408623
]
Sebb commented on LANG-810:
---
I think it's the Javadoc that is wrong, because the method is called internally
e.g. here:
{code}
public static String join(Object[] array, char separator) {
...
return join(array, separator, 0, array.length);
}
{code}
If the Javadoc is correct, then that method also needs to be fixed.
> StringUtils.join() endIndex, bugged for loop
>
>
> Key: LANG-810
> URL: https://issues.apache.org/jira/browse/LANG-810
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Krzysztof Nazarewski
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> endIndex is described as index, but for loop still checks it as "array
> length".
> Basically missing equal sign
> commons-lang3-3.1-sources.jar, StringUtils.java lines 3309, 3394:
> for (int i = startIndex; i < endIndex; i++) {
> should be:
> for (int i = startIndex; i <= endIndex; i++) {
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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 ] Bogdan Drozdowski updated NET-468: -- Attachment: sockclient-proxy5.diff Does version 5 satisfy you? > 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 > 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: sockclient-proxy3.diff, sockclient-proxy4.diff, > sockclient-proxy5.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
