[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358309#comment-14358309 ] Stefan Bodewig commented on COMPRESS-311: - yes, this is waht you should be doing. http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStreamTest.java?revision=1660457view=markup contains unit tests including for the long file name cases. See testWriteLongFileNamePosixMode for example. File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358261#comment-14358261 ] DARPAN KAUSHIK commented on COMPRESS-311: - Thanks a lot Stefan.!! I am trying to create a Tar package.Can you cite an example on how to use this extension with TarArchiveOutputStream.I am using: TarArchiveOutputStream tos=new TarArchiveOutputStream(OutputStream); tos.setLongFileMode(TarArchiveOutputStream.LONGFILE_POSIX); File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358309#comment-14358309 ] Stefan Bodewig edited comment on COMPRESS-311 at 3/12/15 8:38 AM: -- yes, this is what you should be doing. http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStreamTest.java?revision=1660457view=markup contains unit tests including for the long file name cases. See testWriteLongFileNamePosixMode for example. was (Author: bodewig): yes, this is waht you should be doing. http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveOutputStreamTest.java?revision=1660457view=markup contains unit tests including for the long file name cases. See testWriteLongFileNamePosixMode for example. File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BEANUTILS-474) FluentPropertyBeanIntrospector does not use the same naming algorithm as DefaultBeanIntrospector
[ https://issues.apache.org/jira/browse/BEANUTILS-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358341#comment-14358341 ] Benedikt Ritter commented on BEANUTILS-474: --- Patches welcome! Don't forget to include a junit tests ;-) FluentPropertyBeanIntrospector does not use the same naming algorithm as DefaultBeanIntrospector Key: BEANUTILS-474 URL: https://issues.apache.org/jira/browse/BEANUTILS-474 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.9.2 Reporter: Michael Grove Priority: Minor Labels: naming, property Original Estimate: 1h Remaining Estimate: 1h If you have a bean with the methods `URI getURI()` and `void setURI(URI)` the `DefaultBeanIntrospector` will find the property `URI` with the expected getter and setter. The `FluentPropertyBeanIntrospector` will instead find the property `uRI`, which (imo) is incorrect; you end up with a duplicate of the same property when using the two introspectors together. `DefaultBeanIntrospector` uses `Introspector#decapitalize` whereas `FluentPropertyBeanIntrospector` uses it's internal method `propertyName` which is where the difference arises from. `FluentPropertyBeanIntrospector` should just use `Introspector#decapitalize` when generating names. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1091) Shutdown thread pools in test cases
[ https://issues.apache.org/jira/browse/LANG-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358344#comment-14358344 ] Benedikt Ritter commented on LANG-1091: --- Patches welcome! :-) Shutdown thread pools in test cases --- Key: LANG-1091 URL: https://issues.apache.org/jira/browse/LANG-1091 Project: Commons Lang Issue Type: Improvement Components: lang.builder.*, lang.concurrent.* Affects Versions: 4.0 Environment: Linux, JDK 7 Reporter: Jesper Öqvist Original Estimate: 1h Remaining Estimate: 1h The tests, in for example org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest, create thread pools which are not shut down properly, leading to idle worker threads that can prevent the JVM from shutting down properly. Suggested fix: shutdown() on the thread pool where a call to shutdown or shutdownNow is missing. Affected classes (these were the ones I could find easily, I may have missed some): * org.apache.commons.lang3.builder.ReflectionToStringStyleConcurrencyTest * org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest * org.apache.commons.lang3.concurrent.CallableBackgroundInitializerTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358386#comment-14358386 ] DARPAN KAUSHIK commented on COMPRESS-311: - Thanks. Can we set it at object instantiation time ? or how to set it as default mode? File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358385#comment-14358385 ] DARPAN KAUSHIK commented on COMPRESS-311: - Thanks Stefan.But its not working for me..still error is coming.Below is my code snippet: TarArchiveOutputStream tos=new TarArchiveOutputStream(OutputStream); tos.setLongFileMode(TarArchiveOutputStream.LONGFILE_POSIX); any other alternative or am I doing something wrong.? File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358332#comment-14358332 ] Emmanuel Bourg commented on COMPRESS-311: - What about enabling one of the long file modes by default? File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1091) Shutdown thread pools in test cases
[ https://issues.apache.org/jira/browse/LANG-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1091: -- Fix Version/s: Patch Needed Shutdown thread pools in test cases --- Key: LANG-1091 URL: https://issues.apache.org/jira/browse/LANG-1091 Project: Commons Lang Issue Type: Improvement Components: lang.builder.*, lang.concurrent.* Affects Versions: 3.3.2 Environment: Linux, JDK 7 Reporter: Jesper Öqvist Fix For: Patch Needed, 3.4 Original Estimate: 1h Remaining Estimate: 1h The tests, in for example org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest, create thread pools which are not shut down properly, leading to idle worker threads that can prevent the JVM from shutting down properly. Suggested fix: shutdown() on the thread pool where a call to shutdown or shutdownNow is missing. Affected classes (these were the ones I could find easily, I may have missed some): * org.apache.commons.lang3.builder.ReflectionToStringStyleConcurrencyTest * org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest * org.apache.commons.lang3.concurrent.CallableBackgroundInitializerTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1091) Shutdown thread pools in test cases
[ https://issues.apache.org/jira/browse/LANG-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1091: -- Affects Version/s: (was: 4.0) 3.3.2 Shutdown thread pools in test cases --- Key: LANG-1091 URL: https://issues.apache.org/jira/browse/LANG-1091 Project: Commons Lang Issue Type: Improvement Components: lang.builder.*, lang.concurrent.* Affects Versions: 3.3.2 Environment: Linux, JDK 7 Reporter: Jesper Öqvist Fix For: Patch Needed, 3.4 Original Estimate: 1h Remaining Estimate: 1h The tests, in for example org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest, create thread pools which are not shut down properly, leading to idle worker threads that can prevent the JVM from shutting down properly. Suggested fix: shutdown() on the thread pool where a call to shutdown or shutdownNow is missing. Affected classes (these were the ones I could find easily, I may have missed some): * org.apache.commons.lang3.builder.ReflectionToStringStyleConcurrencyTest * org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest * org.apache.commons.lang3.concurrent.CallableBackgroundInitializerTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358347#comment-14358347
]
Benedikt Ritter commented on LANG-1092:
---
The time package is killing me... Feel free to commit the suggested
improvements.
Unit Test failing due to timezone order on JVM/machine
--
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
Fix For: Review Patch, 3.4
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when
the test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens
on every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java (revision 1665715)
+++ FastDatePrinterTest.java (working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1091) Shutdown thread pools in test cases
[ https://issues.apache.org/jira/browse/LANG-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1091: -- Fix Version/s: 3.4 Shutdown thread pools in test cases --- Key: LANG-1091 URL: https://issues.apache.org/jira/browse/LANG-1091 Project: Commons Lang Issue Type: Improvement Components: lang.builder.*, lang.concurrent.* Affects Versions: 3.3.2 Environment: Linux, JDK 7 Reporter: Jesper Öqvist Fix For: Patch Needed, 3.4 Original Estimate: 1h Remaining Estimate: 1h The tests, in for example org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest, create thread pools which are not shut down properly, leading to idle worker threads that can prevent the JVM from shutting down properly. Suggested fix: shutdown() on the thread pool where a call to shutdown or shutdownNow is missing. Affected classes (these were the ones I could find easily, I may have missed some): * org.apache.commons.lang3.builder.ReflectionToStringStyleConcurrencyTest * org.apache.commons.lang3.builder.ToStringStyleConcurrencyTest * org.apache.commons.lang3.concurrent.CallableBackgroundInitializerTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1092:
--
Fix Version/s: 3.4
Review Patch
Unit Test failing due to timezone order on JVM/machine
--
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
Fix For: Review Patch, 3.4
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when
the test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens
on every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java (revision 1665715)
+++ FastDatePrinterTest.java (working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1046) containsPattern method for StringUtils?
[ https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358355#comment-14358355 ] Benedikt Ritter commented on LANG-1046: --- I'm not sure I understand this completely. Can you give some examples? containsPattern method for StringUtils? --- Key: LANG-1046 URL: https://issues.apache.org/jira/browse/LANG-1046 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebb Fix For: Discussion The JVM Matcher class only supports anchored matches. It might perhaps be useful to add a containsPattern(CharSequence input, String pattern) method that returns true if the input contains the pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1093) Add ClassUtils.getAbbreviatedName
[ https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358455#comment-14358455 ] ASF GitHub Bot commented on LANG-1093: -- GitHub user CodingFabian opened a pull request: https://github.com/apache/commons-lang/pull/48 LANG-1093 - Add ClassUtils.getAbbreviatedName() getAbbreviatedName() allows to create a short version of a class name. It accepts a parameter which gives the desired length, but ClassUtils will make sure that the result keeps most of its meaning, which can result in shorter or longer abbreviations than requested. This pattern is applied by logging frameworks and generally accepted to produce nice and understandable abbreviations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/CodingFabian/commons-lang abbreviateClassName Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/48.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #48 commit 4eaba0fee42c7746d5e71ef9096d508c070ec41e Author: Fabian Lange lange.fab...@gmail.com Date: 2015-03-12T10:21:03Z LANG-1093 - Add ClassUtils.getAbbreviatedName() getAbbreviatedName() allows to create a short version of a class name. It accepts a parameter which gives the desired length, but ClassUtils will make sure that the result keeps most of its meaning, which can result in shorter or longer abbreviations than requested. This pattern is applied by logging frameworks and generally accepted to produce nice and understandable abbreviations. Add ClassUtils.getAbbreviatedName - Key: LANG-1093 URL: https://issues.apache.org/jira/browse/LANG-1093 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Fabian Lange It would be really nice to have a class name shortener functionality available similar to what some logger frameworks use. I took the idea for my implementation from logback, including the quirky treatment of the desired length argument, feel free to discuss on the PR/here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358709#comment-14358709
]
Benedikt Ritter commented on LANG-1094:
---
Are we sure this is a bug in lang? Sounds more like a bug in the JavaDoc tool.
Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
Fix For: Patch Needed
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to
link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1094:
---
Fix Version/s: (was: Patch Needed)
Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to
link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358726#comment-14358726
]
Duncan Jones commented on LANG-1094:
I'm not sure, but I wanted to raise it before I forgot about it. It could be an
error in how we've configured our Javadoc output or it might be that we need to
choose a different version of a Javadoc plugin to avoid a bug in Javadoc.
I've removed the patch needed label, since we don't' know what we're dealing
with yet.
Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to
link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1092) Unit Test failing due to timezone order on JVM/machine
[
https://issues.apache.org/jira/browse/LANG-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359792#comment-14359792
]
Henri Yandell commented on LANG-1092:
-
I hear you, I winced when I saw the build was failing in the time package.
My improvement is merely one that makes the test 'work', and fail for everyone.
I think we should remove the time package from 3.4, putting it in its own
'legacy' jar :)
Unit Test failing due to timezone order on JVM/machine
--
Key: LANG-1092
URL: https://issues.apache.org/jira/browse/LANG-1092
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.3.2
Reporter: Henri Yandell
Fix For: Review Patch, 3.4
At work we're getting build issues with Lang 3.3.2 (and any since 3.2 when
the test code was introduced in LANG-818). The test
org.apache.commons.lang3.time.FastDatePrinterTest.testCalendarTimezoneRespected
picks a timezone and runs a test on it. One assumes that timezones usually
work, but some are not - so it depends on the order of timezones returned by
TimeZone.getAvailableIDs().
This would seem to imply a daylight savings time bug in FastDateFormat. This
may be the same issue as LANG-916.
If you adjust the for loop such that the test is within the loop and happens
on every timezone, you will hit timezones that fail. e.g.:
{code}
Index: FastDatePrinterTest.java
===
--- FastDatePrinterTest.java (revision 1665715)
+++ FastDatePrinterTest.java (working copy)
@@ -269,8 +269,6 @@
for (final String zone : availableZones) {
if (!zone.equals(currentZone.getID())) {
anotherZone = TimeZone.getTimeZone(zone);
-}
-}
assertNotNull(Cannot find another timezone, anotherZone);
@@ -282,6 +280,8 @@
final String expectedValue = sdf.format(cal.getTime());
final String actualValue =
FastDateFormat.getInstance(pattern).format(cal);
assertEquals(expectedValue, actualValue);
+}
+}
}
@Test
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1046) containsPattern method for StringUtils?
[
https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358926#comment-14358926
]
Sebb commented on LANG-1046:
The first two can currently be written as:
{code:java}
assertTrue(Pattern.compile(alpha.*).matcher(alphabet).matches()); // or
alphabet.matches(alpha.*);
assertTrue(Pattern.compile(alpha.).matcher(alphabet).lookingAt());
{code}
The 3rd would need to done by updating the RE as follows:
{code:java}
assertTrue(Pattern.compile(.*+ph.b).matcher(alphabet).lookingAt());
{code}
The only string matching that is directly supported by the String class is
String.matches() which matches the whole string.
Of course that can be used for the other cases by prefixing/appending .* as
necessary to the RE, but that's a bit messy.
Perhaps there is a use-case for adding a method to do startsWith matching as
well.
For consistency, perhaps one should support all 3 match types?
i.e. match all, match start, match part.
containsPattern method for StringUtils?
---
Key: LANG-1046
URL: https://issues.apache.org/jira/browse/LANG-1046
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Sebb
Fix For: Discussion
The JVM Matcher class only supports anchored matches.
It might perhaps be useful to add a containsPattern(CharSequence input,
String pattern) method that returns true if the input contains the pattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-1046) containsPattern method for StringUtils?
[
https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358926#comment-14358926
]
Sebb edited comment on LANG-1046 at 3/12/15 4:34 PM:
-
The first two can currently be written as:
{code:java}
assertTrue(Pattern.compile(alpha.*).matcher(alphabet).matches()); // or
alphabet.matches(alpha.*);
assertTrue(Pattern.compile(alpha.).matcher(alphabet).lookingAt());
{code}
The 3rd would need to done by updating the RE as follows:
{code:java}
assertTrue(Pattern.compile(.*+ph.b).matcher(alphabet).lookingAt());
{code}
The only string matching that is directly supported by the String class is
String.matches(RE) which matches the whole string.
Of course that can be used for the other cases by prefixing/appending .* as
necessary to the RE, but that's a bit messy.
Perhaps there is a use-case for adding a method to do startsWith matching as
well.
For consistency, perhaps one should support all 3 match types?
i.e. match all, match start, match part.
was (Author: s...@apache.org):
The first two can currently be written as:
{code:java}
assertTrue(Pattern.compile(alpha.*).matcher(alphabet).matches()); // or
alphabet.matches(alpha.*);
assertTrue(Pattern.compile(alpha.).matcher(alphabet).lookingAt());
{code}
The 3rd would need to done by updating the RE as follows:
{code:java}
assertTrue(Pattern.compile(.*+ph.b).matcher(alphabet).lookingAt());
{code}
The only string matching that is directly supported by the String class is
String.matches() which matches the whole string.
Of course that can be used for the other cases by prefixing/appending .* as
necessary to the RE, but that's a bit messy.
Perhaps there is a use-case for adding a method to do startsWith matching as
well.
For consistency, perhaps one should support all 3 match types?
i.e. match all, match start, match part.
containsPattern method for StringUtils?
---
Key: LANG-1046
URL: https://issues.apache.org/jira/browse/LANG-1046
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Sebb
Fix For: Discussion
The JVM Matcher class only supports anchored matches.
It might perhaps be useful to add a containsPattern(CharSequence input,
String pattern) method that returns true if the input contains the pattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358818#comment-14358818
]
Sebb commented on LANG-1094:
It's not a bug in LANG.
It is either in Javadoc or in Maven's handling of Javadoc.
It may also depend on the browser being used; when I copy/paste from Firefox it
automatically converts the spaces and other unsafe chars.
What browser did you use to copy/paste the link?
Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to
link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358848#comment-14358848
]
Duncan Jones commented on LANG-1094:
I was using Chrome. However, I've looked at other Javadocs (most notably the
main Oracle docs) and I don't see this problem. So something different is
happening with the Lang docs. I'm happy to change this issue to a different
type or close it and continue discussion on the ML if that's preferable.
Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to
link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1046) containsPattern method for StringUtils?
[ https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358802#comment-14358802 ] Sebb commented on LANG-1046: The string alphabet matches alpha.* and starts with alph.. Both of these are supported. They are anchored to the start of the string. It also contains ph.b, but matching this is not directly supported. containsPattern method for StringUtils? --- Key: LANG-1046 URL: https://issues.apache.org/jira/browse/LANG-1046 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebb Fix For: Discussion The JVM Matcher class only supports anchored matches. It might perhaps be useful to add a containsPattern(CharSequence input, String pattern) method that returns true if the input contains the pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1046) containsPattern method for StringUtils?
[ https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358802#comment-14358802 ] Sebb edited comment on LANG-1046 at 3/12/15 4:28 PM: - The string alphabet matches alpha.* and starts with alph.. Both of these are directly supported by Java. They are anchored to the start of the string. It also contains ph.b, but matching this is not directly supported. was (Author: s...@apache.org): The string alphabet matches alpha.* and starts with alph.. Both of these are supported. They are anchored to the start of the string. It also contains ph.b, but matching this is not directly supported. containsPattern method for StringUtils? --- Key: LANG-1046 URL: https://issues.apache.org/jira/browse/LANG-1046 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Sebb Fix For: Discussion The JVM Matcher class only supports anchored matches. It might perhaps be useful to add a containsPattern(CharSequence input, String pattern) method that returns true if the input contains the pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1046) containsPattern method for StringUtils?
[
https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358838#comment-14358838
]
Benedikt Ritter commented on LANG-1046:
---
Okay, how about this:
{code:java}
assertTrue(StringUtils.containsPattern(alphabet, alpha.*));
assertTrue(StringUtils.containsPattern(alphabet, alph.));
assertTrue(StringUtils.containsPattern(alphabet, ph.b));
{code}
containsPattern method for StringUtils?
---
Key: LANG-1046
URL: https://issues.apache.org/jira/browse/LANG-1046
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Sebb
Fix For: Discussion
The JVM Matcher class only supports anchored matches.
It might perhaps be useful to add a containsPattern(CharSequence input,
String pattern) method that returns true if the input contains the pattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1046) containsPattern method for StringUtils?
[
https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358837#comment-14358837
]
Benedikt Ritter commented on LANG-1046:
---
Okay, how about this:
{code:java}
assertTrue(StringUtils.containsPattern(alphabet, alpha.*));
assertTrue(StringUtils.containsPattern(alphabet, alph.));
assertTrue(StringUtils.containsPattern(alphabet, ph.b));
{code}
containsPattern method for StringUtils?
---
Key: LANG-1046
URL: https://issues.apache.org/jira/browse/LANG-1046
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Sebb
Fix For: Discussion
The JVM Matcher class only supports anchored matches.
It might perhaps be useful to add a containsPattern(CharSequence input,
String pattern) method that returns true if the input contains the pattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (LANG-1046) containsPattern method for StringUtils?
[
https://issues.apache.org/jira/browse/LANG-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1046:
--
Comment: was deleted
(was: Okay, how about this:
{code:java}
assertTrue(StringUtils.containsPattern(alphabet, alpha.*));
assertTrue(StringUtils.containsPattern(alphabet, alph.));
assertTrue(StringUtils.containsPattern(alphabet, ph.b));
{code})
containsPattern method for StringUtils?
---
Key: LANG-1046
URL: https://issues.apache.org/jira/browse/LANG-1046
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Sebb
Fix For: Discussion
The JVM Matcher class only supports anchored matches.
It might perhaps be useful to add a containsPattern(CharSequence input,
String pattern) method that returns true if the input contains the pattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (EMAIL-68) Donation/Proposal for Commons-Email 2.0
[ https://issues.apache.org/jira/browse/EMAIL-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359075#comment-14359075 ] Roman Čičvák commented on EMAIL-68: --- I would suggest to get rid of activation 1.1 dependency as its content is already within Java Spec JRE (rt.jar), and may confuse classloader having multiple definitions of same classes. May result in java.lang.NoClassDefFoundError. Just got into this issue with javax.activation.DataHandler class. Donation/Proposal for Commons-Email 2.0 --- Key: EMAIL-68 URL: https://issues.apache.org/jira/browse/EMAIL-68 Project: Commons Email Issue Type: Improvement Affects Versions: 2.0 Reporter: Ramiro Pereira de Magalhães Fix For: 2.0 Attachments: commons.email2.zip This is a donation of code to the commons-email project. I hope it inspires people to create a more flexible, extensible and maintainable API for sending e-mail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (EMAIL-68) Donation/Proposal for Commons-Email 2.0
[ https://issues.apache.org/jira/browse/EMAIL-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359466#comment-14359466 ] Thomas Neidhart commented on EMAIL-68: -- We could get rid of the dependency already for email 1.4 if we move the minimum jdk requirements to Java 1.6 Donation/Proposal for Commons-Email 2.0 --- Key: EMAIL-68 URL: https://issues.apache.org/jira/browse/EMAIL-68 Project: Commons Email Issue Type: Improvement Affects Versions: 2.0 Reporter: Ramiro Pereira de Magalhães Fix For: 2.0 Attachments: commons.email2.zip This is a donation of code to the commons-email project. I hope it inspires people to create a more flexible, extensible and maintainable API for sending e-mail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359178#comment-14359178 ] Stefan Bodewig commented on COMPRESS-311: - This might lead to Commons Compress creating archives by default that are unreadable by some implementations. File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-311) File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement.
[ https://issues.apache.org/jira/browse/COMPRESS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14359176#comment-14359176 ] Stefan Bodewig commented on COMPRESS-311: - Sorry Darpan, but the snippet really isn't long enough to tell what may be going wrong. The value you set via setLongFileMode is used for all entries you add after setting it and there are test cases that show it is working. If it fails for you, can you provide a small test case that exhibits the problem? File Name too long (100 bytes) when trying to create a Tar,and I cn not reduce file name as per my requirement. Key: COMPRESS-311 URL: https://issues.apache.org/jira/browse/COMPRESS-311 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.9 Reporter: DARPAN KAUSHIK -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1094) Javadoc is not encoding spaces correctly
Duncan Jones created LANG-1094:
--
Summary: Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
Fix For: Patch Needed
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to link
to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1093) Add ClassUtils.getAbbreviatedName
[
https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358608#comment-14358608
]
Benedikt Ritter commented on LANG-1093:
---
Hello Fabian,
bq. On the other hand I thought, if its inspired by the quirky API, then I
could keep also that edge case?
Now is our chance to resolve the quirkiness ;-) If a user only wants the class
name without any package information, she can use {{getShortClassName}}. So
{{len = 0 - IAE}}?
bq. The null cause is covered the same way as the other methds do it by
saying or an empty string for return.
Yes, and I agree with that behavior. I only would like to see this case show up
in the JavaDoc table of examples.
Add ClassUtils.getAbbreviatedName
-
Key: LANG-1093
URL: https://issues.apache.org/jira/browse/LANG-1093
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Fabian Lange
Labels: github
Fix For: Review Patch
It would be really nice to have a class name shortener functionality
available similar to what some logger frameworks use.
I took the idea for my implementation from logback, including the quirky
treatment of the desired length argument, feel free to discuss on the PR/here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1093) Add ClassUtils.getAbbreviatedName
[ https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358610#comment-14358610 ] Fabian Lange commented on LANG-1093: its still quirky in the sense that len is just a guide for the code. but i think ill do the IAE for 0 as well. Thanks for the feedback. Add ClassUtils.getAbbreviatedName - Key: LANG-1093 URL: https://issues.apache.org/jira/browse/LANG-1093 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Fabian Lange Labels: github Fix For: Review Patch It would be really nice to have a class name shortener functionality available similar to what some logger frameworks use. I took the idea for my implementation from logback, including the quirky treatment of the desired length argument, feel free to discuss on the PR/here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1093) Add ClassUtils.getAbbreviatedName
Fabian Lange created LANG-1093: -- Summary: Add ClassUtils.getAbbreviatedName Key: LANG-1093 URL: https://issues.apache.org/jira/browse/LANG-1093 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Fabian Lange It would be really nice to have a class name shortener functionality available similar to what some logger frameworks use. I took the idea for my implementation from logback, including the quirky treatment of the desired length argument, feel free to discuss on the PR/here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1093) Add ClassUtils.getAbbreviatedName
[
https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358568#comment-14358568
]
Benedikt Ritter commented on LANG-1093:
---
Very nice patch overall. Just two points I'd like to talk about:
* How should negative values for {{len}} be handled? Currently we have
{{ClassUtils.getAbbreviatedName(String.class, -1) == j.l.String}} but
{{ClassUtils.getAbbreviatedName(String.class, 0) == String}}. Feels like we
should throw IAE for negativ values.
* It's good to document corner cases as well, so that users don't have to try
out themself. For example {{ClassUtils.getAbbreviatedName((ClassObject) null,
10) == }} could be documented. And of corse the behavior for negativ values.
Add ClassUtils.getAbbreviatedName
-
Key: LANG-1093
URL: https://issues.apache.org/jira/browse/LANG-1093
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Fabian Lange
Labels: github
Fix For: Review Patch
It would be really nice to have a class name shortener functionality
available similar to what some logger frameworks use.
I took the idea for my implementation from logback, including the quirky
treatment of the desired length argument, feel free to discuss on the PR/here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1093) Add ClassUtils.getAbbreviatedName
[ https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358585#comment-14358585 ] Fabian Lange commented on LANG-1093: Thanks for the feedback, I actually considered even dropping the 0 len case. Because we have a dedicated API for that. On the other hand I thought, if its inspired by the quirky API, then I could keep also that edge case? The null cause is covered the same way as the other methds do it by saying or an empty string for return. Add ClassUtils.getAbbreviatedName - Key: LANG-1093 URL: https://issues.apache.org/jira/browse/LANG-1093 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Fabian Lange Labels: github Fix For: Review Patch It would be really nice to have a class name shortener functionality available similar to what some logger frameworks use. I took the idea for my implementation from logback, including the quirky treatment of the desired length argument, feel free to discuss on the PR/here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1093) Add ClassUtils.getAbbreviatedName
[ https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1093: -- Labels: github (was: ) Add ClassUtils.getAbbreviatedName - Key: LANG-1093 URL: https://issues.apache.org/jira/browse/LANG-1093 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Fabian Lange Labels: github Fix For: Review Patch It would be really nice to have a class name shortener functionality available similar to what some logger frameworks use. I took the idea for my implementation from logback, including the quirky treatment of the desired length argument, feel free to discuss on the PR/here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1093) Add ClassUtils.getAbbreviatedName
[ https://issues.apache.org/jira/browse/LANG-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1093: -- Fix Version/s: Review Patch Add ClassUtils.getAbbreviatedName - Key: LANG-1093 URL: https://issues.apache.org/jira/browse/LANG-1093 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Fabian Lange Labels: github Fix For: Review Patch It would be really nice to have a class name shortener functionality available similar to what some logger frameworks use. I took the idea for my implementation from logback, including the quirky treatment of the desired length argument, feel free to discuss on the PR/here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VALIDATOR-360) EmailValidator does not catch invalid email address like dora@.com
Dora Kinghorn created VALIDATOR-360: --- Summary: EmailValidator does not catch invalid email address like dora@.com Key: VALIDATOR-360 URL: https://issues.apache.org/jira/browse/VALIDATOR-360 Project: Commons Validator Issue Type: Bug Components: Framework, Routines Affects Versions: 1.4.1 Release Environment: java 1.7 Reporter: Dora Kinghorn EmailValidator does not catch invalid email address like dora@.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
