[jira] [Commented] (LANG-1726) ExceptionUtils.asRuntimeException is not a good replacement for deprecated ExceptionUtils.rethrow
[
https://issues.apache.org/jira/browse/LANG-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803352#comment-17803352
]
Niall Pemberton commented on LANG-1726:
---
Václav has identified the main issue. It looks like the intention of the
original commit was to simply rename the method, I assume the intention was to
make it more understandable as to what it does, but there are two problems with
it
# The return type was incorrectly from to
which makes it unusable since the return type must match the return type of the
calling method which will not be a RuntimeException
# The original _*rethrow*_ method name accurately described what it did (it
rethrows the original exception, but tricks the compiler into thinking its a
RuntimeException). Changing the name to _*asRuntimeException*_ introduces a
confusion because it just rethrows the original exception, which may not be a
RuntimeException.
So, for me, the first thing is to decide what todo. Ideally IMO we should get
rid of the new _*asRuntimeException*_ method. I guess since its part of a
release, that means it should be deprecated with a note to use the original
_*rethrow*_ method.
Once its agreed what todo about this, then I think the javadoc can be corrected
or improved.
> ExceptionUtils.asRuntimeException is not a good replacement for deprecated
> ExceptionUtils.rethrow
> -
>
> Key: LANG-1726
> URL: https://issues.apache.org/jira/browse/LANG-1726
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.exception.*
>Affects Versions: 3.14.0
>Reporter: Václav Haisman
>Priority: Major
> Fix For: 3.15.0
>
>
> I have been doing pass over deprecated warning in our code and one of them is
> that {{org.apache.commons.lang3.exception.ExceptionUtils#rethrow}} is
> deprecated. Its comment says "Use asRuntimeException(Throwable)." However,
> {{asRuntimeException()}} is not a good replacement. It lacks the generic type
> parameter R that the rethrow method has. In fact, the comment that says...
> {noformat}
> Returns:
> Never actually returned, this generic type matches any type which the calling
> site requires. [..]
> {noformat}
> ...is lying.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-337) ByteOrderMark can be refactored as an enum
[ https://issues.apache.org/jira/browse/IO-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17800316#comment-17800316 ] Niall Pemberton commented on IO-337: I will -1 this change if it is ever committed since it would severely limit what is provided by the current implementation and prevent it being used for its original purpose. As I said in 2015 and if you look at the Wikidepdia page, there are more than 5 listed BOMs. The original poster is incorrect in stating that it is mis-used in XMLReader - from memory this code came from Tika and was the original purpose for being developed (XML Guessing). In its current implementation this functionality can be used for other purposes, not just BOMs and so its a regressive step to make a change that would prevent that and limit functionality. This works perfectly well as it is and I see zero benefit and lots of downsides to this change, so we should close this as WONTFIX > ByteOrderMark can be refactored as an enum > -- > > Key: IO-337 > URL: https://issues.apache.org/jira/browse/IO-337 > Project: Commons IO > Issue Type: New Feature >Reporter: Yaniv Kunda >Priority: Minor > Fix For: 3.x > > Attachments: ByteOrderMark-enum.patch > > > ByteOrderMark is used primarily for encapsulating the data regarding to > Unicode BOMs. Since those are fixed, it would make sense to make it an enum, > instead of a public class. > I have attached a patch that only covers ByteOrderMark itself, including an > additional getCharset() utility method, and toString() simplification. > This patch does not cover: > 1) Its incorrect use (per its perceived purpose) in > XmlStreamReader.XML_GUESS_BYTES > 2) The now-unnecessary tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (POOL-372) CallStackUtils mishandles security manager check part 2
[
https://issues.apache.org/jira/browse/POOL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653233#comment-17653233
]
Niall Pemberton commented on POOL-372:
--
The Security Manager was deprecated in *Java 17,* so at some point this feature
will need to be removed:
* [https://openjdk.org/jeps/411]
>From what I understand, this feature produces a limited stack trace (no method
>names or line numbers) in a more efficient manner than the Throwable
>implementation for debugging purposes.
Perhaps an alternative would be to replace the whole stack trace debugging
feature with *Flight Recorder* events introduced in {*}Java 11{*}?
* https://openjdk.org/jeps/328
> CallStackUtils mishandles security manager check part 2
> ---
>
> Key: POOL-372
> URL: https://issues.apache.org/jira/browse/POOL-372
> Project: Commons Pool
> Issue Type: Bug
>Reporter: Volker Kleinschmidt
>Priority: Major
>
> This ticket is for (b).
> CallStackUtils determines at initialization time whether it is allowed to
> create a security manager, then sticks that info into a static variable and
> never checks it again, relying on this check to later try to create a
> SecurityManager for a SecurityManagerCallStack. This is doubly wrong:
> a) If the code is running in a privileged context at init time, it determines
> that it can create a security manager, and then later naively assumes that
> henceforth all code is privileged and also can create a security manager. Of
> course this is not true, otherwise one would not need a security manager in
> the first place! This info can never be kept in a static variable, it's
> extremely context-dependent. So this leads to AccessControlException from
> invoking newCallStack() if abandoned object logging is enabled.
> b) The permission to create a security manager must never be granted to any
> code, unless that code has AllPermission in the first place, i.e. is already
> fully privileged. This is because this permission allows circumventing the
> security manager completely (simply create one that lets all checks pass).
> Therefore even just checking whether you're allowed to create a secmgr is
> naive - if a secmgr is installed at all you should assume that you're NOT
> privileged enough to do this, simply because for sure some code that calls
> your code will not be privileged enough.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (POOL-264) NullPointerException in GKOP.borrowObject()
[ https://issues.apache.org/jira/browse/POOL-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651820#comment-17651820 ] Niall Pemberton commented on POOL-264: -- The synchronization was removed in May 2011 when it was refactored to use java.util.concurrent based pooling: * [https://svn.apache.org/viewvc?view=revision&revision=1102500] This change was included in the Pool 2.0 release (Java 1.5 minimum) but not in any of the Pool 1.x versions (Java 1.3 minimum). > NullPointerException in GKOP.borrowObject() > --- > > Key: POOL-264 > URL: https://issues.apache.org/jira/browse/POOL-264 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6, 1.5.7, 1.6 >Reporter: Leonid Meyerguz >Priority: Major > > While I cannot pin down a consistent repro, I occasionally observe a > NullPointerException at > org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1126) > The pool is configured as follows: > maxActive = -1 > maxIdle = 32 > maxTotal = 32 > whenExhaustedAction = WHEN_EXHAUSTED_GROW > timeBetweenEvictionRunsMillis = 2 > minEvictableIdleTimeMillis = 6 > numTestsPerEvictionRun = -1 > The NullPointerException is thrown in the WHEN_EXHAUSTED_GROW branch of the > code. Specifically it appears that latch.getPool() returns null. > Any suggestions for a work-around would be appreciated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (POOL-393) BaseGenericObjectPool.jmxRegister may cost too much time
[
https://issues.apache.org/jira/browse/POOL-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651437#comment-17651437
]
Niall Pemberton commented on POOL-393:
--
I created the following PR:
* [https://github.com/apache/commons-pool/pull/199]
It adds a check to MBeanServer's _*isRegistered(ObjectName)*_ method and from
running Phil's test this improves performance 10x even though there are alot of
calls to JMX for a large number of pools.
> BaseGenericObjectPool.jmxRegister may cost too much time
>
>
> Key: POOL-393
> URL: https://issues.apache.org/jira/browse/POOL-393
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 2.4.2
>Reporter: Shichao Yuan
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
>
> When creating many pools, I find that it tasks too much time to register jmx.
> In the code, the ObjectName's postfix always starts with 1, so many
> InstanceAlreadyExistsExceptions may be thrown before registered successfully.
> Maybe a random number is a better choice, or a atomic long.
> {quote}private ObjectName jmxRegister(BaseObjectPoolConfig config,
> String jmxNameBase, String jmxNamePrefix) {
> ObjectName objectName = null;
> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
> int i = 1;
> boolean registered = false;
> String base = config.getJmxNameBase();
> if (base == null)
> Unknown macro: \{ base = jmxNameBase; }
> while (!registered) {
> try {
> ObjectName objName;
> // Skip the numeric suffix for the first pool in case there is
> // only one so the names are cleaner.
> if (i == 1)
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix); }
> else
> Unknown macro: \{ objName = new ObjectName(base + jmxNamePrefix + i); }
> mbs.registerMBean(this, objName);
> objectName = objName;
> registered = true;
> } catch (MalformedObjectNameException e) {
> if (BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX.equals(
> jmxNamePrefix) && jmxNameBase.equals(base))
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> else
> Unknown macro: \{ // Must be an invalid name. Use the defaults instead.
> jmxNamePrefix = BaseObjectPoolConfig.DEFAULT_JMX_NAME_PREFIX; base =
> jmxNameBase; }
> } catch (InstanceAlreadyExistsException e)
> Unknown macro: \{ // Increment the index and try again i++; }
> catch (MBeanRegistrationException e)
> Unknown macro: \{ // Shouldn't happen. Skip registration if it does.
> registered = true; }
> catch (NotCompliantMBeanException e)
> }
> return objectName;
> }
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VALIDATOR-394) General Modulus Ten Check Digit Implementation
[ https://issues.apache.org/jira/browse/VALIDATOR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326580#comment-15326580 ] Niall Pemberton commented on VALIDATOR-394: --- @Sebb - good point, I've cloned postitionWeight I added a couple of more tests and a *sumWeightedDigits* option and checked in this change: - http://svn.apache.org/viewvc?view=revision&revision=1748035 > General Modulus Ten Check Digit Implementation > -- > > Key: VALIDATOR-394 > URL: https://issues.apache.org/jira/browse/VALIDATOR-394 > Project: Commons Validator > Issue Type: New Feature > Components: Routines >Reporter: Niall Pemberton > Attachments: VALIDATOR-394-ModulusTenCheckDigit.patch, > VALIDATOR-394-Tests.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Discussion on the commons dev mailing list about a CheckDigit implementation > for German identity cards prompted a general Modulus 10 CheckDigit > implementation where the weighting factors could be specified. > See http://markmail.org/message/zqxsep327ios2r4t -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VALIDATOR-394) General Modulus Ten Check Digit Implementation
[ https://issues.apache.org/jira/browse/VALIDATOR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-394: -- Description: Discussion on the commons dev mailing list about a CheckDigit implementation for German identity cards prompted a general Modulus 10 CheckDigit implementation where the weighting factors could be specified. See http://markmail.org/message/zqxsep327ios2r4t was: Discussion on the commons dev mailing list about a CheckDigit implementation for German identity cards prompted a general Modulus 10 CheckDigit implementation where the weighting factors could be specified. See markmail.org/message/zqxsep327ios2r4t > General Modulus Ten Check Digit Implementation > -- > > Key: VALIDATOR-394 > URL: https://issues.apache.org/jira/browse/VALIDATOR-394 > Project: Commons Validator > Issue Type: New Feature > Components: Routines >Reporter: Niall Pemberton > Attachments: VALIDATOR-394-ModulusTenCheckDigit.patch, > VALIDATOR-394-Tests.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Discussion on the commons dev mailing list about a CheckDigit implementation > for German identity cards prompted a general Modulus 10 CheckDigit > implementation where the weighting factors could be specified. > See http://markmail.org/message/zqxsep327ios2r4t -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VALIDATOR-394) General Modulus Ten Check Digit Implementation
[ https://issues.apache.org/jira/browse/VALIDATOR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-394: -- Attachment: VALIDATOR-394-Tests.patch VALIDATOR-394-ModulusTenCheckDigit.patch Attaching VALIDATOR-394-ModulusTenCheckDigit.patch with implementation. Also attaching VALIDATOR-394-Tests.patch which is existing tests using ModulusTenCheckDigit > General Modulus Ten Check Digit Implementation > -- > > Key: VALIDATOR-394 > URL: https://issues.apache.org/jira/browse/VALIDATOR-394 > Project: Commons Validator > Issue Type: New Feature > Components: Routines >Reporter: Niall Pemberton > Attachments: VALIDATOR-394-ModulusTenCheckDigit.patch, > VALIDATOR-394-Tests.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Discussion on the commons dev mailing list about a CheckDigit implementation > for German identity cards prompted a general Modulus 10 CheckDigit > implementation where the weighting factors could be specified. > See markmail.org/message/zqxsep327ios2r4t -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VALIDATOR-394) General Modulus Ten Check Digit Implementation
Niall Pemberton created VALIDATOR-394: - Summary: General Modulus Ten Check Digit Implementation Key: VALIDATOR-394 URL: https://issues.apache.org/jira/browse/VALIDATOR-394 Project: Commons Validator Issue Type: New Feature Components: Routines Reporter: Niall Pemberton Discussion on the commons dev mailing list about a CheckDigit implementation for German identity cards prompted a general Modulus 10 CheckDigit implementation where the weighting factors could be specified. See markmail.org/message/zqxsep327ios2r4t -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IO-494) Mismatch return type in api docs of class DirectoryWalker.
[ https://issues.apache.org/jira/browse/IO-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-494. Resolution: Fixed Assignee: Niall Pemberton Thanks, I've fixed this > Mismatch return type in api docs of class DirectoryWalker. > -- > > Key: IO-494 > URL: https://issues.apache.org/jira/browse/IO-494 > Project: Commons IO > Issue Type: Bug > Components: Filters >Affects Versions: 2.4 >Reporter: Hunter Han >Assignee: Niall Pemberton >Priority: Trivial > Labels: documentation > Original Estimate: 20m > Remaining Estimate: 20m > > In the api docs of class org.apache.commons.io.DirectoryWalker, topic of > 3.1 External / Multi-threaded.Method handleIsCancelled in demo code returns > boolean but with a void return type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012207#comment-15012207
]
Niall Pemberton commented on IO-487:
Go for it - looks good to me, the only minor comment I have is, can you include
the className in the exception message:
{{throw new InvalidClassException("Class '" + className + "' not accepted");}}
> ValidatingObjectInputStream contribution - restrict which classes can be
> deserialized
> -
>
> Key: IO-487
> URL: https://issues.apache.org/jira/browse/IO-487
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 2.4
>Reporter: Bertrand Delacretaz
>Priority: Minor
> Labels: patch
> Fix For: 2.5
>
> Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch,
> IO-487-accept-reject.patch, IO-487-matchers.patch,
> IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch,
> IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-487: --- Attachment: IO-487-2.patch Attaching IO-487-2.patch which includes the following: * Change the ClassAcceptor's accept() method to return a boolean * RegexpClassAcceptor (in place of WhiteRegexpClassAcceptor & BlackRegexpClassAcceptor) * NameClassAcceptor (in place of WhitelistClassAcceptor & BlacklistClassAcceptor) * add NotClassAcceptor (to provide blacklist/exclusion functionality of above implementations) > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-2.patch, IO-487-name-regex-acceptor.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005666#comment-15005666 ] Niall Pemberton commented on IO-487: Last comment! I think the ClassAcceptor's accept() method should be changed to return a boolean, and move the exception to be thrown to the resolveClass() method of the ObjectInputStream. I think that would make ClassAcceptor more re-usable in its own right outside of this specific use-case. It would also make composing composite ClassAcceptors from other implementations easier to implement. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-name-regex-acceptor.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005663#comment-15005663 ] Niall Pemberton commented on IO-487: OK, makes sense. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-name-regex-acceptor.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005662#comment-15005662 ] Niall Pemberton commented on IO-487: No, thats not true - IntersectionClassAcceptor is something different from what I was suggesting. Thinking about it though, probably just providing a "NotClassAcceptor" implementation which reverses the effect of a delegate ClassAcceptor that its constructed with would provide this for any ClassAcceptor and then no need for the separate included/exclude (blacklist/whitelist) implementations. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-name-regex-acceptor.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005566#comment-15005566 ] Niall Pemberton commented on IO-487: Also an alternative to throwing UnsupportedOperationException would be to throw InvalidClassException (which is an ObjectStreamException) > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-name-regex-acceptor.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-487: --- Attachment: IO-487-name-regex-acceptor.patch An alternative would be for single RegexClassAcceptor & NameClassAcceptor implementations that do both include & exclude. Attaching patch containing implementations. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487-name-regex-acceptor.patch, IO-487.patch, > IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005423#comment-15005423 ] Niall Pemberton commented on IO-487: Personally I prefer SafeObjectInputStream over Validating Also would prefer Exclude/Include rather than Black/White > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-337) ByteOrderMark can be refactored as an enum
[ https://issues.apache.org/jira/browse/IO-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567831#comment-14567831 ] Niall Pemberton commented on IO-337: There are more byte order marks than the five defined as static variables in the ByteOrderMark class. This way we just define the common ones, but allow people to construct others. Switching to an enum would prevent this. It would also prevent the (ab)use of this class to detect starting bytes such as the BOMInputStream does with the XML_GUESS_BYTES boms that it constructs. http://en.wikipedia.org/wiki/Byte_order_mark > ByteOrderMark can be refactored as an enum > -- > > Key: IO-337 > URL: https://issues.apache.org/jira/browse/IO-337 > Project: Commons IO > Issue Type: New Feature >Reporter: Yaniv Kunda >Priority: Minor > Attachments: ByteOrderMark-enum.patch > > > ByteOrderMark is used primarily for encapsulating the data regarding to > Unicode BOMs. Since those are fixed, it would make sense to make it an enum, > instead of a public class. > I have attached a patch that only covers ByteOrderMark itself, including an > additional getCharset() utility method, and toString() simplification. > This patch does not cover: > 1) Its incorrect use (per its perceived purpose) in > XmlStreamReader.XML_GUESS_BYTES > 2) The now-unnecessary tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-478) Rename org.apache.commons.io.output.ByteArrayOutputStream
[ https://issues.apache.org/jira/browse/IO-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557833#comment-14557833 ] Niall Pemberton commented on IO-478: This was the case when it was added in 2003 and I don't remember anyone ever expressing any confusion over this in that time. I also think the name perfectly describes what it does which is just a different implementation of the java.io.ByteArrayOutputStream. Both implementations grow but just differ in their internal implementation of how they do that. So my opinion is to leave this as it is and close this issue as WONTFIX. > Rename org.apache.commons.io.output.ByteArrayOutputStream > - > > Key: IO-478 > URL: https://issues.apache.org/jira/browse/IO-478 > Project: Commons IO > Issue Type: Task > Components: Streams/Writers >Reporter: Benedikt Ritter > Fix For: 3.x > > > The name of org.apache.commons.io.output.ByteArrayOutputStream clashes with > java.io.ByteArrayOutputStream which can cause confusion. We should rename the > class to something that better describes its behavior and differences to > java.io.ByteArrayOutputStream, for example GrowingByteArrayOutputStream. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-992) NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13950314#comment-13950314
]
Niall Pemberton commented on LANG-992:
--
I have checked in the change in revision 1582585
> NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
> ---
>
> Key: LANG-992
> URL: https://issues.apache.org/jira/browse/LANG-992
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.3.1
> Environment: Java 8, Windows 7
>Reporter: Adam Rauch
> Fix For: Review Patch
>
> Attachments: LANG-992-v2.patch
>
>
> After upgraded from 3.1 to 3.3.1 it seems that {{isNumber(String str)}}
> returns false for decimal numbers with leading zeros. In other words:
> {code:java}
> boolean ret = NumberUtils.isNumber("0.4790");
> {code}
> On 3.1, {{ret}} was true. In 3.3.1, {{ret}} is false.
> Guessing that LANG-972 is related... comment in the code states:
> {code:java}
> // leading 0, but not hex, must be octal
> {code}
> This is clearly a case where leading 0 does not mean hex.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-992) NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-992:
-
Attachment: (was: LANG-992.patch)
> NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
> ---
>
> Key: LANG-992
> URL: https://issues.apache.org/jira/browse/LANG-992
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.3.1
> Environment: Java 8, Windows 7
>Reporter: Adam Rauch
> Attachments: LANG-992-v2.patch
>
>
> After upgraded from 3.1 to 3.3.1 it seems that isNumber(String str) returns
> false for decimal numbers with leading zeros. In other words:
>boolean ret = NumberUtils.isNumber("0.4790");
> On 3.1, ret was true. In 3.3.1, ret is false.
> Guessing that LANG-972 is related... comment in the code states:
> // leading 0, but not hex, must be octal
> This is clearly a case where leading 0 does not mean hex.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-992) NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-992:
-
Attachment: LANG-992-v2.patch
Attaching second version of patch
> NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
> ---
>
> Key: LANG-992
> URL: https://issues.apache.org/jira/browse/LANG-992
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.3.1
> Environment: Java 8, Windows 7
>Reporter: Adam Rauch
> Attachments: LANG-992-v2.patch
>
>
> After upgraded from 3.1 to 3.3.1 it seems that isNumber(String str) returns
> false for decimal numbers with leading zeros. In other words:
>boolean ret = NumberUtils.isNumber("0.4790");
> On 3.1, ret was true. In 3.3.1, ret is false.
> Guessing that LANG-972 is related... comment in the code states:
> // leading 0, but not hex, must be octal
> This is clearly a case where leading 0 does not mean hex.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-992) NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
[
https://issues.apache.org/jira/browse/LANG-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-992:
-
Attachment: LANG-992.patch
Yes, this was caused by the second commit for LANG-972 in revision 1566967
when the change for Octal numbers was made. I have a patch that resolves this
specific issue, but perhaps the Octal change should be reverted.
> NumberUtils#isNumber() returns false for "0.0", "0.4790", et al
> ---
>
> Key: LANG-992
> URL: https://issues.apache.org/jira/browse/LANG-992
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.3.1
> Environment: Java 8, Windows 7
>Reporter: Adam Rauch
> Attachments: LANG-992.patch
>
>
> After upgraded from 3.1 to 3.3.1 it seems that isNumber(String str) returns
> false for decimal numbers with leading zeros. In other words:
>boolean ret = NumberUtils.isNumber("0.4790");
> On 3.1, ret was true. In 3.3.1, ret is false.
> Guessing that LANG-972 is related... comment in the code states:
> // leading 0, but not hex, must be octal
> This is clearly a case where leading 0 does not mean hex.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-967) Code should never catch and ignore all Throwables
[
https://issues.apache.org/jira/browse/LANG-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947347#comment-13947347
]
Niall Pemberton commented on LANG-967:
--
Providing a utility class encourages it IMO and as I said before, its a
potential bomb for any new errors. If people want to shoot themselves by
writing this type of code then fine, I think commons should avoid this.
"An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch."
http://docs.oracle.com/javase/7/docs/api/java/lang/Error.html
> Code should never catch and ignore all Throwables
> -
>
> Key: LANG-967
> URL: https://issues.apache.org/jira/browse/LANG-967
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Sebb
> Fix For: Patch Needed
>
>
> Code should never catch and ignore all Throwables - ThreadDeath and
> VirtualMachineError must be rethrown.
> It would be useful to provide a method to enforce this behaviour.
> For example,. as is done by the Tomcat method \[1] with source here \[2]
> Sample usage:
> {code}
> try {
> reader.close();
> } catch (Throwable u) {
> ExceptionUtils.handleThrowable(u);
> }
> {code}
> \[1] org.apache.tomcat.util.ExceptionUtils#handleThrowable()
> \[2]
> https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/ExceptionUtils.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-967) Code should never catch and ignore all Throwables
[
https://issues.apache.org/jira/browse/LANG-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947229#comment-13947229
]
Niall Pemberton commented on LANG-967:
--
This seems like a bad idea to me - what circumstances is it good to
catch/ignore any Errors? We shouldn't encourage use of this by providing a
dangerous method IMO. Especially since its a potential bomb for any new Errors
that may be added in the future.
{code}
try {
reader.close();
} catch (Exception e) {
}
{code}
> Code should never catch and ignore all Throwables
> -
>
> Key: LANG-967
> URL: https://issues.apache.org/jira/browse/LANG-967
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Sebb
> Fix For: Patch Needed
>
>
> Code should never catch and ignore all Throwables - ThreadDeath and
> VirtualMachineError must be rethrown.
> It would be useful to provide a method to enforce this behaviour.
> For example,. as is done by the Tomcat method \[1] with source here \[2]
> Sample usage:
> {code}
> try {
> reader.close();
> } catch (Throwable u) {
> ExceptionUtils.handleThrowable(u);
> }
> {code}
> \[1] org.apache.tomcat.util.ExceptionUtils#handleThrowable()
> \[2]
> https://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/ExceptionUtils.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (VALIDATOR-325) IBAN validation not calculated correctly
[ https://issues.apache.org/jira/browse/VALIDATOR-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838960#comment-13838960 ] Niall Pemberton commented on VALIDATOR-325: --- Its a good point, and it would probably be useful to throw a number exceptions to provide more concise errors: - Code is null/blank - country not supported (i.e. formatValidator == null) - Invalid format for country - Invalid check digit However this is a general problem for all these validation routines - they only provide valid/invalid rather than specific errors and would require changing how the framework works. For me, I don't have any interest in the framework part of Validator (and the bean validation specification probabvly means that the framework is now dead) and part of the work done on Validator 1.4 was to clearly separate out the actual validation routines from the framework - which would be good if they could be released independently. Another OT thing I found out last night is that the Apache BVal project has copied all these chckdigit validation routines from here, which is nice: http://svn.apache.org/repos/asf/bval/trunk/bval-extras/src/main/java/org/apache/bval/extras/constraints/checkdigit/ > IBAN validation not calculated correctly > > > Key: VALIDATOR-325 > URL: https://issues.apache.org/jira/browse/VALIDATOR-325 > Project: Commons Validator > Issue Type: Bug >Reporter: Wim Vleugels > Fix For: 1.4.0 Release > > Attachments: IBANValidator.java > > > When I try to validate an incorrect belgian IBAN code "BE7436302152834", than > it passes the validation without any problem although even the length of the > code is invalid. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (VALIDATOR-325) IBAN validation not calculated correctly
[ https://issues.apache.org/jira/browse/VALIDATOR-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated VALIDATOR-325: -- Attachment: IBANValidator.java It is pretty straight forward to combine the regular expression validator with the IBAN checkdigit to create a validator that caters for all country formats. The biggest effort is defining all the regular expression formats for each country. I'm attaching an IBANValidator that does this. This needs a proper test case to verify all the formats (I've only tested it with your Belgian example). > IBAN validation not calculated correctly > > > Key: VALIDATOR-325 > URL: https://issues.apache.org/jira/browse/VALIDATOR-325 > Project: Commons Validator > Issue Type: Bug >Reporter: Wim Vleugels > Fix For: 1.4.0 Release > > Attachments: IBANValidator.java > > > When I try to validate an incorrect belgian IBAN code "BE7436302152834", than > it passes the validation without any problem although even the length of the > code is invalid. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (VALIDATOR-325) IBAN validation not calculated correctly
[ https://issues.apache.org/jira/browse/VALIDATOR-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13837299#comment-13837299 ] Niall Pemberton commented on VALIDATOR-325: --- Its been quite a while since I worked on validator, but I believe it only provides IBAN check digit validation out of the box - not length. Validator has the CodeValidator which can combine a CheckDigit validation with regex or length checks - so you could combine that with the IBANCheckDigit[2] to create a Belgian IBAN validator [1] http://commons.apache.org/proper/commons-validator/javadocs/api-1.4.0/org/apache/commons/validator/routines/CodeValidator.html [2] http://commons.apache.org/proper/commons-validator/javadocs/api-1.4.0/org/apache/commons/validator/routines/checkdigit/IBANCheckDigit.html P.S. Its useful if you post the Validator version you're using and examples of code. Also this would have been better asking on the mailing list first, before creating a bug report: http://commons.apache.org/proper/commons-validator/mail-lists.html > IBAN validation not calculated correctly > > > Key: VALIDATOR-325 > URL: https://issues.apache.org/jira/browse/VALIDATOR-325 > Project: Commons Validator > Issue Type: Bug >Reporter: Wim Vleugels > > When I try to validate an incorrect belgian IBAN code "BE7436302152834", than > it passes the validation without any problem although even the length of the > code is invalid. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (BEANUTILS-454) copyProperties() throws conversion exception for null Date
[ https://issues.apache.org/jira/browse/BEANUTILS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832261#comment-13832261 ] Niall Pemberton commented on BEANUTILS-454: --- So this was a mistake when adding the date/calendar converters. No particular thinking, except other converters had the same default behaviour > copyProperties() throws conversion exception for null Date > -- > > Key: BEANUTILS-454 > URL: https://issues.apache.org/jira/browse/BEANUTILS-454 > Project: Commons BeanUtils > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Markus Stahl >Priority: Critical > Fix For: 1.8.4 > > > This issue had been reported earlier and rejected too soon. > Since 1.8.0, BeanUtils.copyProperties suddenly throws an Exception, if the > property is of type Date. It did not do so in prior releases, that's why > properly running software is nowadays broken. There is a workaround if the > BeanUtils are used in my own code, but if it is used in 3rd party code, I am > screwed. > Please, treat null for Date the same as null for any other type and copy null > from source to destination. > For more reasons, see the comments of people who move now to new releases of > BeanUtils facing the same problem. The issue gets more and more attention, > but I think, nobody except the reporters are notified about it. Therefore > this issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (IO-406) Move StringBufferOutputStream class to apache commons io project.
[ https://issues.apache.org/jira/browse/IO-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-406: --- Attachment: IO-406-AppendableOutputStream.patch Commons IO already has StringBuilderWriter (but not a StringBufferWriter) and WriterOutputStream implementations that can be combined to create a StringBuilder OutputStream. The advantage of using the WriterOutputStream implementation is that a CharsetDecoder can be used for converting the characters to bytes. However, if people think this is a good idea then an AppendableOutputStream is more generic - providing for StringBuilder, StringBuffer and any Writer implementation. Attaching a patch with that > Move StringBufferOutputStream class to apache commons io project. > - > > Key: IO-406 > URL: https://issues.apache.org/jira/browse/IO-406 > Project: Commons IO > Issue Type: Task > Components: Streams/Writers >Affects Versions: 2.4 > Environment: Regardless >Reporter: cynthia avishegnath > Labels: commons, geronimo, io, refactor, util > Fix For: 2.5 > > Attachments: IO-406-AppendableOutputStream.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Move org.apache.geronimo.mail.util.StringBufferOutputStream class to apache > commons io project. > Many would like to use that class without having to pull in dependency on > Geronimo, but also wish to comply to DIE-DRY by not replicating that class in > our respective personal libraries. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-344) CollatorUtils - equivalent of StringUtils, but using Collators
[ https://issues.apache.org/jira/browse/LANG-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-344: - Attachment: CollatorUtilsTest.java CollatorUtils.java > CollatorUtils - equivalent of StringUtils, but using Collators > -- > > Key: LANG-344 > URL: https://issues.apache.org/jira/browse/LANG-344 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.3 >Reporter: Niall Pemberton >Priority: Minor > Fix For: Patch Needed > > Attachments: CollatorUtils.java, CollatorUtilsTest.java > > > Stephen Kestle has pointed out that "equalsIgnoreCase is an English/ASCII > hack" and that using the Collator class provides a more robust String > comparison mechanism. > - Most recently this came up when adding new "ignore case" methods to > StringUtils for LANG-326 (also http://tinyurl.com/3d2jjk ) > - Raised in regarding case insensitivity for EqualsBuilder and > HashCodeBuilder in LANG-316 > Creating this issue ticket so this doesn't get forgotten -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (COMMONSSITE-30) Add Module profiles to parent poms
[ https://issues.apache.org/jira/browse/COMMONSSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved COMMONSSITE-30. Resolution: Fixed Profiles to build proper & sandbox were added > Add Module profiles to parent poms > -- > > Key: COMMONSSITE-30 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-30 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-30-module-profiles-v4.patch > > > Seeing the felix project's pom with different modules in profiles made me > think this might be useful for commons - with "trunks-proper" or > "trunks-sandbox". > I tried it out, but running mvn -Ptrunks-proper site failed bizarely: > * on commons-io it objected to JDK 1.5 features saying the source option was > 1.3 - so it seemed to be using the commons-parent default, rather than the > individual property setting for projects > * on lang though it objected to enum - so seemed to ignore those settings. > Perhaps someone else knows how to get it working properly - at the least its > useful for cleaning up all the modules. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (COMMONSSITE-22) Maven2 Plugin to generate custom component pages
[ https://issues.apache.org/jira/browse/COMMONSSITE-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved COMMONSSITE-22. Resolution: Fixed This is the commons-build-plugin - closing > Maven2 Plugin to generate custom component pages > > > Key: COMMONSSITE-22 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-22 > Project: Commons All > Issue Type: Improvement > Components: Commons Build >Reporter: Niall Pemberton >Assignee: Niall Pemberton > > I've been playing with a Maven2 Ant plugin which is a possible solution for > generating the component's download pages - currently handled by m1. As an > addition it also does custom "Issue Tracking" pages, of the style most m1 > sites use (and better than the current m2 generated one). > The advantage of this plugin is that it creates the page in the component's > site - which is better IMO than having a page in "commons general" outside > the component's site. I'm going to add this to the sandbox shortly -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (COMMONSSITE-57) Fix broken link on http://commons.apache.org/mail-lists.html
[ https://issues.apache.org/jira/browse/COMMONSSITE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved COMMONSSITE-57. Resolution: Fixed This was complted with release 1.4 of build plugin - closing > Fix broken link on http://commons.apache.org/mail-lists.html > > > Key: COMMONSSITE-57 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-57 > Project: Commons All > Issue Type: Bug > Components: Site >Reporter: Konstantin Kolinko >Assignee: Niall Pemberton >Priority: Trivial > Attachments: mail-lists.xml.patch > > > Link to the Apache archive of announce@apache mailing list is broken. The > link points to > http://mail-archives.apache.org/mod_mbox/announce/ > which gives 404. The correct address is > http://mail-archives.apache.org/mod_mbox/www-announce/ -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (COMMONSSITE-38) Upgrade to maven-javadoc-plugin 2.5 / *-javadoc.jar Manifest entries
[ https://issues.apache.org/jira/browse/COMMONSSITE-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved COMMONSSITE-38. Resolution: Fixed This has been done - closing > Upgrade to maven-javadoc-plugin 2.5 / *-javadoc.jar Manifest entries > > > Key: COMMONSSITE-38 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-38 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton >Priority: Minor > Attachments: COMMONSSITE-38-javadoc-jar-manifest.patch > > > The recent release of version 2.5 of the maven-javadoc-plugin now provides > for the ability to configure manifest entries in the same way as the > maven-jar-plugin does. > We can add this to commons-parent - the only thing I noticed is that it > requires maven 2.0.9 as the minimum. Tried it out and it looks OK. The other > thing is do we want to differentiate from the jar manifets (perhaps add > JavaDoc to titles). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (COMMONSSITE-21) commons-parent-6 pom changes
[ https://issues.apache.org/jira/browse/COMMONSSITE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved COMMONSSITE-21. Resolution: Fixed closing > commons-parent-6 pom changes > > > Key: COMMONSSITE-21 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-21 > Project: Commons All > Issue Type: Improvement > Components: Commons Parent Pom >Reporter: Niall Pemberton > Attachments: COMMONSSITE-21-commons-parent-pom-v1.patch, > COMMONSSITE-21-commons-parent-pom-v2.patch, > commons-valdiator-generated-NOTICE.txt > > > Opening this ticket to discuss changes for Version 6 of the commons-parent > pom. > See thread: http://tinyurl.com/39eo9z for related discussion/issues -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated BEANUTILS-409:
--
Attachment: BEANUTILS-409-register.patch
I was thinking more along the lines of a new register method - attaching
BEANUTILS-409-register.patch
With this you could change the behaviour of all the default arrat converters
with 2 lines:
{code}
BeanUtilsBean.setInstance(new BeanUtilsBean2());
BeanUtilsBean.getInstance().getConvertUtils().register(false, true, 0, false);
{code}
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Assignee: Benedikt Ritter
>Priority: Critical
> Labels: describe
> Fix For: 1.8.4
>
> Attachments: BEANUTILS-409-FIX.patch, BEANUTILS-409-register.patch,
> BEANUTILS-409-Test.patch
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
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] (BEANUTILS-409) BeanUtils - 'describe' method returning Incorrect array value
[
https://issues.apache.org/jira/browse/BEANUTILS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590068#comment-13590068
]
Niall Pemberton commented on BEANUTILS-409:
---
The reason behind this type of behavior is because of the origin of BeanUtils
in the Struts 1 project - the populate() method was developed to convert a Map
of request parameters into a bean. Request parameters can have multiple values
- but Struts only used the first (multiple values were handled through a
parameter name convention):
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#getParameterValues(java.lang.String)
The describe() method suffers from this behaviour because it utilizes the same
methods (ultimately the BeanUtilsBean.convert(Object) method.
Work to improve the capabilities of the Converters and enhance BeanUtils to use
these new facilities came later (relatively!) in the 1.8.x series - but we
tried to retain backward compatibility for Struts 1 users.
There is a mechanism to change this behaviour in place in BeanUtils 1.8.3 -
sorry its not very elegant.
First you have to register BeanUtilsBean2 as the BeanUtils bean:
{code}
BeanUtilsBean.setInstance(new BeanUtilsBean2());
{code}
This causes the ConvertUtilsBean2 to be used and all the conversion is
delegated to the registered converters. However the default behavior for the
registered array converters when converting to a String is the old behavior of
just taking the first value. This can be changed using the
setOnlyFirstToString(false) - but you have to do that for each array converter.
For example, for String arrays you would do:
{code}
ArrayConverter stringArrayConverter = new ArrayConverter(String[].class, new
StringConverter(), 0);
stringArrayConverter.setOnlyFirstToString(false);
ConvertUtils.register(stringArrayConverter, String[].class);
{code}
This is cumbersome to do for every array converter so it would probably be a
good idea to expose a method which can do this for all the default array
converters that are registered.
> BeanUtils - 'describe' method returning Incorrect array value
> -
>
> Key: BEANUTILS-409
> URL: https://issues.apache.org/jira/browse/BEANUTILS-409
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: commons-beanutils 1.8.3, jdk 1.6.0_20
>Reporter: benny
>Assignee: Benedikt Ritter
>Priority: Critical
> Labels: describe
> Fix For: 1.8.4
>
> Attachments: BEANUTILS-409-Test.patch
>
>
> I want to convert a bean class to a map (key=the name of the member,value=the
> value of the member).
> I'm using the method BeanUtils.describe(beanClass);
> (I'm using commons-beanutils 1.8.3, jdk 1.6.0_20, on commons-beanutils 1.5 it
> works)
> The problem is that the return value is incorrect, (the map contain only the
> first item from the array),
> the code:
> public class Demo {
> private ArrayList myList = new ArrayList();
> public Demo() {
> myList.add("first_value");
> myList.add("second_value");
> }
>
> public ArrayList getMyList() {
> return myList;
> }
>
> public void setMyList(ArrayList myList) {
> this.myList = myList;
> }
>
> public static void main(String[] args) {
> Demo myBean = new Demo();
> try {
> Map describe = BeanUtils.describe(myBean);
> Iterator it = describe.entrySet().iterator();
> while (it.hasNext()) {
> Map.Entry pairs = (Map.Entry) it.next();
> System.out.println(String.format("key=%s,value=%s",
> (String) pairs.getKey(), (String) pairs.getValue()));
>
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> •The expected output:
>
> key=myList,value=[first_value,second_value]
> key=class,value=class $Demo
> •But the real output is:
>
> key=myList,value=[first_value]
> key=class,value=class $Demo
> As you can see the array contains two values but the output(and the map)
> contains only one,why??
--
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] (MATH-876) In v3, Bundle-SymbolicName should be org.apache.commons.math3 (not org.apache.commons.math as currently)
[
https://issues.apache.org/jira/browse/MATH-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated MATH-876:
-
Attachment: MATH876-bundle-name.patch
It would be better to override the commons.osgi.symbolicName property rather
than changing the componentid to do this - attaching a patch
> In v3, Bundle-SymbolicName should be org.apache.commons.math3 (not
> org.apache.commons.math as currently)
>
>
> Key: MATH-876
> URL: https://issues.apache.org/jira/browse/MATH-876
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Matthew Webber
> Labels: build
> Fix For: 3.1
>
> Attachments: MATH876-bundle-name.patch
>
>
> In Commons Math 3.0, all package names start with
> {{org.apache.commons.math3}}, to distinguish them from packages in the
> previous (2.2) - issue MATH-444.
> However, the name of the bundle itself was not similarly changed - in the
> MANIFEST.MF from 3.0.0, we have this line:
> {{Bundle-SymbolicName: org.apache.commons.math}}
> This should be changed in 3.1 to:
> {{Bundle-SymbolicName: org.apache.commons.math3}}
> As an example, Apache Commons Lang changed their bundle name when they moved
> from v2 to v3 - exactly what I am proposing for Commons Math.
> For various reasons, the existing plugin naming is a problem for us in our
> environment, where our code uses a mixture of 2.2 and 3.0 classes (there are
> too many references to quickly change).
--
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] (DBUTILS-106) DBUtils can't build using JDK 1.7 - DriverProxy needs to implement getParentLogger()
[ https://issues.apache.org/jira/browse/DBUTILS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated DBUTILS-106: Attachment: DBUTILS106-dynamic-invoke.patch Alternative patch which invokes method dynamically > DBUtils can't build using JDK 1.7 - DriverProxy needs to implement > getParentLogger() > > > Key: DBUTILS-106 > URL: https://issues.apache.org/jira/browse/DBUTILS-106 > Project: Commons DbUtils > Issue Type: Improvement >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Attachments: DBUTILS106-dynamic-invoke.patch > > > DBUtils can't build using JDK 1.7 - DriverProxy needs to implement > getParentLogger(). > This is causing daily gump failures: > http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html -- 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] (DBUTILS-106) DBUtils can't build using JDK 1.7 - DriverProxy needs to implement getParentLogger()
[ https://issues.apache.org/jira/browse/DBUTILS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545422#comment-13545422 ] Niall Pemberton commented on DBUTILS-106: - I have added the method in r1429538 - currently just throws SQLFeatureNotSupportedException, any alternative would be to try and execute the method dynamically. * see http://docs.oracle.com/javase/7/docs/api/java/sql/Driver.html#getParentLogger() > DBUtils can't build using JDK 1.7 - DriverProxy needs to implement > getParentLogger() > > > Key: DBUTILS-106 > URL: https://issues.apache.org/jira/browse/DBUTILS-106 > Project: Commons DbUtils > Issue Type: Improvement >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > > DBUtils can't build using JDK 1.7 - DriverProxy needs to implement > getParentLogger(). > This is causing daily gump failures: > http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html -- 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] (DBUTILS-106) DBUtils can't build using JDK 1.7 - DriverProxy needs to implement getParentLogger()
Niall Pemberton created DBUTILS-106: --- Summary: DBUtils can't build using JDK 1.7 - DriverProxy needs to implement getParentLogger() Key: DBUTILS-106 URL: https://issues.apache.org/jira/browse/DBUTILS-106 Project: Commons DbUtils Issue Type: Improvement Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor DBUtils can't build using JDK 1.7 - DriverProxy needs to implement getParentLogger(). This is causing daily gump failures: http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html -- 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-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291498#comment-13291498
]
Niall Pemberton commented on IO-279:
Ooo, my bad - this is already fixed. Still same as my patch except using
file.lastModified() rather than System.currentTimeMillis()
> Tailer erroneously considers file as new
>
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Sergio Bossa
> Fix For: 2.4
>
> Attachments: IO-279.patch
>
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
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] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated IO-279:
---
Attachment: IO-279.patch
Firstly I don't know why System.currentTimeMillis() is used. What matters is if
the files lastModified time compared to its previous lastModified value.
I agree with Chris that the lastModified time should be stored after the file
is read.
> Tailer erroneously considers file as new
>
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Sergio Bossa
> Fix For: 2.4
>
> Attachments: IO-279.patch
>
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
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] (IO-269) Tailer locks file from deletion/rename on Windows
[ https://issues.apache.org/jira/browse/IO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291490#comment-13291490 ] Niall Pemberton commented on IO-269: Do you have any benchmark to back up the less efficient statement? Marcos indicated that it was not the case in his benchmark. Continuing to tail a file thats been renamed would be a bug (log files is a good example of that). The current implementation can miss rotations - thats a factor of the delay and how fast/frequently the file is being written to. So the question really is, is it more likely to miss rotations and I believe that goes back to the efficiency question. > Tailer locks file from deletion/rename on Windows > - > > Key: IO-269 > URL: https://issues.apache.org/jira/browse/IO-269 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb > Attachments: IO-269-v2.patch, IO-269.patch > > > The Tailer code works on Windows, except that it locks the file against > deletion or rename. > The test code fails to detect this, because it fails to check if the file > deletion succeeds. > This seems to be a Windows OS issue. > A possible solution might be to keep closing and re-opening the file. -- 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] (IO-269) Tailer locks file from deletion/rename on Windows
[ https://issues.apache.org/jira/browse/IO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291452#comment-13291452 ] Niall Pemberton commented on IO-269: With NIO2 in JDK 7 I wouldn't hold out much hope for future file improvements. Also optional platform specific features really go against the ethos of Java's write once, run anywhere. Any reason why reopening is a bad idea on other non-Windoze platforms? > Tailer locks file from deletion/rename on Windows > - > > Key: IO-269 > URL: https://issues.apache.org/jira/browse/IO-269 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb > Attachments: IO-269-v2.patch, IO-269.patch > > > The Tailer code works on Windows, except that it locks the file against > deletion or rename. > The test code fails to detect this, because it fails to check if the file > deletion succeeds. > This seems to be a Windows OS issue. > A possible solution might be to keep closing and re-opening the file. -- 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] (IO-269) Tailer locks file from deletion/rename on Windows
[ https://issues.apache.org/jira/browse/IO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-269: --- Attachment: IO-269-v2.patch The original patch is now out-of-date. Attaching IO-269-v2.patch which is up-to-date with the current code base > Tailer locks file from deletion/rename on Windows > - > > Key: IO-269 > URL: https://issues.apache.org/jira/browse/IO-269 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb > Attachments: IO-269-v2.patch, IO-269.patch > > > The Tailer code works on Windows, except that it locks the file against > deletion or rename. > The test code fails to detect this, because it fails to check if the file > deletion succeeds. > This seems to be a Windows OS issue. > A possible solution might be to keep closing and re-opening the file. -- 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] (CHAIN-55) split the huge project in submodules
[ https://issues.apache.org/jira/browse/CHAIN-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097642#comment-13097642 ] Niall Pemberton commented on CHAIN-55: -- I agree with splitting the modules, mainly because I think the "web" elements are off-putting for users who want a simple CoR pattern. But I would keep the "web" components (i.e. Servlet, Portlet, Faces) together as a single module. This would allow WebContext & the Get/SetLocaleCommands to be part of the "web" module, rather than having to put it in the "core APIs" (since Servlet, Portlet & Faces implement them). Marking portlet & faces dependencies as "optional" in the pom.xml would prevent unnecessary dependencies being included. > split the huge project in submodules > > > Key: CHAIN-55 > URL: https://issues.apache.org/jira/browse/CHAIN-55 > Project: Commons Chain > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: 2.0 > > > As discussed in the [dev ML|http://markmail.org/message/pnyin5xzmxt2up5q], > there is a general agreement between people interested on chain, on splitting > the huge component in small submodules, in order to have a lightweight, > dependencies-less (unless the logging library, if required) and > self-contained core module, and users interested on core APIs only don't need > to bring unused code in their applications. SUggested modules are: > * core APIs; > * XML configuration APIs (depends from Digester); > * servlet (depends from Servlet APIs); > * portlet (depends from Portlet APIs); > * faces (depends from Faces APIs). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-277) ReaderInputStream enters infinite loop when it encounters an unmappable character
[
https://issues.apache.org/jira/browse/IO-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-277.
Resolution: Fixed
Fix Version/s: 2.1
Assignee: Niall Pemberton
I have implemented your suggestion to replace unmappable characters so that
behaviour is consistent with WriterOutputStream. Also I have added constructors
to ReaderInputStream/WriterOutputStream that take CharsetEncoder/CharsetDecoder
respectively so that if this is not the desired behaviour, then people can
define their own. Thanks for reporting this and the test case.
> ReaderInputStream enters infinite loop when it encounters an unmappable
> character
> -
>
> Key: IO-277
> URL: https://issues.apache.org/jira/browse/IO-277
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.0.1
>Reporter: Mike Thomas
>Assignee: Niall Pemberton
> Fix For: 2.1
>
> Attachments: TestReaderInputStreamLoop.java
>
>
> The ReaderInputStream.read(byte[] b, int off, int len) method enters an
> infinite loop when its CharsetEncoder encounters an unmappable character in
> the input buffer.
> When its CharsetEncoder encounters an unmappable character, the value of
> CoderResult lastCoderResult.isUnmappable() == true, and Reader.read() is not
> invoked on the underlying Reader ever again.
> Attaching source file that reproduces this behavior.
> One fix to consider is to call
> CharsetEncoder.onUnmappableCharacter(CodingErrorAction) in the
> ReaderInputStream constructor with a value other than the default
> CodingErrorAction.REPORT. e.g.:
> public ReaderInputStream(Reader reader, Charset charset, int bufferSize) {
> this.reader = reader;
> encoder = charset.newEncoder();
> encoder.onUnmappableCharacter(CodingErrorAction.REPLACE);
> ...
> By replacing the unmappable character with encoder's default replacement
> character, this effectively prevents the infinite loop from occurring. I'm
> not sure if that's the ideal behavior, but it seems fairly consistent with
> what org.apache.commons.io.output.WriterOutputStream does.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-283) When using the 2.0 Commons IO, there is no sort method for LastModifiedFileComparator
[ https://issues.apache.org/jira/browse/IO-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-283. Resolution: Invalid I have checked Commons IO 2.0 and the sort() method is available. Note that prior to Commons 2.0 LastModifiedFileComparator did not extend AbstractFileComparator and no sort method was available. My guess is that you probably have an older version of Commons Io in your classpath > When using the 2.0 Commons IO, there is no sort method for > LastModifiedFileComparator > - > > Key: IO-283 > URL: https://issues.apache.org/jira/browse/IO-283 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.0 > Environment: Sparc Solaris 2.10 >Reporter: Ulises Flynn >Priority: Minor > > Although the javadocs and source code from version 2.0 of Apache Commons > makes mentions of a sort method, the actual jar does not have the sort method > that is available. It seems that the LastModifiedFileComparator in the jar is > not extending AbstractFileComparator like it is in the source code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-272) LineIterator could easily support Iterable
[ https://issues.apache.org/jira/browse/IO-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-272. Resolution: Duplicate > LineIterator could easily support Iterable > -- > > Key: IO-272 > URL: https://issues.apache.org/jira/browse/IO-272 > Project: Commons IO > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > It could be useful to make LineIterator support Iterable, which is > very easy to add. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-269) Tailer locks file from deletion/rename on Windows
[ https://issues.apache.org/jira/browse/IO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018287#comment-13018287 ] Niall Pemberton commented on IO-269: This was reported by Hemal Pandya in the following thread: http://markmail.org/message/3qydndh4doszjmdz > Tailer locks file from deletion/rename on Windows > - > > Key: IO-269 > URL: https://issues.apache.org/jira/browse/IO-269 > Project: Commons IO > Issue Type: Bug >Reporter: Sebb > > The Tailer code works on Windows, except that it locks the file against > deletion or rename. > The test code fails to detect this, because it fails to check if the file > deletion succeeds. > This seems to be a Windows OS issue. > A possible solution might be to keep closing and re-opening the file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-266) FileUtils.copyFile() throws IOException when copying large files to a shared directory (on Windows)
[
https://issues.apache.org/jira/browse/IO-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018285#comment-13018285
]
Niall Pemberton commented on IO-266:
I think we should just reduce the size to fix the problem Igor found - so 30M
is the nearest (rounded)
> FileUtils.copyFile() throws IOException when copying large files to a shared
> directory (on Windows)
> ---
>
> Key: IO-266
> URL: https://issues.apache.org/jira/browse/IO-266
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Windows 2003 Server 64-bit
>Reporter: Igor Smereka
>
> java.io.IOException: Insufficient system resources exist to complete the
> requested service
> at sun.nio.ch.FileDispatcher.pwrite0(Native Method)
> at sun.nio.ch.FileDispatcher.pwrite(Unknown Source)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(Unknown Source)
> at sun.nio.ch.IOUtil.write(Unknown Source)
> at sun.nio.ch.FileChannelImpl.write(Unknown Source)
> at sun.nio.ch.FileChannelImpl.transferFromFileChannel(Unknown Source)
> at sun.nio.ch.FileChannelImpl.transferFrom(Unknown Source)
> at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:813)
> at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:783)
> at org.test.igor.TestFileUtils.main(TestFileUtils.java:55)
> NOTE: the issue is cased by the function doCopyFile(File srcFile, File
> destFile, boolean preserveFileDate) using hardcoded data chunks of FIFTY_MB
> in the transferFrom() call.
> Reducing this chunk from 50M to 31M solves the issue for my situation (32M
> still fails).
> Here is a test program to reproduce the issue:
> package org.test.igor;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.nio.channels.FileChannel;
> import org.apache.commons.io.FileUtils;
> import org.apache.commons.io.IOUtils;
> public class TestFileUtils {
> public static void main(String[] args){
>
>
> File src = new File("D:\\2011.1-dev\\test\\test");
> File dest = new File("ismerek1\\Shared");
>
> String filename = "jdk-6u19-windows-x64.exe";
>
> File file = new File(src, filename);
> File toFile = new File(dest, filename);
>
> try {
> FileUtils.copyFile(file, toFile, true);
> System.out.println("Successful copy");
> }
> catch (IOException e1) {
> e1.printStackTrace();
> }
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-250) Add FileUtils.pathTo(File aFile, File fromAnotherFile)
[
https://issues.apache.org/jira/browse/IO-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018284#comment-13018284
]
Niall Pemberton commented on IO-250:
I'd prefer to avoid the name PathUtils - NIO2 introduces a new "Path" object to
replace "File", so that could cause confusion.
> Add FileUtils.pathTo(File aFile, File fromAnotherFile)
> --
>
> Key: IO-250
> URL: https://issues.apache.org/jira/browse/IO-250
> Project: Commons IO
> Issue Type: New Feature
> Environment: n/a
>Reporter: Jasper Blues
>Priority: Minor
> Fix For: 3.x
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Please consider adding the following method to
> org.apache.commons.io.FileUtils. I've submitted the method, with test cases
> below (rather than create a patch file). As a single method, it should prove
> very simple to integrate.
> The method returns the path to a file, from another file, as described in the
> Javadoc method header below:
> {code}
> /**
> * Returns the path of a aFile relative to another aFile, for example the
> location of a file:
> * resources/language/english/foobar.properties relative to
> * resources/language/japanese/foobar.properties is
> * ../../english/foobar.properties
> *
> * @param aFile the aFile to check relative location
> * @param fromAnotherFile the base location
> * @return the relative location path
> * @throws java.io.IOException on IO error
> */
> public static String pathTo(File aFile, File fromAnotherFile) throws
> IOException {
> LOGGER.debug("Find path to file: " + aFile.toString() + " from file:
> " + fromAnotherFile.toString());
> Stack fileToDirectories = directoriesFor(aFile);
> Stack fileFromDirectories = directoriesFor(fromAnotherFile);
> while (fileToDirectories.peek().equals(fileFromDirectories.peek())) {
> fileToDirectories.pop();
> fileFromDirectories.pop();
> if (fileToDirectories.isEmpty() || fileFromDirectories.isEmpty())
> {
> break;
> }
> }
> StringBuilder pathToCommonParentDirectory = new StringBuilder();
> while (!fileFromDirectories.isEmpty()) {
> pathToCommonParentDirectory.append("../");
> fileFromDirectories.pop();
> }
> StringBuilder pathToFileFromCommonParentDirectory = new
> StringBuilder();
> while (!fileToDirectories.isEmpty()) {
>
> pathToFileFromCommonParentDirectory.append(fileToDirectories.pop().getName());
> if (!fileToDirectories.isEmpty()) {
> pathToFileFromCommonParentDirectory.append("/");
> }
> }
> return pathToCommonParentDirectory.toString() +
> pathToFileFromCommonParentDirectory.toString();
> }
> private static Stack directoriesFor(File file) throws IOException {
> Stack pathElements = new Stack();
> for (File element = file.getCanonicalFile(); element != null; element
> = element.getParentFile()) {
> pathElements.push(element);
> }
> return pathElements;
> }
> {code}
> . . . this is useful for batch processing, web applications, etc.
> Test Cases:
> {code}
> @Test
> public void pathTo() throws IOException {
> //Setup
> File file1 = new File("configs/js/en/a.xml");
> File file2 = new File("configs/js/ja/a.xml");
> Assert.assertNotNull(file1);
> Assert.assertNotNull(file2);
> //Test
> Assert.assertEquals("../../en/a.xml", FileUtils.pathTo(file1, file2));
> }
> @Test
> public void pathTo_windowsStyleOnUnixMachine() throws IOException {
> File file1 = new File("c:/fred/foobar/dude.properties");
> File file2 = new File("c:/data/zz.txt");
> Assert.assertEquals("../../fred/foobar/dude.properties",
> FileUtils.pathTo(file1, file2));
> Assert.assertEquals("../../../data/zz.txt", FileUtils.pathTo(file2,
> file1));
> }
> @Test
> public void pathTo_fromParentDirectory() throws IOException {
> File file1 = new
> File("ui-performance-enhancer/out/test/ui-performance-enhancer/configs/css/imported.xml");
> File file2 = new
> File("ui-performance-enhancer/out/test/ui-performance-enhancer/configs/css");
> Assert.assertEquals("imported.xml", FileUtils.pathTo(file1, file2));
> }
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-267) Implement Iterable versions of methods that currently provide an Iterator
[ https://issues.apache.org/jira/browse/IO-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-267. Resolution: Won't Fix You can use FileUtils.listFiles() - http://tinyurl.com/3bs9uya > Implement Iterable versions of methods that currently provide an Iterator > - > > Key: IO-267 > URL: https://issues.apache.org/jira/browse/IO-267 > Project: Commons IO > Issue Type: New Feature >Reporter: Sebb > > It would be useful to be able to use methods such as FileUtils.iterateFiles() > in a foreach loop. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-384) ConvertUtilsBean unable to process javassist classes
[
https://issues.apache.org/jira/browse/BEANUTILS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009616#comment-13009616
]
Niall Pemberton commented on BEANUTILS-384:
---
Switching from a straight Map.get() to looping over all entries to find a
converter may have a negative impact where BeanUtils is heavily used.
You can override the ConvertUtilsBean's lookup(Class, Class) method to
implement this behaviour yourself and then register your custom
ConvertUtilsBean using:
{code}
BeanUtilsBean.setInstance(new BeanUtilsBean(new CustomConvertUtilsBean()));
{code}
> ConvertUtilsBean unable to process javassist classes
>
>
> Key: BEANUTILS-384
> URL: https://issues.apache.org/jira/browse/BEANUTILS-384
> Project: Commons BeanUtils
> Issue Type: Improvement
> Components: ConvertUtils & Converters
>Affects Versions: 1.8.3
>Reporter: smallufo
> Attachments: ConvertUtilsBean.java
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The ConvertUtils uses ConvertUtils.register(userConverter , User.class) to
> register a converter.
> And use converters.get(clazz) in Converter.lookup() to find proper converter.
> It won't work for javassist modified object .
> for example , the User.class runtime becomes User_$$_javassist_0.class , and
> Converter is unable to find the corresponding converter.
> So , I suggest the future version can loop the converters map , and use
> User.class.isAssignableFrom(clazz_in_map) to find corresponding converter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006289#comment-13006289
]
Niall Pemberton edited comment on IO-174 at 3/13/11 11:23 PM:
--
Yes you're right and its a shame I didn't think of it at the time.
However, any break in binary compatibility will force a package rename for IO
here in commons. So until that happens, this change can't.
was (Author: niallp):
Yes you're right and its a shame I didn't think of it at the time.
However, any break in binary compatibility will force a package for IO here in
commons. So until that happens, this change can't.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006289#comment-13006289
]
Niall Pemberton commented on IO-174:
Yes you're right and its a shame I didn't think of it at the time.
However, any break in binary compatibility will force a package for IO here in
commons. So until that happens, this change can't.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006277#comment-13006277
]
Niall Pemberton commented on IO-174:
The main point was that it was designed that way - to be reusable. Personally I
think thats OK.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-261) getFile with varargs parameter
[
https://issues.apache.org/jira/browse/IO-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-261.
Resolution: Fixed
Fix Version/s: 2.1
Assignee: Niall Pemberton
Fixed thanks
http://svn.apache.org/viewvc?view=revision&revision=1081025
> getFile with varargs parameter
> --
>
> Key: IO-261
> URL: https://issues.apache.org/jira/browse/IO-261
> Project: Commons IO
> Issue Type: Improvement
>Reporter: Gabriele Kahlout
>Assignee: Niall Pemberton
>Priority: Minor
> Labels: features
> Fix For: 2.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Why not have those in FileUtils?
> public static File getFile(final String... dirs) {
> File ret = null;
> for (String dir : dirs) {
> if (ret == null) {
> ret = new File(dir);
> } else {
> ret = new File(ret.getPath(), dir);
> }
> }
> return ret;
> }
> public static File getFile(final File dir, final String... dirs) {
> File ret = dir;
> for (String dir1 : dirs) {
> if (ret == null) {
> ret = new File(dir1);
> } else {
> ret = new File(ret.getPath(), dir1);
> }
> }
> return ret;
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved IO-174.
Resolution: Won't Fix
Fix Version/s: (was: 3.x)
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-182) add new APPEND parameter for writing string into files
[ https://issues.apache.org/jira/browse/IO-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-182. Resolution: Fixed Fix Version/s: (was: 3.x) 2.1 Assignee: Niall Pemberton Fixed, thanks for the patch http://svn.apache.org/viewvc?view=revision&revision=1081011 > add new APPEND parameter for writing string into files > -- > > Key: IO-182 > URL: https://issues.apache.org/jira/browse/IO-182 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 1.4 >Reporter: Stefan Simik >Assignee: Niall Pemberton > Fix For: 2.1 > > Attachments: patch-add-append-to-write-fonctions.patch > > > It would be great to have one additional parameter for writing strins into > file - boolean append. > If true, string will be appended to the end of the file. > It is very useful for many purposes, for example logging and so on.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-259) FileAlterationMonitor.stop(boolean allowIntervalToFinish)
[ https://issues.apache.org/jira/browse/IO-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-259. Resolution: Fixed Fix Version/s: 2.1 Assignee: Niall Pemberton Good suggestions - I added a stop(long) method and if you specify a negative value it stops immediately. http://svn.apache.org/viewvc?view=revision&revision=1080843 > FileAlterationMonitor.stop(boolean allowIntervalToFinish) > - > > Key: IO-259 > URL: https://issues.apache.org/jira/browse/IO-259 > Project: Commons IO > Issue Type: Improvement >Reporter: Dan Checkoway >Assignee: Niall Pemberton > Fix For: 2.1 > > Attachments: IO-259.patch > > > I'm a long-time user of commons-io, but I just started using > FileAlterationMonitor the other day. I have a bean in a Spring application > context that constructs a FileAlterationMonitor, and it sets the > ThreadFactory to an instance that creates daemon threads. At context > shutdown, my bean calls .stop() on the monitor. > The problem is that .stop() currently honors the Thread.sleep(interval), in > that it does a nice friendly thread.join(). If you set your interval high > enough, your "graceful app shutdown" is going to sit there waiting a while. > Compounding things is that I have *seven* FileAlterationMonitors in my app, > all of which run with a 10-second sleep time. So at graceful shutdown time, > I'm facing a delay of up to 70 seconds...lame! > So I stopped calling .stop() and since the ThreadFactory created daemon > threads, shutdown is quick. But... > I'm running inside tomcat, and when it shuts down it looks for leaks. And of > course it finds a handful of my threads and complains, such as: > SEVERE: The web application [/my-webapp] appears to have started a thread > named [FileUpdateMonitor-/path/to/my/file.ext] but has failed to stop it. > This is very likely to create a memory leak. > So what I'm suggesting is an alternate version of > FileAlterationMonitor.stop() that takes "boolean allowIntervalToFinish". The > default behavior won't change (for backward compatibility). But if you > explicitly call .stop(false), then it will interrupt the sleeping thread > immediately. That thread wakes up, sees that running=false, and finishes up > immediately. > Patch will be attached in a sec... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-260) ClassLoaderObjectInputStream does not handle Proxy classes
[ https://issues.apache.org/jira/browse/IO-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-260. Resolution: Fixed Fix Version/s: 2.1 Assignee: Niall Pemberton Fixed, thanks http://svn.apache.org/viewvc?view=revision&revision=1080833 > ClassLoaderObjectInputStream does not handle Proxy classes > -- > > Key: IO-260 > URL: https://issues.apache.org/jira/browse/IO-260 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.0.1 >Reporter: John Carrino >Assignee: Niall Pemberton > Fix For: 2.1 > > > ObjectInputSteam has 2 methods that need to be overloaded for proper behavior > in this case. > resolveClass is ok, but resolveProxyClass doesn't attempt to look in the > passed class loader to resolve the interfaces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-265) vararg constructor in AndFileFilter and OrFileFilter is required
[ https://issues.apache.org/jira/browse/IO-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-265. Resolution: Won't Fix > vararg constructor in AndFileFilter and OrFileFilter is required > > > Key: IO-265 > URL: https://issues.apache.org/jira/browse/IO-265 > Project: Commons IO > Issue Type: Improvement > Components: Filters >Affects Versions: 2.0.1 >Reporter: Yegor Bugayenko >Priority: Minor > > Would be nice to have a vararg constructor in AndFileFilter and OrFileFilter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-264) FileUtils.moveFile() JavaDoc should specify FileExistsException thrown
[ https://issues.apache.org/jira/browse/IO-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-264. Resolution: Fixed Fix Version/s: 2.1 Assignee: Niall Pemberton Thanks, I updated the javadocs for the following methods: * moveFile() * moveFileToDirectory() * moveDirectory() * moveToDirectory() * moveDirectoryToDirectory() http://svn.apache.org/viewvc?view=revision&revision=1080825 > FileUtils.moveFile() JavaDoc should specify FileExistsException thrown > -- > > Key: IO-264 > URL: https://issues.apache.org/jira/browse/IO-264 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.0 >Reporter: Maciej Biłas >Assignee: Niall Pemberton >Priority: Trivial > Fix For: 2.1 > > > FileUtils.moveFile() JavaDoc does specify the behaviour of the method in a > case when the destFile exists. It would be helpful to know from the JavaDoc > that in such case an exception is thrown as it's not immediately obvious. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (IO-262) FileAlterationObserver has no getter for FileFilter
[ https://issues.apache.org/jira/browse/IO-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-262. Resolution: Fixed Fix Version/s: 2.1 Fixed, thanks for the suggestion http://svn.apache.org/viewvc?view=revision&revision=1080820 > FileAlterationObserver has no getter for FileFilter > --- > > Key: IO-262 > URL: https://issues.apache.org/jira/browse/IO-262 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.0, 2.0.1 >Reporter: Lae >Priority: Trivial > Fix For: 2.1 > > Original Estimate: 5m > Remaining Estimate: 5m > > FileAlterationObserver accepts a FileFilter, but there is no getter for it, > which causes inconvenience when implementing a FileAlterationListener. > For example, when implementing > FileAlterationListener.onStart(FileAlterationObserver), I wanted to get all > existing files under FileAlterationObserver.getDirectory() that satisfies the > FileFilter the user used to construct the observer, so that I can keep track > of present states of the target files as well as their future states. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (BEANUTILS-390) BeanComparator throws exception for null property values
[ https://issues.apache.org/jira/browse/BEANUTILS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-390. --- Resolution: Won't Fix There is no need for NullSafeBeanComparator - you can construct a BeanComparator with any Comparator implementation, so you just need to do that with a null-safe flavour. As you point out, the NullPointerException is in ComparableComparator - which isn't even part of BeanUtils > BeanComparator throws exception for null property values > > > Key: BEANUTILS-390 > URL: https://issues.apache.org/jira/browse/BEANUTILS-390 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean-Collections >Affects Versions: 1.8.3 >Reporter: Matthew Toso >Priority: Minor > Attachments: NullSafeBeanComparator.java > > > When using a BeanComparator to sort on a bean property that may contain null > values, an exception is thrown. By default, the BeanComparator uses a > ComparableComparator internally. ComparableComparator in turn throws a > NullPointerException when it attempts to compare to a null value. My proposed > solution is extending BeanComparator with a new class, > NullSafeBeanComparator, that incorporates logic from NullComparator. I have a > working example and will attach it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-265) vararg constructor in AndFileFilter and OrFileFilter is required
[ https://issues.apache.org/jira/browse/IO-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005910#comment-13005910 ] Niall Pemberton commented on IO-265: You can use: * FileFilterUtils.and(IOFileFilter...) - http://tinyurl.com/5ugznoo * FileFilterUtils.or(IOFileFilter...) - http://tinyurl.com/6zz6r3u > vararg constructor in AndFileFilter and OrFileFilter is required > > > Key: IO-265 > URL: https://issues.apache.org/jira/browse/IO-265 > Project: Commons IO > Issue Type: Improvement > Components: Filters >Affects Versions: 2.0.1 >Reporter: Yegor Bugayenko >Priority: Minor > > Would be nice to have a vararg constructor in AndFileFilter and OrFileFilter. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (LANG-679) StringUtils.startsWithIgnoreCase whrong documentation
[ https://issues.apache.org/jira/browse/LANG-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-679. -- Resolution: Duplicate Duplicates LANG-460 fixed in Lang 2.5 > StringUtils.startsWithIgnoreCase whrong documentation > - > > Key: LANG-679 > URL: https://issues.apache.org/jira/browse/LANG-679 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.4 >Reporter: Michael Neifeld > > Examples within JavaDoc misleads about parameters - according to examples the > string and the prefix misplaced. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (BEANUTILS-388) WrapDynaBean should handle Boolean property with is...() getter
[
https://issues.apache.org/jira/browse/BEANUTILS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-388.
---
Resolution: Duplicate
Duplicates BEANUTILS-321, BEANUTILS-356, BEANUTILS-364
> WrapDynaBean should handle Boolean property with is...() getter
> ---
>
> Key: BEANUTILS-388
> URL: https://issues.apache.org/jira/browse/BEANUTILS-388
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.8.3
> Environment: Linux 2.6.35.11-83.fc14.i686.PAE
>Reporter: Marco Benuzzi
>
> Stub generated from wsdl by wsimport (ant task com.sun.tools.ws.ant.WsImport)
> have some properties defined with Boolean class and getter method is...()
> instead of get...().
> Using WrapDynaBean to inspect classes which contain those Boolean give
> NoSuchMethodException.
> Below a test code which show the problem with property "c"
> In my opinion this code should work.
> {noformat}
> public class Custom {
>
> public static class Test {
> private Integer a;
> private Boolean b;
> private Boolean c;
> public Integer getA() {
> return a;
> }
> public void setA(Integer a) {
> this.a = a;
> }
> public Boolean getB() {
> return b;
> }
> public void setB(Boolean b) {
> this.b = b;
> }
> public Boolean isC() {
> return c;
> }
> public void setC(Boolean c) {
> this.c = c;
> }
>
> }
>
> public static void main(String[] args) {
> try {
> Test object = new Test();
> object.setA(100);
> object.setB(true);
> DynaBean dynaBean = new WrapDynaBean(object);
> for (DynaProperty propDesc :
> dynaBean.getDynaClass().getDynaProperties()) {
> System.out.println("name = " + propDesc.getName());
> System.out.println("class = " +
> propDesc.getType().getName());
> System.out.println("value = " +
> dynaBean.get(propDesc.getName()));
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {noformat}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (BEANUTILS-387) [beanutils] copyProperties() throws a ConversionException : No value specified for 'Date' when the field is a java.util.Date with a null value
[
https://issues.apache.org/jira/browse/BEANUTILS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-387.
---
Resolution: Won't Fix
Prior to BeanUtils 1.8.0 there was no converter for java.util.Date and date
properties were copied unchanged - so *null* didn't cause any issue. BeanUtils
1.8.0 introduced a date converter (BEANUTILS-255), but as you discovered the
default behaviour for *null* is to throw an exception. Registering a
DateConverter with a default value of *null* is the correct solution to your
issue.
This is working as intended, so closing this issue as WONT FIX.
> [beanutils] copyProperties() throws a ConversionException : No value
> specified for 'Date' when the field is a java.util.Date with a null value
> ---
>
> Key: BEANUTILS-387
> URL: https://issues.apache.org/jira/browse/BEANUTILS-387
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.8.3
>Reporter: Daniel Marchese
>
> We have migrated the library from version 1.6.0 to 1.8.0 and the
> copyProperties() method fails when copying a java.util.Date attribute with a
> null value.
> Here is a simple testcase :
> {code}
> public class Test {
> private Date date;
>
> public Date getDate() { return date;}
> public void setDate(Date date) { this.date = date; }
> public static void main(String[] args) throws Exception {
> Test dest = new Test();
> Test source = new Test();
> BeanUtils.copyProperties(dest, source);
> }
> }
> {code}
> As a workaround, we can do this :
> ConvertUtils.register(new DateConverter(null), Date.class);
> When can also use PropertyUtils.copyProperties() because in this case no
> conversion is required but the impact is unknown on our big application.
> The problem is that there seems to be a regression between version 1.6.0 and
> 1.8.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-109) Allow the build to run with Maven 2 and Maven 3
[ https://issues.apache.org/jira/browse/CODEC-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984202#action_12984202 ] Niall Pemberton commented on CODEC-109: --- You need to check the "Plugins Compatibility Matrix" for site - see: https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html Says there you need maven-project-info-reports-plugin version 2.2, (not 2.1.2) We had a thread on m2 earlier here: http://markmail.org/message/32j6w3xtwdjbi2h4 and created a wiki page here: http://wiki.apache.org/commons/Maven3Plan > Allow the build to run with Maven 2 and Maven 3 > --- > > Key: CODEC-109 > URL: https://issues.apache.org/jira/browse/CODEC-109 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.4 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) > Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500) > Java version: 1.6.0_23 > Java home: C:\Program Files\Java\jdk1.6.0_23\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > > Allow the build to run with Maven 2 and Maven 3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMMONSSITE-57) Fix broken link on http://commons.apache.org/mail-lists.html
[ https://issues.apache.org/jira/browse/COMMONSSITE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983226#action_12983226 ] Niall Pemberton commented on COMMONSSITE-57: I fixed this a while ago: http://svn.apache.org/viewvc?view=revision&revision=1005109 Needs a release of commons-build-plugin now > Fix broken link on http://commons.apache.org/mail-lists.html > > > Key: COMMONSSITE-57 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-57 > Project: Commons All > Issue Type: Bug > Components: Site >Reporter: Konstantin Kolinko >Assignee: Niall Pemberton >Priority: Trivial > Attachments: mail-lists.xml.patch > > > Link to the Apache archive of announce@apache mailing list is broken. The > link points to > http://mail-archives.apache.org/mod_mbox/announce/ > which gives 404. The correct address is > http://mail-archives.apache.org/mod_mbox/www-announce/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (BEANUTILS-386) Maven - missing dependency on Commons Collections
[ https://issues.apache.org/jira/browse/BEANUTILS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved BEANUTILS-386. --- Resolution: Invalid BeanUtils 1.8.3 specifies commons-collections in its pom as a dependency which you can see if you look here: * http://repo2.maven.org/maven2/commons-beanutils/commons-beanutils/1.8.3/commons-beanutils-1.8.3.pom However it is marked as *optional* which means that you need to specify that dependency yourself if you use those part of BeanUtils (such as BeanMap) that require it. > Maven - missing dependency on Commons Collections > - > > Key: BEANUTILS-386 > URL: https://issues.apache.org/jira/browse/BEANUTILS-386 > Project: Commons BeanUtils > Issue Type: Improvement >Affects Versions: 1.8.3 >Reporter: Enal Posi >Priority: Minor > > Our project is configured with a Maven dependency on commons-beanutils. > BeanMap(Object) seems to have a dependency on > org.apache.commons.collections.Transformer, which is found in > commons-collections. However, beanutils apparently does not imply this > dependency, resulting in class not found exceptions at runtime. > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-671) Add indexOf() & lastIndexOf() methods for Whitespace and Non-whitespae to StringUtils
[
https://issues.apache.org/jira/browse/LANG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981513#action_12981513
]
Niall Pemberton commented on LANG-671:
--
It is a more powerful facility than the StringUtils.containsWhitespace() thats
already been added for LANG-625 and there are three reasons I can think of in
favour of adding this:
* LANG-625 indicates that "the basic loop is 10 times faster than regex" -
though I haven't verified this
* These methods are simpler than regex
* The definition of *whitespace* seems to be different in regexp than the
Character.isWhitespace(char) method - when I tried the changes to
StringUtilsTest I made in the 2.x branch in r1058365 - they failed in the
regexp version of the normalizeSpace() method in trunk (see
http://svn.apache.org/viewvc?view=revision&revision=1058365)
Having said that I think you're idea is a good one. Do you object to having
both?
> Add indexOf() & lastIndexOf() methods for Whitespace and Non-whitespae to
> StringUtils
> -
>
> Key: LANG-671
> URL: https://issues.apache.org/jira/browse/LANG-671
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Niall Pemberton
> Attachments: LANG-671-StringUtils-whitespace.patch
>
>
> Whitespace methods:
> {code}
> public static int indexOfWhitespace(CharSequence str, int startPos)
> public static int lastIndexOfWhitespace(CharSequence str, int startPos)
> {code}
> Non-whitespace methods:
> {code}
> public static int indexOfNonWhitespace(CharSequence str, int startPos)
> public static int lastIndexOfNonWhitespace(CharSequence str, int startPos)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-671) Add indexOf() & lastIndexOf() methods for Whitespace and Non-whitespae to StringUtils
[
https://issues.apache.org/jira/browse/LANG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-671:
-
Attachment: LANG-671-StringUtils-whitespace.patch
Attaching LANG-671-StringUtils-whitespace.patch
> Add indexOf() & lastIndexOf() methods for Whitespace and Non-whitespae to
> StringUtils
> -
>
> Key: LANG-671
> URL: https://issues.apache.org/jira/browse/LANG-671
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Niall Pemberton
> Attachments: LANG-671-StringUtils-whitespace.patch
>
>
> Whitespace methods:
> {code}
> public static int indexOfWhitespace(CharSequence str, int startPos)
> public static int lastIndexOfWhitespace(CharSequence str, int startPos)
> {code}
> Non-whitespace methods:
> {code}
> public static int indexOfNonWhitespace(CharSequence str, int startPos)
> public static int lastIndexOfNonWhitespace(CharSequence str, int startPos)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-671) Add indexOf() & lastIndexOf() methods for Whitespace and Non-whitespae to StringUtils
Add indexOf() & lastIndexOf() methods for Whitespace and Non-whitespae to
StringUtils
-
Key: LANG-671
URL: https://issues.apache.org/jira/browse/LANG-671
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Niall Pemberton
Whitespace methods:
{code}
public static int indexOfWhitespace(CharSequence str, int startPos)
public static int lastIndexOfWhitespace(CharSequence str, int startPos)
{code}
Non-whitespace methods:
{code}
public static int indexOfNonWhitespace(CharSequence str, int startPos)
public static int lastIndexOfNonWhitespace(CharSequence str, int startPos)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-593) Testing with JDK 1.7
[ https://issues.apache.org/jira/browse/LANG-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980472#action_12980472 ] Niall Pemberton commented on LANG-593: -- With b102 the same problem with FastDateFormatTest exists With b124 the same problem with FastDateFormatTest exists and now ExtendedMessageFormatTest also fails The problem with ExtendedMessageFormatTest is that it is using Locale.getDefault() when no Locale is supplied, which is returning Locale..en_US - but DateFormat & Number format are now (in b124) using the new Locale.getDefault(Locale.Category.FORMAT) which is returning Locale.en_GB. So this appears to be a bug in the 1.7 JDK > Testing with JDK 1.7 > > > Key: LANG-593 > URL: https://issues.apache.org/jira/browse/LANG-593 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 2.5 >Reporter: Niall Pemberton > Fix For: 3.0 > > > I ran the tests for the Lang 2.5 RC2 using JDK 1.7.0-b78 and they all passed > except the testFormat() in FastDateFormatTest. > The problem seems to be that in JDK 1.7 the "yyy" and "y" patterns now cause > a four digit year with SimpleDateFormat - whereas previous JDK versions > resulted in a 2 digit year (as FastDateFormat does). > JDK 1.7 hasn't yet been released and that may be fixed in the JDK by the time > it is, but I thought it worth making a note. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-607) StringUtils methods do not handle Unicode 2.0+ supplementary characters correctly.
[ https://issues.apache.org/jira/browse/LANG-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979877#action_12979877 ] Niall Pemberton commented on LANG-607: -- Is the work thats been done so far OK to go into a release? I'm wondering whether I should revert it from the 2.x branch before releasing 2.6 or is whats been done in trunk (and ported to 2.x) good to go? > StringUtils methods do not handle Unicode 2.0+ supplementary characters > correctly. > -- > > Key: LANG-607 > URL: https://issues.apache.org/jira/browse/LANG-607 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.5 > Environment: java version "1.6.0_16" > Java(TM) SE Runtime Environment (build 1.6.0_16-b01) > Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) > Microsoft Windows [Version 6.0.6002] > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_16 > Java home: C:\Program Files\Java\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-607.diff > > > StringUtils.containsAny methods incorrectly matches Unicode 2.0+ > supplementary characters. > For example, define a test fixture to be the Unicode character U+2 where > U+2 is written in Java source as "\uD840\uDC00" > private static final String CharU2 = "\uD840\uDC00"; > private static final String CharU20001 = "\uD840\uDC01"; > You can see Unicode supplementary characters correctly implemented in the JRE > call: > assertEquals(-1, CharU2.indexOf(CharU20001)); > But this is broken: > assertEquals(false, StringUtils.containsAny(CharU2, CharU20001)); > assertEquals(false, StringUtils.containsAny(CharU20001, CharU2)); > This is fine: > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU2)); > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU20001)); > assertEquals(true, StringUtils.contains(CharU2, CharU2)); > assertEquals(false, StringUtils.contains(CharU2, CharU20001)); > because the method calls the JRE to perform the match. > More than you want to know: > - http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-636) text.ExtendedMessageFormat doesn't override java.text.MessageFormat.equals(Object)
[ https://issues.apache.org/jira/browse/LANG-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-636. -- Resolution: Fixed Fix Version/s: (was: 3.0) 2.6 Assignee: Niall Pemberton Fixed in the trunk and 2.x branch > text.ExtendedMessageFormat doesn't override > java.text.MessageFormat.equals(Object) > -- > > Key: LANG-636 > URL: https://issues.apache.org/jira/browse/LANG-636 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Reporter: Sebb >Assignee: Niall Pemberton > Fix For: 2.6 > > > Findbugs: > Bug: org.apache.commons.lang3.text.ExtendedMessageFormat doesn't override > java.text.MessageFormat.equals(Object) > Pattern id: EQ_DOESNT_OVERRIDE_EQUALS, type: Eq, category: STYLE > This class extends a class that defines an equals method and adds fields, but > doesn't define an equals method itself. Thus, equality on instances of this > class will ignore the identity of the subclass and the added fields. Be sure > this is what is intended, and that you don't need to override the equals > method. Even if you don't need to override the equals method, consider > overriding it anyway to document the fact that the equals method for the > subclass just return the result of invoking super.equals(o). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-670) Add notEqual() method to ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-670. -- Resolution: Fixed Fixed: http://svn.apache.org/viewvc?view=revision&revision=1057410 > Add notEqual() method to ObjectUtils > > > Key: LANG-670 > URL: https://issues.apache.org/jira/browse/LANG-670 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.5 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.6 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-670) Add notEqual() method to ObjectUtils
Add notEqual() method to ObjectUtils Key: LANG-670 URL: https://issues.apache.org/jira/browse/LANG-670 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.5 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.6 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-607) StringUtils methods do not handle Unicode 2.0+ supplementary characters correctly.
[ https://issues.apache.org/jira/browse/LANG-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979781#action_12979781 ] Niall Pemberton commented on LANG-607: -- Is the work complete on this? I have ported the changes back to the 2.x branch (I copied the Character.isHighSurrogate(char) method from Apache Harmony into CharUtils) > StringUtils methods do not handle Unicode 2.0+ supplementary characters > correctly. > -- > > Key: LANG-607 > URL: https://issues.apache.org/jira/browse/LANG-607 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.5 > Environment: java version "1.6.0_16" > Java(TM) SE Runtime Environment (build 1.6.0_16-b01) > Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) > Microsoft Windows [Version 6.0.6002] > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_16 > Java home: C:\Program Files\Java\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-607.diff > > > StringUtils.containsAny methods incorrectly matches Unicode 2.0+ > supplementary characters. > For example, define a test fixture to be the Unicode character U+2 where > U+2 is written in Java source as "\uD840\uDC00" > private static final String CharU2 = "\uD840\uDC00"; > private static final String CharU20001 = "\uD840\uDC01"; > You can see Unicode supplementary characters correctly implemented in the JRE > call: > assertEquals(-1, CharU2.indexOf(CharU20001)); > But this is broken: > assertEquals(false, StringUtils.containsAny(CharU2, CharU20001)); > assertEquals(false, StringUtils.containsAny(CharU20001, CharU2)); > This is fine: > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU2)); > assertEquals(true, StringUtils.contains(CharU2 + CharU20001, > CharU20001)); > assertEquals(true, StringUtils.contains(CharU2, CharU2)); > assertEquals(false, StringUtils.contains(CharU2, CharU20001)); > because the method calls the JRE to perform the match. > More than you want to know: > - http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-603) Removes "implement Cloneable" from StrBuilder
[ https://issues.apache.org/jira/browse/LANG-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-603. -- Resolution: Won't Fix The clone() method has been implemented in the 2.x branch (see LANG-302) > Removes "implement Cloneable" from StrBuilder > - > > Key: LANG-603 > URL: https://issues.apache.org/jira/browse/LANG-603 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Jason Ng Yong Liang >Priority: Trivial > Fix For: 2.x > > > I know this will be fixed in 3.0; meanwhile however, it's confusing people > when they try to use the clone method, only to find that it's not visible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-302) StrBuilder does not implement clone()
[ https://issues.apache.org/jira/browse/LANG-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-302: - Fix Version/s: 2.6 Implemented clone() method in LANG 2.x branch: http://svn.apache.org/viewvc?view=revision&revision=1057349 > StrBuilder does not implement clone() > - > > Key: LANG-302 > URL: https://issues.apache.org/jira/browse/LANG-302 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Henri Yandell > Fix For: 3.0, 2.6 > > Attachments: LANG-302-clone-v3.patch > > > As reported by FindBugs. > Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-302) StrBuilder does not implement clone()
[ https://issues.apache.org/jira/browse/LANG-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-302: - Attachment: (was: LANG-302-clone-v2.patch) > StrBuilder does not implement clone() > - > > Key: LANG-302 > URL: https://issues.apache.org/jira/browse/LANG-302 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: LANG-302-clone-v3.patch > > > As reported by FindBugs. > Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-302) StrBuilder does not implement clone()
[ https://issues.apache.org/jira/browse/LANG-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-302: - Attachment: LANG-302-clone-v3.patch v2 of patch attached > StrBuilder does not implement clone() > - > > Key: LANG-302 > URL: https://issues.apache.org/jira/browse/LANG-302 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: LANG-302-clone-v3.patch > > > As reported by FindBugs. > Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-302) StrBuilder does not implement clone()
[ https://issues.apache.org/jira/browse/LANG-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-302: - Attachment: (was: LANG-302-clone.patch) > StrBuilder does not implement clone() > - > > Key: LANG-302 > URL: https://issues.apache.org/jira/browse/LANG-302 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: LANG-302-clone-v2.patch > > > As reported by FindBugs. > Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-302) StrBuilder does not implement clone()
[ https://issues.apache.org/jira/browse/LANG-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-302: - Attachment: LANG-302-clone-v2.patch v2 of patch attached > StrBuilder does not implement clone() > - > > Key: LANG-302 > URL: https://issues.apache.org/jira/browse/LANG-302 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: LANG-302-clone-v2.patch > > > As reported by FindBugs. > Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-669) Use StrBuilder instead of StringBuffer to improve performance where sync. is not an issue (Lang 2.x branch)
[ https://issues.apache.org/jira/browse/LANG-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979455#action_12979455 ] Niall Pemberton commented on LANG-669: -- http://svn.apache.org/viewvc?view=revision&revision=1057072 > Use StrBuilder instead of StringBuffer to improve performance where sync. is > not an issue (Lang 2.x branch) > --- > > Key: LANG-669 > URL: https://issues.apache.org/jira/browse/LANG-669 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 2.5 >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.6 > > > StrBuilder is an un-synchronized equivalent of StringBuffer. We should *eat > our own dogfood* and use it where synchronization is not an issue in the Lang > 2.x branch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-669) Use StrBuilder instead of StringBuffer to improve performance where sync. is not an issue (Lang 2.x branch)
[ https://issues.apache.org/jira/browse/LANG-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-669. -- Resolution: Fixed > Use StrBuilder instead of StringBuffer to improve performance where sync. is > not an issue (Lang 2.x branch) > --- > > Key: LANG-669 > URL: https://issues.apache.org/jira/browse/LANG-669 > Project: Commons Lang > Issue Type: Improvement > Components: General >Affects Versions: 2.5 >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.6 > > > StrBuilder is an un-synchronized equivalent of StringBuffer. We should *eat > our own dogfood* and use it where synchronization is not an issue in the Lang > 2.x branch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-669) Use StrBuilder instead of StringBuffer to improve performance where sync. is not an issue (Lang 2.x branch)
Use StrBuilder instead of StringBuffer to improve performance where sync. is not an issue (Lang 2.x branch) --- Key: LANG-669 URL: https://issues.apache.org/jira/browse/LANG-669 Project: Commons Lang Issue Type: Improvement Components: General Affects Versions: 2.5 Reporter: Niall Pemberton Assignee: Niall Pemberton Fix For: 2.6 StrBuilder is an un-synchronized equivalent of StringBuffer. We should *eat our own dogfood* and use it where synchronization is not an issue in the Lang 2.x branch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-302) StrBuilder does not implement clone()
[ https://issues.apache.org/jira/browse/LANG-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-302: - Attachment: LANG-302-clone.patch I know this is resolved for 3.0 - but Sebb raised this again concerning a 2.6 release (also LANG-603): * http://markmail.org/message/qa42zi27j4svsuna I agree with Stephen that we can't remove Cloneable in the 2.x branch because of compatibility issues. IMO the best solution is to implement clone(). As it stands this implementation is breaking the contract of Cloneable and I think that is worse than any difference with StringBuilder or StringBuffer. Its also very trivial to implement. Attaching a patch to implement clone > StrBuilder does not implement clone() > - > > Key: LANG-302 > URL: https://issues.apache.org/jira/browse/LANG-302 > Project: Commons Lang > Issue Type: Bug > Components: lang.text.* >Affects Versions: 2.2 >Reporter: Henri Yandell > Fix For: 3.0 > > Attachments: LANG-302-clone.patch > > > As reported by FindBugs. > Does StrBuilder need to be Cloneable? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-594) DateUtils equal & compare functions up to most significant field
[
https://issues.apache.org/jira/browse/LANG-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979171#action_12979171
]
Niall Pemberton commented on LANG-594:
--
This could do with some unit tests
> DateUtils equal & compare functions up to most significant field
>
>
> Key: LANG-594
> URL: https://issues.apache.org/jira/browse/LANG-594
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Paul Benedict
>Assignee: Paul Benedict
>Priority: Minor
> Fix For: 3.0
>
>
> DateUtils.truncate() is great to get rid of all data except the most
> significant field. I suggest two new methods to perform comparisons of the
> like. This would be especially useful in integration tests with databases
> where precision is based on the column type (date vs. timestamps).
> {code}
> DateUtils.equals(Date d1, Date d2, int field);
> DateUtils.compareTo(Date d1, Date d2, int field);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-667) Add a Null-safe compare() method to ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978972#action_12978972 ] Niall Pemberton commented on LANG-667: -- Simplified the code as per Julien's suggestion: http://svn.apache.org/viewvc?view=revision&revision=1056520 > Add a Null-safe compare() method to ObjectUtils > --- > > Key: LANG-667 > URL: https://issues.apache.org/jira/browse/LANG-667 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.5 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 3.0 > > > Add a Null-safe compare() method to ObjectUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-667) Add a Null-safe compare() method to ObjectUtils
[ https://issues.apache.org/jira/browse/LANG-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978707#action_12978707 ] Niall Pemberton commented on LANG-667: -- @Julien - thanks for the suggestion, I'll look at this when I get home @Paul - Lang is all about adding useful utilities that Java itself doesn't have and theres alot of *prior art* here of null-safe utilities. Julien's example is a great demonstration of how this function can be used to simplify code. This feature is not a Comparable implementation and so breaks no contract. I really don't understand your objection and IMO its a very weak argument to object on the basis of Comparable's JavaDoc. How would you handle implementing a compareTo() method where the properties being compared may be null - surely you're not arguing that Julien's example should fail and throw a NullPointerException if one of the properties is null? > Add a Null-safe compare() method to ObjectUtils > --- > > Key: LANG-667 > URL: https://issues.apache.org/jira/browse/LANG-667 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.5 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 3.0 > > > Add a Null-safe compare() method to ObjectUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-668) Change ObjectUtils min() & max() functions to use varargs rather than just two parameters
[
https://issues.apache.org/jira/browse/LANG-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved LANG-668.
--
Resolution: Fixed
Fixed: http://svn.apache.org/viewvc?view=revision&revision=1056134
> Change ObjectUtils min() & max() functions to use varargs rather than just
> two parameters
> -
>
> Key: LANG-668
> URL: https://issues.apache.org/jira/browse/LANG-668
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 3.0
>
>
> Currently ObjectUtils has min() and max() method with the following
> signatures:
> {code}
> public static > T min(T c1, T c2)
> public static > T max(T c1, T c2)
> {code}
> It would be useful to change these from taking just two parameters to any
> number using varags:
> {code}
> public static > T min(T... values)
> public static > T max(T... values)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-668) Change ObjectUtils min() & max() functions to use varargs rather than just two parameters
[
https://issues.apache.org/jira/browse/LANG-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton updated LANG-668:
-
Description:
Currently ObjectUtils has min() and max() method with the following signatures:
{code}
public static > T min(T c1, T c2)
public static > T max(T c1, T c2)
{code}
It would be useful to change these from taking just two parameters to any
number using varags:
{code}
public static > T min(T... values)
public static > T max(T... values)
{code}
was:
Currently ObjectUtils has min() and max() method with the following signatures:
{code}
public static > T min(T c1, T c2)
public static > T max(T c1, T c2)
{code}
It would be useful to change these from taking just two parameters to any
number using varags:
{code}
public static > T min(T... values)
public static > T max(T... values)
{code}
> Change ObjectUtils min() & max() functions to use varargs rather than just
> two parameters
> -
>
> Key: LANG-668
> URL: https://issues.apache.org/jira/browse/LANG-668
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Niall Pemberton
>Assignee: Niall Pemberton
>Priority: Minor
> Fix For: 3.0
>
>
> Currently ObjectUtils has min() and max() method with the following
> signatures:
> {code}
> public static > T min(T c1, T c2)
> public static > T max(T c1, T c2)
> {code}
> It would be useful to change these from taking just two parameters to any
> number using varags:
> {code}
> public static > T min(T... values)
> public static > T max(T... values)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
