[jira] [Commented] (LOGGING-152) Helper class that redirects OutputStream to Log
[
https://issues.apache.org/jira/browse/LOGGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816433#comment-17816433
]
Dmitry Katsubo commented on LOGGING-152:
What is in your opinion the right place to put this to?
> Helper class that redirects OutputStream to Log
> ---
>
> Key: LOGGING-152
> URL: https://issues.apache.org/jira/browse/LOGGING-152
> Project: Commons Logging
> Issue Type: Improvement
>Affects Versions: 1.1.1
>Reporter: Dmitry Katsubo
>Priority: Major
> Attachments: LoggingOutputStream.java
>
>
> Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for
> debug messages to be printed to. The attached class acts as a bridge between
> {{OutputStream}} and {{org.apache.commons.logging.Log}}.
> Example of usage:
> {code}
> PrintStream loggingPrintStream = new PrintStream(new
> LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, "[XJC] "));
> com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
> {code}
> Also has some overlap with LOGGING-110.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (LANG-1696) Add support of java collections to EqualsBuilder
Dmitry Katsubo created LANG-1696:
Summary: Add support of java collections to EqualsBuilder
Key: LANG-1696
URL: https://issues.apache.org/jira/browse/LANG-1696
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Reporter: Dmitry Katsubo
Provided that new {{HashSet<>().equals(Collections.emptySet())}} it would be
great if {{EqualsBuilder}} also supports that. Currently it checks that
[left/right classes are subclasses of each
other|https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java#L499],
however that does not hold for collections.
Suggestion: if either left or right is {{Collection}} or {{Map}} then delegate
equals to
{code}
public EqualsBuilder reflectionAppend(final Object lhs, final Object rhs) {
if (!isEquals()) {
return this;
}
if (lhs == rhs) {
return this;
}
if (lhs == null || rhs == null) {
setEquals(false);
return this;
}
if (lhs instanceof Collection || rhs instanceof Collection || lhs
instanceof Map || rhs instanceof Map) {
setEquals(lhs.equals(rhs));
return this;
}
...
{code}
Likely this mode should be additionally controlled (switched on/off), as
strictly speaking, it won't be a reflection tree walker starting from that
field.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-254) Improve MultipartStream public API
[ https://issues.apache.org/jira/browse/FILEUPLOAD-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17343105#comment-17343105 ] Dmitry Katsubo commented on FILEUPLOAD-254: --- It looks like it was "fixed" in commit [e0bfe29|https://github.com/apache/commons-fileupload/commit/e0bfe29d200975e78982db4b276829c4318100e1#diff-989ac0dee68b2b7eecb80eb79fdb59037526ac5922f896186fc0c3083f0c083b], hence from my point of view the issue could be closed (even though one would probably want to take a deeper look and really play with API to see that there are no surprises). > Improve MultipartStream public API > -- > > Key: FILEUPLOAD-254 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-254 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.3.1 >Reporter: Anton Gorbunov >Assignee: Jochen Wiedmann >Priority: Major > > In many cases user may need to get part content as an InputStream. > MultipartStream class already has such method - newInputStream(), but for > some reason it made package-private. > I suggest to make it public. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FILEUPLOAD-254) Improve MultipartStream public API
[
https://issues.apache.org/jira/browse/FILEUPLOAD-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15932497#comment-15932497
]
Dmitry Katsubo commented on FILEUPLOAD-254:
---
I vote for this improvement. I think the issue is similar to FILEUPLOAD-278. I
would suggest the method name like:
{code}
public InputStream getBodyDataInputStream();
{code}
or simply
{code}
public InputStream getInputStream();
{code}
> Improve MultipartStream public API
> --
>
> Key: FILEUPLOAD-254
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-254
> Project: Commons FileUpload
> Issue Type: Improvement
>Affects Versions: 1.3.1
>Reporter: Anton Gorbunov
>Assignee: Jochen Wiedmann
>
> In many cases user may need to get part content as an InputStream.
> MultipartStream class already has such method - newInputStream(), but for
> some reason it made package-private.
> I suggest to make it public.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (COMPRESS-313) CompressorStreamFactory auto-detection of LZMA stream
Dmitry Katsubo created COMPRESS-313:
---
Summary: CompressorStreamFactory auto-detection of LZMA stream
Key: COMPRESS-313
URL: https://issues.apache.org/jira/browse/COMPRESS-313
Project: Commons Compress
Issue Type: Improvement
Components: Compressors
Affects Versions: 1.9
Reporter: Dmitry Katsubo
Priority: Minor
It would be nice if {{CompressorStreamFactory}} can auto-detect LZMA compressed
stream in method {{createCompressorInputStream(InputStream in)}}. According to
[this
thread|https://sourceforge.net/p/sevenzip/discussion/45798/thread/2e59850f] the
magic numbers can be 0x5D, 0x00, 0x00.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882011#comment-13882011
]
Dmitry Katsubo commented on LANG-909:
-
[~charles_hon...@intuit.com] Then I would completely agree that this bug can be
closed. Looking forward for next 3.x release!
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881365#comment-13881365
]
Dmitry Katsubo commented on LANG-909:
-
[~britter]: As you can read from {{FastDateParser}} JavaDoc, it supports into
Gregorian calendars. For other calendars it creates {{SimpleDateFormat}}. In
such unpopular scenarios {{ThreadSafeSimpleDateFormat}} is still beneficial.
However added value is not big, so maybe one can copy code to his project
directly from this issue after googling a while.
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801641#comment-13801641
]
Dmitry Katsubo commented on LANG-909:
-
Perhaps Java8 does not need this class (it will have better date/time
functionality support), but {{commons-lang}} is Java1.5-compatible, is it?
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Fix For: Review Patch
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LANG-909:
Attachment: DateFormatAdapter.java
ThreadSafeSimpleDateFormatTest.java
ThreadSafeSimpleDateFormat.java
Attaching improved version (formatting applied, testing improved, added
delegating setters/getters).
I also attach the adapter for current {{FastDateFormat}} and {{FastDateParser}}
and testing these implementations via adapter (which I have referred in my last
comment).
{{FastDateParser}} in general services my needs, as I only work with Gregorian
calendar. For other calendars JavaDoc says it delegates parsing to
{{SimpleDateFormat}} (I have not found this place in code), thus for these
calendars {{ThreadSafeSimpleDateFormat}} is (potentially) faster as it shares
same {{SimpleDateFormat}} instance within a thread.
Does anyone has measurements on how {{FastDateParser}} is faster then
{{SimpleDateFormat}}?
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LANG-909:
Attachment: (was: ThreadSafeDateFormat.java)
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LANG-909:
Attachment: (was: ThreadSafeDateFormatTest.java)
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Attachments: DateFormatAdapter.java, ThreadSafeSimpleDateFormat.java,
ThreadSafeSimpleDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-909) Thread-safe wrapper for SimpleDateFormat
Dmitry Katsubo created LANG-909:
---
Summary: Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance of
{{SimpleDateFormat}} per thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LANG-909:
Attachment: ThreadSafeDateFormatTest.java
ThreadSafeDateFormat.java
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Attachments: ThreadSafeDateFormat.java, ThreadSafeDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-909) Thread-safe wrapper for SimpleDateFormat
[
https://issues.apache.org/jira/browse/LANG-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731429#comment-13731429
]
Dmitry Katsubo commented on LANG-909:
-
[~s...@apache.org]: I will apply the code style changes you have mentioned. To
make it easier: are there code formatting rules for Eclipse which I can
download? This from
[here|http://maven.apache.org/developers/conventions/code.html#Eclipse_3.2] are
for Maven project and seem to be different from what Apache commons is using.
Unit tests do not test different formats because from implementation it is
clear that formatting is delegated to {{SimpleDateFormat}}; adding such test
does not add any code or branch coverage to existing test thus to my mind it is
useless.
[~charles_hon...@intuit.com]: Future parser looks good. Will the adapter for
{{java.text.DateFormat}} be included? A lot of legacy/3rdparty code is based on
that JDK API, so it would be nice to keep compatibility.
Thread-safe wrapper for SimpleDateFormat
Key: LANG-909
URL: https://issues.apache.org/jira/browse/LANG-909
Project: Commons Lang
Issue Type: New Feature
Components: lang.time.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Attachments: ThreadSafeDateFormat.java, ThreadSafeDateFormatTest.java
{{SimpleDateFormat}} implementation in JDK is known to be [not
thread-safe|http://stackoverflow.com/questions/6840803/simpledateformat-thread-safety].
The attached helper class solves the problem by holding a separate instance
of {{SimpleDateFormat}} per thread.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LOGGING-152) Helper class that redirects OutputStream to Log
Dmitry Katsubo created LOGGING-152:
--
Summary: Helper class that redirects OutputStream to Log
Key: LOGGING-152
URL: https://issues.apache.org/jira/browse/LOGGING-152
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Dmitry Katsubo
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for debug
messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger,
LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-152) Helper class that redirects OutputStream to Log
[
https://issues.apache.org/jira/browse/LOGGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LOGGING-152:
---
Attachment: LoggingOutputStream.java
Helper class that redirects OutputStream to Log
---
Key: LOGGING-152
URL: https://issues.apache.org/jira/browse/LOGGING-152
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Dmitry Katsubo
Attachments: LoggingOutputStream.java
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for
debug messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-152) Helper class that redirects OutputStream to Log
[
https://issues.apache.org/jira/browse/LOGGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LOGGING-152:
---
Description:
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for debug
messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
was:
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for debug
messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger,
LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
Helper class that redirects OutputStream to Log
---
Key: LOGGING-152
URL: https://issues.apache.org/jira/browse/LOGGING-152
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Dmitry Katsubo
Attachments: LoggingOutputStream.java
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for
debug messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOGGING-152) Helper class that redirects OutputStream to Log
[
https://issues.apache.org/jira/browse/LOGGING-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LOGGING-152:
---
Description:
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for debug
messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
Also has some overlap with LOGGING-110.
was:
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for debug
messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
Helper class that redirects OutputStream to Log
---
Key: LOGGING-152
URL: https://issues.apache.org/jira/browse/LOGGING-152
Project: Commons Logging
Issue Type: Improvement
Affects Versions: 1.1.1
Reporter: Dmitry Katsubo
Attachments: LoggingOutputStream.java
Some libraries accept {{PrintStream}} or {{OutputStream}} as a target for
debug messages to be printed to. The attached class acts as a bridge between
{{OutputStream}} and {{org.apache.commons.logging.Log}}.
Example of usage:
{code}
PrintStream loggingPrintStream = new PrintStream(new
LoggingOutputStream(logger, LoggingOutputStream.LogLevel.INFO, [XJC] ));
com.sun.tools.xjc.Driver.run(opts, loggingPrintStream, loggingPrintStream);
{code}
Also has some overlap with LOGGING-110.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size
[
https://issues.apache.org/jira/browse/IO-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13638347#comment-13638347
]
Dmitry Katsubo commented on IO-356:
---
Sebb, fixing that for majority of cases is not bad, keeping in mind that now
simply does not work at all. Putting/resetting to a mark on the byte in the
middle of a character should not be a problem: you can define a contract
yourself and describe this very corner case in JavaDoc.
CharSequenceInputStream#reset() behaves incorrectly in case when buffer size
is not dividable by data size
--
Key: IO-356
URL: https://issues.apache.org/jira/browse/IO-356
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 2.4
Reporter: Dmitry Katsubo
Attachments: CharSequenceInputStreamTest.java
The size effect happens when buffer size of input stream is not dividable by
requested data size. The bug is hidden in {{CharSequenceInputStream#reset()}}
method which should also call (I think) {{bbuf.limit(0)}} otherwise next call
to {{CharSequenceInputStream#read()}} will return the remaining tail which
{{bbuf}} has accumulated.
In the attached test case the test fails, if {{dataSize = 13}} (not dividable
by 10) and runs OK if {{dataSize = 20}} (dividable by 10).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-222) ZipArchiveInputStream may read incorrect bytes from stream when processing nested ZIP
Dmitry Katsubo created COMPRESS-222:
---
Summary: ZipArchiveInputStream may read incorrect bytes from
stream when processing nested ZIP
Key: COMPRESS-222
URL: https://issues.apache.org/jira/browse/COMPRESS-222
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.5
Reporter: Dmitry Katsubo
The problem is relevant to COMPRESS-189, in particular it relates to processing
of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns incorrect
contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that given
file if TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x14
0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can see, the problem can be introduced at any random byte.
If the program is set {{READ_WHOLE_ENTRY=true}} then all entries are fully read
and MD5 sum is calculated. MD5 sum matches and all entries are correctly
reported as TIFF. Thus the problem is only present when entry is not fully read
and {{ArchiveInputStream.getNextEntry()}} is called.
Test ZIP can be downloaded from:
https://www.dropbox.com/s/h20wo6t0mwbgsqc/09815141_4.zip
It was originally taken from WIPO FTP, i.e. it is in public domain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-222) ZipArchiveInputStream may read incorrect bytes from stream when processing nested ZIP
[
https://issues.apache.org/jira/browse/COMPRESS-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated COMPRESS-222:
Attachment: ArchiveTest.java
ZipArchiveInputStream may read incorrect bytes from stream when processing
nested ZIP
-
Key: COMPRESS-222
URL: https://issues.apache.org/jira/browse/COMPRESS-222
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.5
Reporter: Dmitry Katsubo
Attachments: ArchiveTest.java, log_read_whole_entry.txt, log.txt,
md5.correct.txt
The problem is relevant to COMPRESS-189, in particular it relates to
processing of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns
incorrect contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that
given file if TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0
0x0 0x14 0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can see, the problem can be introduced at any random byte.
If the program is set {{READ_WHOLE_ENTRY=true}} then all entries are fully
read and MD5 sum is calculated. MD5 sum matches and all entries are correctly
reported as TIFF. Thus the problem is only present when entry is not fully
read and {{ArchiveInputStream.getNextEntry()}} is called.
Test ZIP can be downloaded from:
https://www.dropbox.com/s/h20wo6t0mwbgsqc/09815141_4.zip
It was originally taken from WIPO FTP, i.e. it is in public domain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-222) ZipArchiveInputStream may read incorrect bytes from stream when processing nested ZIP
[
https://issues.apache.org/jira/browse/COMPRESS-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated COMPRESS-222:
Attachment: log.txt
ZipArchiveInputStream may read incorrect bytes from stream when processing
nested ZIP
-
Key: COMPRESS-222
URL: https://issues.apache.org/jira/browse/COMPRESS-222
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.5
Reporter: Dmitry Katsubo
Attachments: ArchiveTest.java, log_read_whole_entry.txt, log.txt,
md5.correct.txt
The problem is relevant to COMPRESS-189, in particular it relates to
processing of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns
incorrect contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that
given file if TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0
0x0 0x14 0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can see, the problem can be introduced at any random byte.
If the program is set {{READ_WHOLE_ENTRY=true}} then all entries are fully
read and MD5 sum is calculated. MD5 sum matches and all entries are correctly
reported as TIFF. Thus the problem is only present when entry is not fully
read and {{ArchiveInputStream.getNextEntry()}} is called.
Test ZIP can be downloaded from:
https://www.dropbox.com/s/h20wo6t0mwbgsqc/09815141_4.zip
It was originally taken from WIPO FTP, i.e. it is in public domain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-222) ZipArchiveInputStream may read incorrect bytes from stream when processing nested ZIP
[
https://issues.apache.org/jira/browse/COMPRESS-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated COMPRESS-222:
Attachment: md5.correct.txt
ZipArchiveInputStream may read incorrect bytes from stream when processing
nested ZIP
-
Key: COMPRESS-222
URL: https://issues.apache.org/jira/browse/COMPRESS-222
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.5
Reporter: Dmitry Katsubo
Attachments: ArchiveTest.java, log_read_whole_entry.txt, log.txt,
md5.correct.txt
The problem is relevant to COMPRESS-189, in particular it relates to
processing of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns
incorrect contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that
given file if TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0
0x0 0x14 0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can see, the problem can be introduced at any random byte.
If the program is set {{READ_WHOLE_ENTRY=true}} then all entries are fully
read and MD5 sum is calculated. MD5 sum matches and all entries are correctly
reported as TIFF. Thus the problem is only present when entry is not fully
read and {{ArchiveInputStream.getNextEntry()}} is called.
Test ZIP can be downloaded from:
https://www.dropbox.com/s/h20wo6t0mwbgsqc/09815141_4.zip
It was originally taken from WIPO FTP, i.e. it is in public domain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-222) ZipArchiveInputStream may read incorrect bytes from stream when processing nested ZIP
[
https://issues.apache.org/jira/browse/COMPRESS-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated COMPRESS-222:
Description:
The problem is relevant to COMPRESS-189, in particular it relates to processing
of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns incorrect
contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that given
file is TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x14
0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can see, the problem can be introduced at any random byte.
If the program is set {{READ_WHOLE_ENTRY=true}} then all entries are fully read
and MD5 sum is calculated. MD5 sum matches and all entries are correctly
reported as TIFF. Thus the problem is only present when entry is not fully read
and {{ArchiveInputStream.getNextEntry()}} is called.
Test ZIP can be downloaded from:
https://www.dropbox.com/s/h20wo6t0mwbgsqc/09815141_4.zip
It was originally taken from WIPO FTP (i.e. it is in public domain) and was a
bit stripped.
Difficult to say what is the impact of this bug, but for 475 ZIP-in-ZIPs in my
collection I have found 3 examples of incorrect contents extraction.
was:
The problem is relevant to COMPRESS-189, in particular it relates to processing
of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns incorrect
contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that given
file if TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x14
0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can see, the problem can be introduced at any random byte.
If the program is set {{READ_WHOLE_ENTRY=true}} then all entries are fully read
and MD5 sum is calculated. MD5 sum matches and all entries are correctly
reported as TIFF. Thus the problem is only present when entry is not fully read
and {{ArchiveInputStream.getNextEntry()}} is called.
Test ZIP can be downloaded from:
https://www.dropbox.com/s/h20wo6t0mwbgsqc/09815141_4.zip
It was originally taken from WIPO FTP, i.e. it is in public domain.
ZipArchiveInputStream may read incorrect bytes from stream when processing
nested ZIP
-
Key: COMPRESS-222
URL: https://issues.apache.org/jira/browse/COMPRESS-222
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.5
Reporter: Dmitry Katsubo
Attachments: ArchiveTest.java, log_read_whole_entry.txt, log.txt,
md5.correct.txt
The problem is relevant to COMPRESS-189, in particular it relates to
processing of inner ZIP files.
Problem description:
If the archive entry is not fully read, then partial reading returns
incorrect contents.
In particular the given example loops trough all entries of 09815141_4.zip
ZIP archive, probing each entry to be a TIFF file. The probe assumes that
given file is TIFF, if it starts with bytes [0x49 0x49 0x2A 0x0 0x8 0x0 0x0
0x0 0x14 0x0].
Most entries are correctly reported as TIFF, except:
{code}
[ArchiveTest] 17.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 33.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x0 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 56.tif is something else
[ArchiveTest] Header contents: 0x49 0x49 0x2A 0x0 0x8 0x0 0x0 0x0 0x0 0x0
[ArchiveTest] 69.tif is something else
[ArchiveTest] Header contents: 0x49 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
{code}
As I can
[jira] [Commented] (COLLECTIONS-366) A light-weight list of integers
[
https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13596965#comment-13596965
]
Dmitry Katsubo commented on COLLECTIONS-366:
@ThomasNeidhart: I am on Benedikt's side.
{{range.contains(Double.valueOf(1.2d))}} should be false for integer range
{{[0..1]}}.
A light-weight list of integers
---
Key: COLLECTIONS-366
URL: https://issues.apache.org/jira/browse/COLLECTIONS-366
Project: Commons Collections
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Dmitry Katsubo
Fix For: 4.x
Attachments: COLLECTIONS-366.patch, RangeList_fixed1.zip
Sometimes there is a demand too have a list, that represents numbers within
some range (say, [5..10]). If the range is big (millions of records),
creating a dummy list that holds all instances of objects is too expensive.
The provided implementation (attached to this issue) solves this problem.
Nice to have in commons collections.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-366) A light-weight list of integers
[
https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597024#comment-13597024
]
Dmitry Katsubo commented on COLLECTIONS-366:
_rejecting other numbers that do not correspond exactly to the int numbers
contained in the range_
I agree with that. Indeed this is a list of integers, not mathematical range.
I also confirm that my initial implementation (attached to this issue) is wrong
in this respect: should read {{if (o instanceof Integer) ...}}.
P.S. Hopefully this class will be finally included in commons-collections.
A light-weight list of integers
---
Key: COLLECTIONS-366
URL: https://issues.apache.org/jira/browse/COLLECTIONS-366
Project: Commons Collections
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Dmitry Katsubo
Fix For: 4.x
Attachments: COLLECTIONS-366.patch, RangeList_fixed1.zip
Sometimes there is a demand too have a list, that represents numbers within
some range (say, [5..10]). If the range is big (millions of records),
creating a dummy list that holds all instances of objects is too expensive.
The provided implementation (attached to this issue) solves this problem.
Nice to have in commons collections.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-366) A light-weight list of integers
[
https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597276#comment-13597276
]
Dmitry Katsubo commented on COLLECTIONS-366:
Benedikt, the patch was created (and attached) by Thomas. In
{{RangeList_fixed1.zip}} I have supplied Unit Tests.
What I can do is to fork
[commons-collections|https://github.com/apache/commons-collections/] and
initiate a pull. Agreed?
A light-weight list of integers
---
Key: COLLECTIONS-366
URL: https://issues.apache.org/jira/browse/COLLECTIONS-366
Project: Commons Collections
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Dmitry Katsubo
Fix For: 4.x
Attachments: COLLECTIONS-366.patch, RangeList_fixed1.zip
Sometimes there is a demand too have a list, that represents numbers within
some range (say, [5..10]). If the range is big (millions of records),
creating a dummy list that holds all instances of objects is too expensive.
The provided implementation (attached to this issue) solves this problem.
Nice to have in commons collections.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COLLECTIONS-366) A light-weight list of integers
[
https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13597276#comment-13597276
]
Dmitry Katsubo edited comment on COLLECTIONS-366 at 3/8/13 4:51 PM:
Benedikt, the patch was created (and attached) by Thomas (he has also made a
great optimization – thanks for that). In {{RangeList_fixed1.zip}} I have
supplied Unit Tests.
What I can do is fork
[commons-collections|https://github.com/apache/commons-collections/] and
initiate a pull. Agreed?
was (Author: dma_k):
Benedikt, the patch was created (and attached) by Thomas. In
{{RangeList_fixed1.zip}} I have supplied Unit Tests.
What I can do is to fork
[commons-collections|https://github.com/apache/commons-collections/] and
initiate a pull. Agreed?
A light-weight list of integers
---
Key: COLLECTIONS-366
URL: https://issues.apache.org/jira/browse/COLLECTIONS-366
Project: Commons Collections
Issue Type: New Feature
Affects Versions: 3.2
Reporter: Dmitry Katsubo
Fix For: 4.x
Attachments: COLLECTIONS-366.patch, RangeList_fixed1.zip
Sometimes there is a demand too have a list, that represents numbers within
some range (say, [5..10]). If the range is big (millions of records),
creating a dummy list that holds all instances of objects is too expensive.
The provided implementation (attached to this issue) solves this problem.
Nice to have in commons collections.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-366) A light-weighted list of integers
[ https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13591842#comment-13591842 ] Dmitry Katsubo commented on COLLECTIONS-366: Adrain, in your very example there is no benefit, sure. But if passed list is a parameter, it makes sense. Also can be used for unit tests. A light-weighted list of integers - Key: COLLECTIONS-366 URL: https://issues.apache.org/jira/browse/COLLECTIONS-366 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: Dmitry Katsubo Attachments: RangeList_fixed1.zip Sometimes there is a demand too have a list, that represents numbers within some range (say, [5..10]). If the range is big (millions of records), creating a dummy list that holds all instances of objects is too expensive. The provided implementation (attached to this issue) solves this problem. Nice to have in commons collections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size
[
https://issues.apache.org/jira/browse/IO-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13586231#comment-13586231
]
Dmitry Katsubo commented on IO-356:
---
So, is there any counter-example for {{bbuf.limit(0)}} solution? If no then why
not to start with it?
CharSequenceInputStream#reset() behaves incorrectly in case when buffer size
is not dividable by data size
--
Key: IO-356
URL: https://issues.apache.org/jira/browse/IO-356
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 2.4
Reporter: Dmitry Katsubo
Attachments: CharSequenceInputStreamTest.java
The size effect happens when buffer size of input stream is not dividable by
requested data size. The bug is hidden in {{CharSequenceInputStream#reset()}}
method which should also call (I think) {{bbuf.limit(0)}} otherwise next call
to {{CharSequenceInputStream#read()}} will return the remaining tail which
{{bbuf}} has accumulated.
In the attached test case the test fails, if {{dataSize = 13}} (not dividable
by 10) and runs OK if {{dataSize = 20}} (dividable by 10).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-208) Add support for ZIP archives with PK00PK signature
[
https://issues.apache.org/jira/browse/COMPRESS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541079#comment-13541079
]
Dmitry Katsubo commented on COMPRESS-208:
-
The given attachment is a part of published patent:
Add support for ZIP archives with PK00PK signature
--
Key: COMPRESS-208
URL: https://issues.apache.org/jira/browse/COMPRESS-208
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Attachments: EP02797238.zip
ZIP archive with PK00PK signature is not recognized as ZIP archive by
{{ArchiveStreamFactory.createArchiveInputStream()}}. Header hexdump:
{code}
00: 50 4B 30 30 50 4B 03 04 │ 14 00 00 00 08 00 48 7D PK00PK♥♦¶ ◘
H}
10: F4 36 04 E0 50 2C 04 27 │ 01 00 E2 3F 10 00 37 00 Ї6♦рP,♦'☺ т?► 7
20: 00 00 4E 39 32 30 34 35 │ 20 53 45 52 20 4A 52 4EN92045 SER
JRN
30: 20 72 65 76 69 73 65 64 │ 20 73 65 71 20 6C 69 73 revised seq
lis
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COMPRESS-208) Add support for ZIP archives with PK00PK signature
[
https://issues.apache.org/jira/browse/COMPRESS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541079#comment-13541079
]
Dmitry Katsubo edited comment on COMPRESS-208 at 12/30/12 3:20 PM:
---
The given attachment is a part of published patent:
http://worldwide.espacenet.com/publicationDetails/biblio?DB=EPODOCII=0ND=3adjacent=truelocale=en_EPFT=Ddate=20050330CC=EPNR=1517606A2KC=A2
however I am not sure if published in world of patents is compatible with
Apache license. Not to risk, just create a new such file or truncate the text
file within the archive.
was (Author: dma_k):
The given attachment is a part of published patent:
Add support for ZIP archives with PK00PK signature
--
Key: COMPRESS-208
URL: https://issues.apache.org/jira/browse/COMPRESS-208
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Attachments: EP02797238.zip
ZIP archive with PK00PK signature is not recognized as ZIP archive by
{{ArchiveStreamFactory.createArchiveInputStream()}}. Header hexdump:
{code}
00: 50 4B 30 30 50 4B 03 04 │ 14 00 00 00 08 00 48 7D PK00PK♥♦¶ ◘
H}
10: F4 36 04 E0 50 2C 04 27 │ 01 00 E2 3F 10 00 37 00 Ї6♦рP,♦'☺ т?► 7
20: 00 00 4E 39 32 30 34 35 │ 20 53 45 52 20 4A 52 4EN92045 SER
JRN
30: 20 72 65 76 69 73 65 64 │ 20 73 65 71 20 6C 69 73 revised seq
lis
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COMPRESS-208) Add support for ZIP archives with PK00PK signature
[
https://issues.apache.org/jira/browse/COMPRESS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13492278#comment-13492278
]
Dmitry Katsubo edited comment on COMPRESS-208 at 11/16/12 2:03 PM:
---
No idea how to create such an archive, I know that WinRAR and WinZIP can open
it. Please Google for PK00PK to find more information about this subtype of
archive, from [what I have
found|http://java.net/nonav/projects/truezip/lists/users/archive/2012-04/message/16]
it is used for archive splitting (volumes support).
Add support for ZIP archives with PK00PK signature
--
Key: COMPRESS-208
URL: https://issues.apache.org/jira/browse/COMPRESS-208
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Attachments: EP02797238.zip
ZIP archive with PK00PK signature is not recognized as ZIP archive by
{{ArchiveStreamFactory.createArchiveInputStream()}}. Header hexdump:
{code}
00: 50 4B 30 30 50 4B 03 04 │ 14 00 00 00 08 00 48 7D PK00PK♥♦¶ ◘
H}
10: F4 36 04 E0 50 2C 04 27 │ 01 00 E2 3F 10 00 37 00 Ї6♦рP,♦'☺ т?► 7
20: 00 00 4E 39 32 30 34 35 │ 20 53 45 52 20 4A 52 4EN92045 SER
JRN
30: 20 72 65 76 69 73 65 64 │ 20 73 65 71 20 6C 69 73 revised seq
lis
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-189) ZipArchiveInputStream may read 0 bytes when reading from a nested Zip file
[
https://issues.apache.org/jira/browse/COMPRESS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498834#comment-13498834
]
Dmitry Katsubo commented on COMPRESS-189:
-
I confirm the problem. I agree that {{java.util.zip.Inflater}} is not used
according to JavaDocs and that causes the problem in some cases.
ZipArchiveInputStream may read 0 bytes when reading from a nested Zip file
--
Key: COMPRESS-189
URL: https://issues.apache.org/jira/browse/COMPRESS-189
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: JDK 1.6 64-bit, Windows 7
Reporter: Daniel Lowe
Priority: Blocker
When the following code is run an error Underlying input stream returned
zero bytes is produced. If the commented line is uncommented it can be seen
that the ZipArchiveInputStream returned 0 bytes. This only happens the first
time read is called, subsequent calls work as expected i.e. the following
code actually works correctly with that line uncommented!
The zip file used to produce this behavious is available at
http://wwmm.ch.cam.ac.uk/~dl387/test.ZIP
If this is not the correct way of processing a zip file of zip files please
let me know. Also I believe whilst ZipFile can iterate over entries fast due
to being able to look at the master table whilst ZipArchiveInputStream
cannot. Is there anyway of instantiating a ZipFile from a zip file inside
another zip file without first extracting the nested zip file?
ZipFile zipFile = new ZipFile(C:/test.ZIP);
for (EnumerationZipArchiveEntry iterator = zipFile.getEntries();
iterator.hasMoreElements(); ) {
ZipArchiveEntry entry = iterator.nextElement();
InputStream is = new BufferedInputStream(zipFile.getInputStream(entry));
ZipArchiveInputStream zipInput = new ZipArchiveInputStream(is);
ZipArchiveEntry innerEntry;
while ((innerEntry = zipInput.getNextZipEntry()) != null){
if (innerEntry.getName().endsWith(XML)){
//zipInput.read();
System.out.println(IOUtils.toString(zipInput));
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size
Dmitry Katsubo created IO-356:
-
Summary: CharSequenceInputStream#reset() behaves incorrectly in
case when buffer size is not dividable by data size
Key: IO-356
URL: https://issues.apache.org/jira/browse/IO-356
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 2.4
Reporter: Dmitry Katsubo
Attachments: CharSequenceInputStreamTest.java
The size effect happens when buffer size of input stream is not dividable by
requested data size. The bug is hidden in {{CharSequenceInputStream#reset()}}
method which should also call (I think) {{bbuf.limit(0)}} otherwise next call
to {{CharSequenceInputStream#read()}} will return the remaining tail which
{{bbuf}} has accumulated.
In the attached test case the test fails, if {{dataSize = 13}} (not dividable
by 10) and runs OK if {{dataSize = 20}} (dividable by 10).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-356) CharSequenceInputStream#reset() behaves incorrectly in case when buffer size is not dividable by data size
[
https://issues.apache.org/jira/browse/IO-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated IO-356:
--
Attachment: CharSequenceInputStreamTest.java
CharSequenceInputStream#reset() behaves incorrectly in case when buffer size
is not dividable by data size
--
Key: IO-356
URL: https://issues.apache.org/jira/browse/IO-356
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 2.4
Reporter: Dmitry Katsubo
Attachments: CharSequenceInputStreamTest.java
The size effect happens when buffer size of input stream is not dividable by
requested data size. The bug is hidden in {{CharSequenceInputStream#reset()}}
method which should also call (I think) {{bbuf.limit(0)}} otherwise next call
to {{CharSequenceInputStream#read()}} will return the remaining tail which
{{bbuf}} has accumulated.
In the attached test case the test fails, if {{dataSize = 13}} (not dividable
by 10) and runs OK if {{dataSize = 20}} (dividable by 10).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-208) Add support for ZIP archives with PK00PK signature
Dmitry Katsubo created COMPRESS-208:
---
Summary: Add support for ZIP archives with PK00PK signature
Key: COMPRESS-208
URL: https://issues.apache.org/jira/browse/COMPRESS-208
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
ZIP archive with PK00PK signature is not recognized as ZIP archive by
{{ArchiveStreamFactory.createArchiveInputStream()}}. Header hexdump:
{code}
00: 50 4B 30 30 50 4B 03 04 │ 14 00 00 00 08 00 48 7D PK00PK♥♦¶ ◘ H}
10: F4 36 04 E0 50 2C 04 27 │ 01 00 E2 3F 10 00 37 00 Ї6♦рP,♦'☺ т?► 7
20: 00 00 4E 39 32 30 34 35 │ 20 53 45 52 20 4A 52 4EN92045 SER JRN
30: 20 72 65 76 69 73 65 64 │ 20 73 65 71 20 6C 69 73 revised seq lis
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-209) DOC is incorrectly recognized as TAR
Dmitry Katsubo created COMPRESS-209:
---
Summary: DOC is incorrectly recognized as TAR
Key: COMPRESS-209
URL: https://issues.apache.org/jira/browse/COMPRESS-209
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Empty DOC is autodetected as TAR by
{{ArchiveStreamFactory.createArchiveInputStream(InputStream)}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-209) DOC is incorrectly recognized as TAR
[
https://issues.apache.org/jira/browse/COMPRESS-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated COMPRESS-209:
Attachment: test.doc
DOC is incorrectly recognized as TAR
Key: COMPRESS-209
URL: https://issues.apache.org/jira/browse/COMPRESS-209
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Attachments: test.doc
Empty DOC is autodetected as TAR by
{{ArchiveStreamFactory.createArchiveInputStream(InputStream)}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-846) StringUtils.equals() / CharSequenceUtils.regionMatches() assumes that CharSequence.toString() implementation is effective
[
https://issues.apache.org/jira/browse/LANG-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo updated LANG-846:
Attachment: CharSequenceUtils.patch
Here goes the patch. The patch follows slow but memory efficient approach.
StringUtils.equals() / CharSequenceUtils.regionMatches() assumes that
CharSequence.toString() implementation is effective
-
Key: LANG-846
URL: https://issues.apache.org/jira/browse/LANG-846
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
Attachments: CharSequenceUtils.patch
In my case I have {{CharSequence}} that implements a lazy string which is
stored on disk, and although {{toString()}} implementation is valid, it is
very expensive plus can potentially cause OOM.
Thus {{CharSequenceUtils.regionMatches()}} should really do char-by-char
comparison, leaving the optimization to underlying {{CharSequence}}
implementation.
Maybe {{CharSequenceUtils.regionMatches()}} could check that passed
{{CharSequence}} is standard implementation (like {{StringBuilder}},
{{StringBuffer}}) that has effective {{toString()}} implementation, but
this implementation ends up with creating new {{String}} object and thus
duplicating the character buffer. So we have classical speed/memory trade-off.
P.S. [Line 192 of
CharSequenceUtils()|http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSequenceUtils.java?revision=1199894view=markup#l192]
reads
{{TODO: Implement rather than convert to String}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-846) StringUtils.equals() / CharSequenceUtils.regionMatches() assumes that CharSequence.toString() implementation is effective
Dmitry Katsubo created LANG-846:
---
Summary: StringUtils.equals() / CharSequenceUtils.regionMatches()
assumes that CharSequence.toString() implementation is effective
Key: LANG-846
URL: https://issues.apache.org/jira/browse/LANG-846
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Dmitry Katsubo
Priority: Minor
In my case I have {{CharSequence}} that implements a lazy string which is
stored on disk, and although {{toString()}} implementation is valid, it is very
expensive plus can potentially cause OOM.
Thus {{CharSequenceUtils.regionMatches()}} should really do char-by-char
comparison, leaving the optimization to underlying {{CharSequence}}
implementation.
Maybe {{CharSequenceUtils.regionMatches()}} could check that passed
{{CharSequence}} is standard implementation (like {{StringBuilder}},
{{StringBuffer}}) that has effective {{toString()}} implementation, but this
implementation ends up with creating new {{String}} object and thus duplicating
the character buffer. So we have classical speed/memory trade-off.
P.S. [Line 192 of
CharSequenceUtils()|http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSequenceUtils.java?revision=1199894view=markup#l192]
reads
{{TODO: Implement rather than convert to String}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-786) StringUtils equals() relies on undefined behavior
[
https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13479161#comment-13479161
]
Dmitry Katsubo commented on LANG-786:
-
I think there is still area for improvement: [line 192 of
CharSequenceUtils()|http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSequenceUtils.java?revision=1199894view=markup#l192]
reads
{{TODO: Implement rather than convert to String}}
In my case I have {{CharSequence}} that implements a lazy string, and
{{toString()}} implementation is very expensive plus can potentially cause OOM.
Thus {{CharSequenceUtils.regionMatches()}} should really do char-by-char
comparison, leaving the optimization to underlying {{CharSequence}}
implementation.
StringUtils equals() relies on undefined behavior
-
Key: LANG-786
URL: https://issues.apache.org/jira/browse/LANG-786
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.x
Environment: java version 1.7.0_02
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Fedora 15 AMD64
Reporter: Daniel Trebbien
Labels: StringUtils
Fix For: 3.2
Attachments: equals.patch
Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the
JavaDoc block has contained the following note:
{quote}
This interface does not refine the general contracts of the equals and
hashCode methods. The result of comparing two objects that implement
CharSequence is therefore, in general, undefined. Each object may be
implemented by a different class, and there is no guarantee that each class
will be capable of testing its instances for equality with those of the other.
{quote}
When the signature of the StringUtils equals() method was changed from
{{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in
R920543, the implementation still relied on calling
CharSequence#equals(Object) even though, in general, the result is undefined.
One example where {{equals(Object)}} returns {{false}} even though, as
CharSequences, two objects represent equal sequences is when one object is an
instance of {{javax.lang.model.element.Name}} and the other object is a
String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COLLECTIONS-366) A light-weighted list of integers
[ https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Katsubo updated COLLECTIONS-366: --- Attachment: RangeList_fixed1.zip The fix for subList() functionality. A light-weighted list of integers - Key: COLLECTIONS-366 URL: https://issues.apache.org/jira/browse/COLLECTIONS-366 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: Dmitry Katsubo Attachments: RangeList_fixed1.zip Sometimes there is a demand too have a list, that represents numbers within some range (say, [5..10]). If the range is big (millions of records), creating a dummy list that holds all instances of objects is too expensive. The provided implementation (attached to this issue) solves this problem. Nice to have in commons collections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-366) A light-weighted list of integers
[ https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Katsubo updated COLLECTIONS-366: --- Attachment: (was: RangeList.zip) A light-weighted list of integers - Key: COLLECTIONS-366 URL: https://issues.apache.org/jira/browse/COLLECTIONS-366 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: Dmitry Katsubo Attachments: RangeList_fixed1.zip Sometimes there is a demand too have a list, that represents numbers within some range (say, [5..10]). If the range is big (millions of records), creating a dummy list that holds all instances of objects is too expensive. The provided implementation (attached to this issue) solves this problem. Nice to have in commons collections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COLLECTIONS-366) A light-weighted list of integers
A light-weighted list of integers - Key: COLLECTIONS-366 URL: https://issues.apache.org/jira/browse/COLLECTIONS-366 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: Dmitry Katsubo Sometimes there is a demand too have a list, that represents numbers within some range (say, [5..10]). If the range is big (millions of records), creating a dummy list that holds all instances of objects is too expensive. The provided implementation (attached to this issue) solves this problem. Nice to have in commons collections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COLLECTIONS-366) A light-weighted list of integers
[ https://issues.apache.org/jira/browse/COLLECTIONS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Katsubo updated COLLECTIONS-366: --- Attachment: RangeList.zip A light-weighted list of integers - Key: COLLECTIONS-366 URL: https://issues.apache.org/jira/browse/COLLECTIONS-366 Project: Commons Collections Issue Type: New Feature Affects Versions: 3.2 Reporter: Dmitry Katsubo Attachments: RangeList.zip Sometimes there is a demand too have a list, that represents numbers within some range (say, [5..10]). If the range is big (millions of records), creating a dummy list that holds all instances of objects is too expensive. The provided implementation (attached to this issue) solves this problem. Nice to have in commons collections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COLLECTIONS-365) [collections] ListOrderedSet implementing java.util.List
[
https://issues.apache.org/jira/browse/COLLECTIONS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Katsubo closed COLLECTIONS-365.
--
Resolution: Fixed
I agree with your comments. Makes sense.
[collections] ListOrderedSet implementing java.util.List
Key: COLLECTIONS-365
URL: https://issues.apache.org/jira/browse/COLLECTIONS-365
Project: Commons Collections
Issue Type: Improvement
Components: Set
Affects Versions: 3.2
Reporter: Dmitry Katsubo
It looks like nothing prevents {{ListOrderedSet}} to implement
{{java.util.List}} interface. One need to implement just few methods:
set(int index, Object element);
ListIterator listIterator();
List subList(int fromIndex, int toIndex);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COLLECTIONS-365) [collections] ListOrderedSet implementing java.util.List
[collections] ListOrderedSet implementing java.util.List
Key: COLLECTIONS-365
URL: https://issues.apache.org/jira/browse/COLLECTIONS-365
Project: Commons Collections
Issue Type: Improvement
Components: Set
Affects Versions: 3.2
Reporter: Dmitry Katsubo
It looks like nothing prevents {{ListOrderedSet}} to implement
{{java.util.List}} interface. One need to implement just few methods:
set(int index, Object element);
ListIterator listIterator();
List subList(int fromIndex, int toIndex);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-97) CompressorStreamFactory should support stream auto-detection
CompressorStreamFactory should support stream auto-detection Key: COMPRESS-97 URL: https://issues.apache.org/jira/browse/COMPRESS-97 Project: Commons Compress Issue Type: Improvement Affects Versions: 1.0 Reporter: Dmitry Katsubo I propose to add bzip2/gzip input stream detection to CompressorStreamFactory based on magic numbers (the same way it is done for ArchiveStreamFactory). Also bzip2 and gz constants should be declared as public static final String constants to be referred by constant name (not ugly value). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-61) ArchiveStreamFactory could have static methods as well
[
https://issues.apache.org/jira/browse/COMPRESS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12841301#action_12841301
]
Dmitry Katsubo commented on COMPRESS-61:
Torsten, I completely understand your position and argumentation. But in 99% of
the cases this factory will be used just to create available compressors. In
another 1% of the cases I would possibly extend current factory with some more
exotic compressor, which only I know how to implement. OK, in this case my
steps are:
- I need to create {{MyArchiveStreamFactory}} that extends
{{ArchiveStreamFactory}} and override e.g. {{createArchiveInputStream()}}
- Now I need to pass this factory somewhere. What type I will pass? Of course,
I can pass more generic type {{ArchiveStreamFactory}} and it will work fine, as
it has methods overridden. But will I put put compile-time dependency on the
rest of my project on {{commons-compress}} library? No. So I will pass
{{MyArchiveStreamFactory}}.
The situation changes, if I _introduce the interface for the factory_. As there
are no interfaces defined in {{commons-compress}}, I will use some
infrastructure, which is build on the top of existing {{ArchiveStreamFactory}}.
And again, it brings no benefits on how
{{ArchiveStreamFactory.createArchiveInputStream()}} is exposed.
So I would say: _using {{static}} methods for factory methods does not limit
its usage_. All above is just my opinion, which may be wrong. If you have any
counter-cases, please, comment.
ArchiveStreamFactory could have static methods as well
--
Key: COMPRESS-61
URL: https://issues.apache.org/jira/browse/COMPRESS-61
Project: Commons Compress
Issue Type: Improvement
Reporter: Sebb
ArchiveStreamFactory currently has to be instantiated in order to use it.
The methods have to be instance methods in order for subclasses to override
them, but until that is done (will it ever be done?) it seems a bit
unnecessary to create an instance of the class.
Perhaps there could be a private static instance of the class that could be
used with public static methods?
The same considerations apply to the other factories.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COMPRESS-61) ArchiveStreamFactory could have static methods as well
[
https://issues.apache.org/jira/browse/COMPRESS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12841301#action_12841301
]
Dmitry Katsubo edited comment on COMPRESS-61 at 3/4/10 4:05 PM:
Torsten, I completely understand your position and argumentation. But in 99% of
the cases this factory will be used just to create available compressors. In
another 1% of the cases I would possibly extend current factory with some more
exotic compressor, which only I know how to implement. OK, in this case my
steps are:
- I need to create {{MyArchiveStreamFactory}} that extends
{{ArchiveStreamFactory}} and override e.g. {{createArchiveInputStream()}}
- Now I need to pass this factory somewhere. What type I will pass? Of course,
I can pass more generic type {{ArchiveStreamFactory}} and it will work fine, as
it has methods overridden. But will I put put compile-time dependency on the
rest of my project on {{commons-compress}} library? No. So I will pass
{{MyArchiveStreamFactory}} and I don't mind in my implementation, how to call
the parent method: statically or via {{super.}}.
The situation changes, if I _introduce the interface for the factory_. As there
are no interfaces defined in {{commons-compress}}, I will use some
infrastructure, which is build on the top of existing {{ArchiveStreamFactory}}.
And again, it brings no benefits on how
{{ArchiveStreamFactory.createArchiveInputStream()}} is exposed.
So I would say: _using {{static}} methods for factory methods does not limit
its usage_. All above is just my opinion, which may be wrong. If you have any
counter-cases, please, comment.
was (Author: dma_k):
Torsten, I completely understand your position and argumentation. But in
99% of the cases this factory will be used just to create available
compressors. In another 1% of the cases I would possibly extend current factory
with some more exotic compressor, which only I know how to implement. OK, in
this case my steps are:
- I need to create {{MyArchiveStreamFactory}} that extends
{{ArchiveStreamFactory}} and override e.g. {{createArchiveInputStream()}}
- Now I need to pass this factory somewhere. What type I will pass? Of course,
I can pass more generic type {{ArchiveStreamFactory}} and it will work fine, as
it has methods overridden. But will I put put compile-time dependency on the
rest of my project on {{commons-compress}} library? No. So I will pass
{{MyArchiveStreamFactory}}.
The situation changes, if I _introduce the interface for the factory_. As there
are no interfaces defined in {{commons-compress}}, I will use some
infrastructure, which is build on the top of existing {{ArchiveStreamFactory}}.
And again, it brings no benefits on how
{{ArchiveStreamFactory.createArchiveInputStream()}} is exposed.
So I would say: _using {{static}} methods for factory methods does not limit
its usage_. All above is just my opinion, which may be wrong. If you have any
counter-cases, please, comment.
ArchiveStreamFactory could have static methods as well
--
Key: COMPRESS-61
URL: https://issues.apache.org/jira/browse/COMPRESS-61
Project: Commons Compress
Issue Type: Improvement
Reporter: Sebb
ArchiveStreamFactory currently has to be instantiated in order to use it.
The methods have to be instance methods in order for subclasses to override
them, but until that is done (will it ever be done?) it seems a bit
unnecessary to create an instance of the class.
Perhaps there could be a private static instance of the class that could be
used with public static methods?
The same considerations apply to the other factories.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
