[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103512#comment-14103512 ] Romain Manni-Bucau commented on JCS-122: Slf4j will work but doesn't help making logging not consistent (if we are able to get rid of sl4j in tomee we would be very happy). Since we own the code we should be able to allow to switch the facade). Nothing preventing a 2.0 BTW. > rework logging? > --- > > Key: JCS-122 > URL: https://issues.apache.org/jira/browse/JCS-122 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau > Fix For: jcs-2.0.0 > > > currently JCS relies on [logging] > Would be great to get rid of this dependency. > Solutions I see: > 1) use JUL (with extensibility like in > http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) > 2) write a little factory with a jcs.Logger to be able to switch > Goal is to be able to adapt to frameworks and users. Guess first will be > often JUL (TomEE), second SLF4J, [logging]... > I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (COMPRESS-286) Error while expanding 7z java.io.EOFException
[ https://issues.apache.org/jira/browse/COMPRESS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-286: Fix Version/s: 1.9 > Error while expanding 7z java.io.EOFException > - > > Key: COMPRESS-286 > URL: https://issues.apache.org/jira/browse/COMPRESS-286 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.8, 1.8.1 > Environment: Windows8, Java6 >Reporter: Greg Domjan > Labels: 7z, XZ, ant, maven2, newbie > Fix For: 1.9 > > > Using 7zip (9.2) able to extract these downloaded files > http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_Dev.7z > http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_ReleaseDLL.7z > Commons-compress 1.6 had issues with these files that seemed related to > COMPRESS-257 so tried to use 1.8 as identified fixed in version. Some issues > where fixed. > Using maven + antrun > > > maven-antrun-plugin > 1.7 > > > > ant-contrib > > ant-contrib > 1.0b3 > > > > ant > > ant > > > > > > org.apache.ant > > ant-nodeps > 1.8.1 > > > > org.apache.commons > > commons-compress > 1.8 > > > > org.apache.ant > > ant-compress > 1.4 > > > Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant > BuildException has occured: Error while expanding > Z:\download\wxMSW-3.0.0_vc120_Dev.7z > java.io.EOFException > around Ant part ... c="z:\download/wxMSW-3.0.0_vc120_Dev.7z"/>... @ 26:237 in > C:\target\antrun\build-download.xml > at > org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:355) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > ... 17 more > Caused by: c:\target\antrun\build-download.xml:26: Error while expand > ing c:\download\wxMSW-3.0.0_vc120_Dev.7z > java.io.EOFException > at org.apache.ant.compress.taskdefs.Un7z.expandFile(Un7z.java:92) > at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:132) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:390) > at org.apache.tools.ant.Target.performTasks(Target.java:411) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at org.apache.tools.ant.Project.executeTarget(Project.java:1368) > at > org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327) > ... 19 more > Caused by: java.io.EOFException > at java.io.DataInputStream.readU
[jira] [Commented] (COMPRESS-286) Error while expanding 7z java.io.EOFException
[ https://issues.apache.org/jira/browse/COMPRESS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103406#comment-14103406 ] Stefan Bodewig commented on COMPRESS-286: - Thanks to Lasse Collin I now know where the problem is (for LZMA streams we need to pass the uncompressed size to the constructor). We'll need to modify some internal APIs, but it at least we now know how to fix it. > Error while expanding 7z java.io.EOFException > - > > Key: COMPRESS-286 > URL: https://issues.apache.org/jira/browse/COMPRESS-286 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.8, 1.8.1 > Environment: Windows8, Java6 >Reporter: Greg Domjan > Labels: 7z, XZ, ant, maven2, newbie > Fix For: 1.9 > > > Using 7zip (9.2) able to extract these downloaded files > http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_Dev.7z > http://downloads.sourceforge.net/sourceforge/wxwindows/3.0.0/binaries/wxMSW-3.0.0_vc120_ReleaseDLL.7z > Commons-compress 1.6 had issues with these files that seemed related to > COMPRESS-257 so tried to use 1.8 as identified fixed in version. Some issues > where fixed. > Using maven + antrun > > > maven-antrun-plugin > 1.7 > > > > ant-contrib > > ant-contrib > 1.0b3 > > > > ant > > ant > > > > > > org.apache.ant > > ant-nodeps > 1.8.1 > > > > org.apache.commons > > commons-compress > 1.8 > > > > org.apache.ant > > ant-compress > 1.4 > > > Caused by: org.apache.maven.plugin.MojoExecutionException: An Ant > BuildException has occured: Error while expanding > Z:\download\wxMSW-3.0.0_vc120_Dev.7z > java.io.EOFException > around Ant part ... c="z:\download/wxMSW-3.0.0_vc120_Dev.7z"/>... @ 26:237 in > C:\target\antrun\build-download.xml > at > org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:355) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > ... 17 more > Caused by: c:\target\antrun\build-download.xml:26: Error while expand > ing c:\download\wxMSW-3.0.0_vc120_Dev.7z > java.io.EOFException > at org.apache.ant.compress.taskdefs.Un7z.expandFile(Un7z.java:92) > at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:132) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:390) > at org.apache.tools.ant.Target.performTasks(Target.java:411) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) >
[jira] [Commented] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103379#comment-14103379 ] Yogesh Rao commented on JCS-122: Any particular reason SLF4J wouldnt work in tomee ? Hope i am not missing anything. > rework logging? > --- > > Key: JCS-122 > URL: https://issues.apache.org/jira/browse/JCS-122 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau > Fix For: jcs-2.0.0 > > > currently JCS relies on [logging] > Would be great to get rid of this dependency. > Solutions I see: > 1) use JUL (with extensibility like in > http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) > 2) write a little factory with a jcs.Logger to be able to switch > Goal is to be able to adapt to frameworks and users. Guess first will be > often JUL (TomEE), second SLF4J, [logging]... > I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCS-133) RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly
[ https://issues.apache.org/jira/browse/JCS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-133. Resolution: Fixed Assignee: Thomas Vandahl Fixed by Sebb in SVN. Thanks for the fix. > RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly > > > Key: JCS-133 > URL: https://issues.apache.org/jira/browse/JCS-133 > Project: Commons JCS > Issue Type: Bug >Reporter: Sebb >Assignee: Thomas Vandahl > Fix For: jcs-2.0.0 > > > The RemoteUtils.getNamingURL method does the following concatenation to > produce the result: > "//" + registryHost + ":" + registryPort + "/" + serviceName; > This works fine for host names and IPv4, but does not work for literal IPv6 > addresses which have to be enclosed in [ and ] > A crude way to fix this would be to look for ":" in the registryHost string. > If present, the zone index identifier (%2 or %eth0) needs to be encoded > because the % is special. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCS-133) RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly
[ https://issues.apache.org/jira/browse/JCS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102619#comment-14102619 ] Thomas Vandahl commented on JCS-133: An alternative would be to try to resolve the address and see if it is a IPv6 address. That, however, might trigger DNS timeouts (30 sec), which should be avoided IMO. I'm fine with the fix. > RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly > > > Key: JCS-133 > URL: https://issues.apache.org/jira/browse/JCS-133 > Project: Commons JCS > Issue Type: Bug >Reporter: Sebb > Fix For: jcs-2.0.0 > > > The RemoteUtils.getNamingURL method does the following concatenation to > produce the result: > "//" + registryHost + ":" + registryPort + "/" + serviceName; > This works fine for host names and IPv4, but does not work for literal IPv6 > addresses which have to be enclosed in [ and ] > A crude way to fix this would be to look for ":" in the registryHost string. > If present, the zone index identifier (%2 or %eth0) needs to be encoded > because the % is special. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-119) replace synchronized blocks by java locks or concurrenhashmap
[ https://issues.apache.org/jira/browse/JCS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-119: --- Fix Version/s: jcs-2.0.0 > replace synchronized blocks by java locks or concurrenhashmap > - > > Key: JCS-119 > URL: https://issues.apache.org/jira/browse/JCS-119 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau > Fix For: jcs-2.0.0 > > > A cache is typically used in a concurrent environment. Since Java 6 using a > ReentrantLock is faster than synchronized so can be interesting to replace > synchronized blocks by a lock. > Places i'm thinking about: > * CompositeCache > * AbstractDoubleLinkedListMemoryCache > * LHMLRUMemoryCache > * DoubleLinkedList > * LRUMap > * SingleLinkedList > * SortedPreferentialArray > Some places where replacing a HashMap by a ConcurrentHashMap can allow to get > rid of synchronized without needing a lock: > * CacheEventQueue > * AbstractDiskCache > * CacheWatchRepairable > There are other places but this is the main I saw. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-122) rework logging?
[ https://issues.apache.org/jira/browse/JCS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-122: --- Fix Version/s: jcs-2.0.0 > rework logging? > --- > > Key: JCS-122 > URL: https://issues.apache.org/jira/browse/JCS-122 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau > Fix For: jcs-2.0.0 > > > currently JCS relies on [logging] > Would be great to get rid of this dependency. > Solutions I see: > 1) use JUL (with extensibility like in > http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/) > 2) write a little factory with a jcs.Logger to be able to switch > Goal is to be able to adapt to frameworks and users. Guess first will be > often JUL (TomEE), second SLF4J, [logging]... > I'm for 1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-132) EnsureCDIIsTestedWhenTCKsRunTest fails on Java 1.6
[ https://issues.apache.org/jira/browse/JCS-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-132: --- Fix Version/s: jcs-2.0.0 > EnsureCDIIsTestedWhenTCKsRunTest fails on Java 1.6 > -- > > Key: JCS-132 > URL: https://issues.apache.org/jira/browse/JCS-132 > Project: Commons JCS > Issue Type: Bug >Reporter: Sebb > Fix For: jcs-2.0.0 > > > EnsureCDIIsTestedWhenTCKsRunTest fails on Java 1.6 because it tries to load > javax.cache.annotation.BeanProvider.class > Unfortunately the jar in which is is contained appears to have been built for > Java 1.7 (unlike the rest of the javax jars). > Some possible workrounds: > - use a different class if there is another that is suitable > - get the providers to release a version that works for Java 1.6 > - catch the failure, and convert it to a warning on Java 1.6 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-133) RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly
[ https://issues.apache.org/jira/browse/JCS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-133: --- Fix Version/s: jcs-2.0.0 > RemoteUtils.getNamingURL does not handle IPv6 numeric addresses properly > > > Key: JCS-133 > URL: https://issues.apache.org/jira/browse/JCS-133 > Project: Commons JCS > Issue Type: Bug >Reporter: Sebb > Fix For: jcs-2.0.0 > > > The RemoteUtils.getNamingURL method does the following concatenation to > produce the result: > "//" + registryHost + ":" + registryPort + "/" + serviceName; > This works fine for host names and IPv4, but does not work for literal IPv6 > addresses which have to be enclosed in [ and ] > A crude way to fix this would be to look for ":" in the registryHost string. > If present, the zone index identifier (%2 or %eth0) needs to be encoded > because the % is special. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCS-116) CompositeCacheManager is thread-hostile
[ https://issues.apache.org/jira/browse/JCS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-116: --- Fix Version/s: jcs-2.0.0 > CompositeCacheManager is thread-hostile > --- > > Key: JCS-116 > URL: https://issues.apache.org/jira/browse/JCS-116 > Project: Commons JCS > Issue Type: Bug >Reporter: Sebb >Priority: Blocker > Fix For: jcs-2.0.0 > > > The CompositeCacheManager class is a singleton. However it is not immutable, > so is inherently thread-hostile. > The class does take some steps to prevent reconfiguration, but it still > allows changes to variables such as defaultCacheAttr that affect instance > methods such as getCache(String) > This makes it very easy to accidentally affect other threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (LANG-965) FieldUtils methods leak accessible flags
[ https://issues.apache.org/jira/browse/LANG-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andre Diermann updated LANG-965: Attachment: commons-lang-965.patch The attached patch tries so solve the mentioned accessibility leak by restoring the original accessibility of a particular field in case it has been modified by readField/writeField. > FieldUtils methods leak accessible flags > > > Key: LANG-965 > URL: https://issues.apache.org/jira/browse/LANG-965 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.1, 3.2.1 > Environment: Apache Maven 3.1.1 > (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) > Maven home: C:\Java\apache-maven-3.1.1\bin\.. > Java version: 1.7.0_51, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_51\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: Patch Needed > > Attachments: commons-lang-965.patch > > > When various FieldUtils methods are called the accessible is set to true but > never reset to false. This is side-effect should be cleaned up. > This makes a mess of the object model which represents the class meta data. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VALIDATOR-340) Add new TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102351#comment-14102351
]
Adrian Crum commented on VALIDATOR-340:
---
A suggestion I made in one of the (many) duplicate issues is to make TLD
validation optional. As one reporter commented, a perfectly valid local domain
will fail validation.
> Add new TLDs
>
>
> Key: VALIDATOR-340
> URL: https://issues.apache.org/jira/browse/VALIDATOR-340
> Project: Commons Validator
> Issue Type: Improvement
> Components: Framework
>Affects Versions: 1.4.0 Release
> Environment: Live
>Reporter: Ken Montgomery
> Labels: TLD, domains, email
> Fix For: 1.4.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The current commons-validator-1.4.0.jar does not include any domains released
> after 2012.
> org.apache.commons.validator.routines.EmailValidator;
> Then on to the method isValidGenericTld(tld)
> Which uses the list
> private static final String[] GENERIC_TLDS = new String[] {
> "aero", // air transport industry
> "asia", // Pan-Asia/Asia Pacific
> "biz", // businesses
> "cat", // Catalan linguistic/cultural community
> "com", // commercial enterprises
> "coop", // cooperative associations
> "info", // informational sites
> "jobs", // Human Resource managers
> "mobi", // mobile products and services
> "museum", // museums, surprisingly enough
> "name", // individuals' sites
> "net", // internet support infrastructure/business
> "org", // noncommercial organizations
> "pro", // credentialed professionals and entities
> "tel", // contact data for businesses and individuals
> "travel", // entities in the travel industry
> "gov", // United States Government
> "edu", // accredited postsecondary US education entities
> "mil", // United States Military
> "int" // organizations established by international treaty
> };
> This list does not include any of the new domains. They are therefore seen as
> invalid.
> See New Domains (about 300)
> http://newgtlds.icann.org/en/program-status/delegated-strings
> From http://commons.apache.org/proper/commons-validator/changes-report.html
> I can see that version 1.4.0 is the current version even though it was
> released on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102299#comment-14102299 ] Michael Osipov edited comment on POOL-266 at 8/19/14 3:10 PM: -- bq. This is not the place to re-hash the "which logging framework is better" debate. I agree on that. Maybe everyone could live with a log chute like Velocity does. was (Author: michael-o): bq. This is not the place to re-hash the "which logging framework is better" debate. I agree on that. Maybe everyone could live with a log chute like Velocity uses. > Common Pool does not use log api > > > Key: POOL-266 > URL: https://issues.apache.org/jira/browse/POOL-266 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier > > Common pool does not use log api (logback,slf4j, log4j, log4j2, commons > logging,...). Errors are printed directly with System.out or System.err. So > it's difficult to have information in the same log file as other application > log file. > Is there any reason to not use log api ? > If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VALIDATOR-340) Add new TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102294#comment-14102294
]
Ken Montgomery commented on VALIDATOR-340:
--
Thank you for your email.
I will be out of the office on Wednesday 20/08/2014 returning on Thursday
21/08/2014.
If you require a more immediate response please email
dlhqapdmapplicationsupp...@auspost.com.au
Regards
Ken Montgomery
Application Support Manager
Australia Post Digital Mailbox
Level 1/136 Exhibition Street, Melbourne VIC 3000
> Add new TLDs
>
>
> Key: VALIDATOR-340
> URL: https://issues.apache.org/jira/browse/VALIDATOR-340
> Project: Commons Validator
> Issue Type: Improvement
> Components: Framework
>Affects Versions: 1.4.0 Release
> Environment: Live
>Reporter: Ken Montgomery
> Labels: TLD, domains, email
> Fix For: 1.4.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The current commons-validator-1.4.0.jar does not include any domains released
> after 2012.
> org.apache.commons.validator.routines.EmailValidator;
> Then on to the method isValidGenericTld(tld)
> Which uses the list
> private static final String[] GENERIC_TLDS = new String[] {
> "aero", // air transport industry
> "asia", // Pan-Asia/Asia Pacific
> "biz", // businesses
> "cat", // Catalan linguistic/cultural community
> "com", // commercial enterprises
> "coop", // cooperative associations
> "info", // informational sites
> "jobs", // Human Resource managers
> "mobi", // mobile products and services
> "museum", // museums, surprisingly enough
> "name", // individuals' sites
> "net", // internet support infrastructure/business
> "org", // noncommercial organizations
> "pro", // credentialed professionals and entities
> "tel", // contact data for businesses and individuals
> "travel", // entities in the travel industry
> "gov", // United States Government
> "edu", // accredited postsecondary US education entities
> "mil", // United States Military
> "int" // organizations established by international treaty
> };
> This list does not include any of the new domains. They are therefore seen as
> invalid.
> See New Domains (about 300)
> http://newgtlds.icann.org/en/program-status/delegated-strings
> From http://commons.apache.org/proper/commons-validator/changes-report.html
> I can see that version 1.4.0 is the current version even though it was
> released on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102299#comment-14102299 ] Michael Osipov commented on POOL-266: - bq. This is not the place to re-hash the "which logging framework is better" debate. I agree on that. Maybe everyone could live with a log chute like Velocity uses. > Common Pool does not use log api > > > Key: POOL-266 > URL: https://issues.apache.org/jira/browse/POOL-266 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier > > Common pool does not use log api (logback,slf4j, log4j, log4j2, commons > logging,...). Errors are printed directly with System.out or System.err. So > it's difficult to have information in the same log file as other application > log file. > Is there any reason to not use log api ? > If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (VALIDATOR-340) Add new TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102286#comment-14102286
]
Sebb commented on VALIDATOR-340:
It might make sense to provide the TLDs as a resource file, rather than
embedding the strings as constants.
[Likewise for the country codes, though these change less frequently]
This could allow users to replace the file if necessary without needing to
download a new version of the code.
A crude way to do this would be to replace the resource file in the jar.
It would be better if the user could provide a resource file with any required
additions.
Not sure if there is a use-case for dropping TLDs.
Note that EmailValidator now uses DomainValidator to check the domain string.
> Add new TLDs
>
>
> Key: VALIDATOR-340
> URL: https://issues.apache.org/jira/browse/VALIDATOR-340
> Project: Commons Validator
> Issue Type: Improvement
> Components: Framework
>Affects Versions: 1.4.0 Release
> Environment: Live
>Reporter: Ken Montgomery
> Labels: TLD, domains, email
> Fix For: 1.4.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The current commons-validator-1.4.0.jar does not include any domains released
> after 2012.
> org.apache.commons.validator.routines.EmailValidator;
> Then on to the method isValidGenericTld(tld)
> Which uses the list
> private static final String[] GENERIC_TLDS = new String[] {
> "aero", // air transport industry
> "asia", // Pan-Asia/Asia Pacific
> "biz", // businesses
> "cat", // Catalan linguistic/cultural community
> "com", // commercial enterprises
> "coop", // cooperative associations
> "info", // informational sites
> "jobs", // Human Resource managers
> "mobi", // mobile products and services
> "museum", // museums, surprisingly enough
> "name", // individuals' sites
> "net", // internet support infrastructure/business
> "org", // noncommercial organizations
> "pro", // credentialed professionals and entities
> "tel", // contact data for businesses and individuals
> "travel", // entities in the travel industry
> "gov", // United States Government
> "edu", // accredited postsecondary US education entities
> "mil", // United States Military
> "int" // organizations established by international treaty
> };
> This list does not include any of the new domains. They are therefore seen as
> invalid.
> See New Domains (about 300)
> http://newgtlds.icann.org/en/program-status/delegated-strings
> From http://commons.apache.org/proper/commons-validator/changes-report.html
> I can see that version 1.4.0 is the current version even though it was
> released on 2012-02-03
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (POOL-267) Use of AbandonListener instead of PrintWriter when a pool object is detected in an abandon state
[ https://issues.apache.org/jira/browse/POOL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102035#comment-14102035 ] Mark Thomas commented on POOL-267: -- Just something to think about. We might want to make the listener more generic in case there are other events we want to raise in the future. > Use of AbandonListener instead of PrintWriter when a pool object is detected > in an abandon state > > > Key: POOL-267 > URL: https://issues.apache.org/jira/browse/POOL-267 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier > Attachments: AbandonedListenerPatch.diff > > > I would be great to have a more flexible mecanism for abandon detection. > Having just a PrintWriter is too restrictive. With an AbandonListener it > would be possible to make more things like using log API or enabling > supervision of application. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14102031#comment-14102031 ] Mark Thomas commented on POOL-266: -- This is not the place to re-hash the "which logging framework is better" debate. I would also add that points made in a civil tone are far more likely to be listened to than those in a hostile tone. A quick code review shows one use of stderr which looks entirely appropriate. In an OOME situation writing directly to stderr is more likely to succeed than writing via a framework. The only use of stdout is for the abandonded logging which is covered by POOL-267. +1 to everything Phil said. Absent a good reason to add a dependency (and I haven't seen one so far) this issue is going to get resolved as WONTFIX. > Common Pool does not use log api > > > Key: POOL-266 > URL: https://issues.apache.org/jira/browse/POOL-266 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier > > Common pool does not use log api (logback,slf4j, log4j, log4j2, commons > logging,...). Errors are printed directly with System.out or System.err. So > it's difficult to have information in the same log file as other application > log file. > Is there any reason to not use log api ? > If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (POOL-266) Common Pool does not use log api
[ https://issues.apache.org/jira/browse/POOL-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101989#comment-14101989 ] Michael Osipov commented on POOL-266: - JDK logger is the same crap as Commons Logging. You gain nothing by using the JDK logger. > Common Pool does not use log api > > > Key: POOL-266 > URL: https://issues.apache.org/jira/browse/POOL-266 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier > > Common pool does not use log api (logback,slf4j, log4j, log4j2, commons > logging,...). Errors are printed directly with System.out or System.err. So > it's difficult to have information in the same log file as other application > log file. > Is there any reason to not use log api ? > If you are interested I can do a patch with the usage of logback API. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (POOL-269) Specialize useless throws Exception
[
https://issues.apache.org/jira/browse/POOL-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101958#comment-14101958
]
Michael Osipov commented on POOL-269:
-
Looks actually good. About source compat, this can be changed with 2.3 (minor).
What do you think?
> Specialize useless throws Exception
> ---
>
> Key: POOL-269
> URL: https://issues.apache.org/jira/browse/POOL-269
> Project: Commons Pool
> Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Michael Osipov
>
> Too many methods say {{throws Exception}} in their signature. This is neither
> helpful nor good API design. You never know what the exception is and where
> it came from.
> An exception translation pattern has to be applied to make code usable, e.g.,
> like the Spring project does or Maven with {{BuildException}}.
> Unfortunately, this ugly practive has prevailed in several Apache projects
> like Lucene.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
