[GitHub] commons-lang pull request #345: add jvmLaunchers
Github user harbby closed the pull request at: https://github.com/apache/commons-lang/pull/345 ---
[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPool's
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691255#comment-16691255
]
ASF GitHub Bot commented on POOL-359:
-
Github user grimreaper commented on the issue:
https://github.com/apache/commons-pool/pull/17
Works for me. Blocked on INFRA-17267
travis fails for unrelated reasons, but tests pass locally:
```
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 05:45 min
[INFO] Finished at: 2018-11-18T20:54:44-08:00
[INFO]
```
> NullPointerException closing multiple GenericObjectPool's
> -
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPool's
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691246#comment-16691246
]
ASF GitHub Bot commented on POOL-359:
-
Github user mswintermeyer commented on the issue:
https://github.com/apache/commons-pool/pull/17
If `cancel` should not be called more than once, then I believe that would
require a greater re-architecture. `GenericObjectPool`'s would need to keep
track of whether another object pool called `cancel`: to rely on something
other than non-static state (`closed` variable on `BaseGenericObjectPool`) to
call a static method. To me, it seems cleanest for static methods to be
designed defensively. So I'm not aware of a reason to not allow this, but I
acknowledge I'm new to the codebase.
Side note that the risk of an NPE in `cancel` seems somewhat new. [This
commit](https://github.com/apache/commons-pool/commit/867614829ba6b041ca6becbad0f43cb180003404#diff-38e254894b87bdf9a1758778c7ffd50fL96)
refactored `EvictionTimer` to depend on the executor's queue rather than an
integer `usageCount`.
> NullPointerException closing multiple GenericObjectPool's
> -
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-471) Zipped files names having non UTF-8 encoding are being replaced with '?' while previewing file.
[
https://issues.apache.org/jira/browse/COMPRESS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691230#comment-16691230
]
Gaurav Mittal commented on COMPRESS-471:
We are concerned about cases where we do not need to apply CP850 encoding but
still we are applying and then files names can contain undesirable characters.
query:
Is there any way we can know that some particular zip file contains non-UTF8
characters in file name and if yes, we can handle at application level.
Currently I do not see any method that can tell me about non-UTF8 characters
and hence we are not able to decide when to apply UTF8 and when to apply other
character encoding.
Is it possible to fix it from library side?
Thanks
> Zipped files names having non UTF-8 encoding are being replaced with '?'
> while previewing file.
> ---
>
> Key: COMPRESS-471
> URL: https://issues.apache.org/jira/browse/COMPRESS-471
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Gaurav Mittal
>Priority: Major
> Attachments: Document(▒Γ║╗)_20150226_11.zip, Incorrect.JPG,
> correct.JPG
>
>
> | * All the strings which are not supported by UTF-8 are being replaced by
> '?' symbol,
> In the issue scenario the charset is 'Cp850', Since the common compress
> library cannot identify the 'Cp850' charset and it takes the default charset
> as 'UTF-8' therefore
> we can see the '?' symbol
> In our code
> ZipFile ret = new ZipFile(path);
> Moreover if we send the encoding in the function as defined below, it works
> fine
> ZipFile ret = new ZipFile(new File(path), "Cp850",false);
> But the second scenario where we are forcibly giving the encoding as 'Cp850'
> may cause side effects in some cases
> --
> Below code does not seem to resolve UTF8 conflicts and could not make file
> names into correct form -
>
> try {
> final Map entriesWithoutUTF8Flag =
> populateFromCentralDirectory();
> resolveLocalFileHeaderData(entriesWithoutUTF8Flag);
> success = true;
> } finally {
> closed = !success;
> if (!success && closeOnError) {
> IOUtils.closeQuietly(archive);
> }
> }|
> | |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-731) Allow user to specify the comments & separator chars
[ https://issues.apache.org/jira/browse/CONFIGURATION-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691199#comment-16691199 ] Shuai Zhang commented on CONFIGURATION-731: --- [~garydgregory] Good point! I submitted new patch for it. BTW, I've got a few questions: # Is there any tool help check Java binary compatibility? It's quite helpful to keep it for providing a patched version of existing JAR. # Is there suggested way to provide a patch? I made it through both patch file here & git PR [https://github.com/apache/commons-configuration/pull/16] # It seems that the Github repository didn't fully syncronized with our SVN repo? > Allow user to specify the comments & separator chars > > > Key: CONFIGURATION-731 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-731 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.4 >Reporter: Shuai Zhang >Priority: Major > Attachments: CONFIGURATION-731.001.patch, CONFIGURATION-731.002.patch > > > Currently the INIConfiguration defined comments & separator chars as final > static fields, which made it impossible for the user control the behavior of > INIConfiguration parsing. I suggest making them as default value, open setter > & getter methods for the comment & separator chars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CONFIGURATION-731) Allow user to specify the comments & separator chars
[ https://issues.apache.org/jira/browse/CONFIGURATION-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuai Zhang updated CONFIGURATION-731: -- Attachment: CONFIGURATION-731.002.patch > Allow user to specify the comments & separator chars > > > Key: CONFIGURATION-731 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-731 > Project: Commons Configuration > Issue Type: Improvement > Components: Format >Affects Versions: 2.4 >Reporter: Shuai Zhang >Priority: Major > Attachments: CONFIGURATION-731.001.patch, CONFIGURATION-731.002.patch > > > Currently the INIConfiguration defined comments & separator chars as final > static fields, which made it impossible for the user control the behavior of > INIConfiguration parsing. I suggest making them as default value, open setter > & getter methods for the comment & separator chars. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DBCP-529) Add 'jmxName' property to web Configuration Parameters listing
[
https://issues.apache.org/jira/browse/DBCP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691037#comment-16691037
]
Gary Gregory commented on DBCP-529:
---
Patches are welcome on GitHub ;)
> Add 'jmxName' property to web Configuration Parameters listing
> --
>
> Key: DBCP-529
> URL: https://issues.apache.org/jira/browse/DBCP-529
> Project: Commons DBCP
> Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Yuri
>Priority: Minor
> Labels: JMX, documentation, website
>
> The {{jmxName}} property is clearly available for {{BasicDataSourceFactory}}
> although it is omitted from [the web
> listing|https://commons.apache.org/proper/commons-dbcp/configuration.html].
> Enabled JMX is a huge win for observability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COMPRESS-470) ParallelScatterZipCreator leaks temporary files (and maybe more)
[
https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-470.
-
Resolution: Fixed
Fix Version/s: 1.19
I've added code that ensures the streams get closed - and that extra effort is
spent on getting rid temporary files.
The later won't help with your case of very long running processes, for those
something like the implementation you've shared in
https://issues.apache.org/jira/browse/COMPRESS-446?focusedCommentId=16684043=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16684043
is the better option. Many thanks for that!
> ParallelScatterZipCreator leaks temporary files (and maybe more)
>
>
> Key: COMPRESS-470
> URL: https://issues.apache.org/jira/browse/COMPRESS-470
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
> Fix For: 1.19
>
>
> As indicated by
> https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679878#comment-16679878
> COMPRESS-446 may have closed one resource leak but not all of them.
> If an exception occurs in {{writeTo}} we may miss calling {{close}} on some
> of the {{ScatterZipOutputStream}}s which in turn may leak resources like
> temporary files opened by using {{FileBasedScatterGatherBackingStore}}.
> This affects all versions since 1.10
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-471) Zipped files names having non UTF-8 encoding are being replaced with '?' while previewing file.
[
https://issues.apache.org/jira/browse/COMPRESS-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690912#comment-16690912
]
Stefan Bodewig commented on COMPRESS-471:
-
I'm sorry, can you please explain what kind of "side effects" you see?
When I iterate over the names after using {{ZipFile(new File(...), "Cp850")}} I
see names that don't contain any question marks.
> Zipped files names having non UTF-8 encoding are being replaced with '?'
> while previewing file.
> ---
>
> Key: COMPRESS-471
> URL: https://issues.apache.org/jira/browse/COMPRESS-471
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Gaurav Mittal
>Priority: Major
> Attachments: Document(▒Γ║╗)_20150226_11.zip, Incorrect.JPG,
> correct.JPG
>
>
> | * All the strings which are not supported by UTF-8 are being replaced by
> '?' symbol,
> In the issue scenario the charset is 'Cp850', Since the common compress
> library cannot identify the 'Cp850' charset and it takes the default charset
> as 'UTF-8' therefore
> we can see the '?' symbol
> In our code
> ZipFile ret = new ZipFile(path);
> Moreover if we send the encoding in the function as defined below, it works
> fine
> ZipFile ret = new ZipFile(new File(path), "Cp850",false);
> But the second scenario where we are forcibly giving the encoding as 'Cp850'
> may cause side effects in some cases
> --
> Below code does not seem to resolve UTF8 conflicts and could not make file
> names into correct form -
>
> try {
> final Map entriesWithoutUTF8Flag =
> populateFromCentralDirectory();
> resolveLocalFileHeaderData(entriesWithoutUTF8Flag);
> success = true;
> } finally {
> closed = !success;
> if (!success && closeOnError) {
> IOUtils.closeQuietly(archive);
> }
> }|
> | |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #345: add jvmLaunchers
Github user harbby commented on the issue: https://github.com/apache/commons-lang/pull/345 Hi all, After a long time, we practiced in many projects, we found pr very interesting, I plan to close this discussion, discuss in commons-exec ---
[jira] [Closed] (DBCP-530) Can Not Collect Database Connection Pooling metrics In JMX
[ https://issues.apache.org/jira/browse/DBCP-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haven Lin closed DBCP-530. -- Resolution: Invalid > Can Not Collect Database Connection Pooling metrics In JMX > -- > > Key: DBCP-530 > URL: https://issues.apache.org/jira/browse/DBCP-530 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1, 2.4.0 >Reporter: Haven Lin >Priority: Minor > Labels: usability > > *Background:* > Our project used org.apache.commons::commons-dbcp2:2.1.1 for collecting > Database Connection Pooling metrics, and publish metrics from JMX to StatsD > server > After we changed version from 2.1.1 to 2.4.0, we can see Database Connection > pool metrics are in JMX MBeans list, but all of Database Connection pool > metrics are *NULL* value. > > *Impact:* > It will caused we can not collect metrics from Database Connection Pooling. > > May I get helps to investigate this problem? > > Any suggestion/question please feel free to let me know. > > Thanks, > Haven > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DBCP-530) Can Not Collect Database Connection Pooling metrics In JMX
[ https://issues.apache.org/jira/browse/DBCP-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haven Lin updated DBCP-530: --- Description: *Background:* Our project used org.apache.commons::commons-dbcp2:2.1.1 for collecting Database Connection Pooling metrics, and publish metrics from JMX to StatsD server After we changed version from 2.1.1 to 2.4.0, we can see Database Connection pool metrics are in JMX MBeans list, but all of Database Connection pool metrics are *NULL* value. *Impact:* It will caused we can not collect metrics from Database Connection Pooling. May I get helps to investigate this problem? Any suggestion/question please feel free to let me know. Thanks, Haven was: Our project used org.apache.commons::commons-dbcp2:2.1.1 for collecting Database Connection Pooling metrics, and publish metrics from JMX to StatsD server After we changed version from 2.1.1 to 2.4.0, we can see Database Connection pool metrics are in JMX MBeans list, but all of Database Connection pool metrics are *NULL* value. May I get helps to investigate this problem? Any suggestion/question please feel free to let me know. Thanks, Haven > Can Not Collect Database Connection Pooling metrics In JMX > -- > > Key: DBCP-530 > URL: https://issues.apache.org/jira/browse/DBCP-530 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.1.1, 2.4.0 >Reporter: Haven Lin >Priority: Minor > Labels: usability > > *Background:* > Our project used org.apache.commons::commons-dbcp2:2.1.1 for collecting > Database Connection Pooling metrics, and publish metrics from JMX to StatsD > server > After we changed version from 2.1.1 to 2.4.0, we can see Database Connection > pool metrics are in JMX MBeans list, but all of Database Connection pool > metrics are *NULL* value. > > *Impact:* > It will caused we can not collect metrics from Database Connection Pooling. > > May I get helps to investigate this problem? > > Any suggestion/question please feel free to let me know. > > Thanks, > Haven > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DBCP-530) Can Not Collect Database Connection Pooling metrics In JMX
Haven Lin created DBCP-530: -- Summary: Can Not Collect Database Connection Pooling metrics In JMX Key: DBCP-530 URL: https://issues.apache.org/jira/browse/DBCP-530 Project: Commons DBCP Issue Type: Bug Affects Versions: 2.4.0, 2.1.1 Reporter: Haven Lin Our project used org.apache.commons::commons-dbcp2:2.1.1 for collecting Database Connection Pooling metrics, and publish metrics from JMX to StatsD server After we changed version from 2.1.1 to 2.4.0, we can see Database Connection pool metrics are in JMX MBeans list, but all of Database Connection pool metrics are *NULL* value. May I get helps to investigate this problem? Any suggestion/question please feel free to let me know. Thanks, Haven -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #383: Make whitespace use after tokens consistent and add...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/383 [](https://coveralls.io/builds/20166048) Coverage remained the same at 95.233% when pulling **869a26c5e71256e16b51727e717150ba4c5e8dfb on PascalSchumacher:consistent_whitespace_after_formatting** into **c4d0dbcb56b8980b1b3b7c85d00ad6540788c08e on apache:master**. ---
[GitHub] commons-lang pull request #383: Make whitespace use after tokens consistent ...
GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-lang/pull/383 Make whitespace use after tokens consistent and add checkstyle rule t⦠â¦o enforce it. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-lang consistent_whitespace_after_formatting Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/383.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 #383 commit 869a26c5e71256e16b51727e717150ba4c5e8dfb Author: pascalschumacher Date: 2018-11-18T10:59:34Z Make whitespace use after tokens consistent and add checkstyle rule to enforce it. ---
[jira] [Comment Edited] (LANG-1425) DateUtils.parseDateStrictly() is not parsing millisecond value
[
https://issues.apache.org/jira/browse/LANG-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690846#comment-16690846
]
Michael Osipov edited comment on LANG-1425 at 11/18/18 9:29 AM:
There are several issues here:
# How close is our parsing pattern to {{SimpleDateFormat}}? Not properly
documented
# {{Date}} is millisecond precision: {{SSS}} cannot and will not work.
# {{S}} alreay implies upto three decimal places while parsing, during
formatting it shall add trailing null at most, as far as I remember.
I guess we need to improve docs and tests. I stumbled upon this some time ago
too.
Also look here: https://stackoverflow.com/a/19223267/696632
If you really need more precision, consider using new Java Time API.
was (Author: michael-o):
There are several issues here:
# How close is our parsing pattern to {{SimpleDateFormat}}? Not properly
documented
# {{Date}} is millisecond precision: {{SSS}} cannot and will not work.
# {{S}} alreay implies upto three decimal places while parsing, during
formatting it shall add trailing null at most, as far as I remember.
I guess we need to improve docs and tests. I stumbled upon this some time ago
too.
Also look here: https://stackoverflow.com/a/19223267/696632
> DateUtils.parseDateStrictly() is not parsing millisecond value
> --
>
> Key: LANG-1425
> URL: https://issues.apache.org/jira/browse/LANG-1425
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.7
>Reporter: Vamsi Krishna Bhagi
>Priority: Major
>
> We need to parse String to java.util.Date and are having multiple Date
> formats.
> Snippet for this is
> {code:java}
> java.util.Date dt = DateUtils.parseDateStrictly(verificationDate.get_value(),
> Locale.ENGLISH,
> new String[] {
> "-MM-dd'T'HH:mm:ss.SSSXXX","-MM-dd'T'HH:mm::ss.SSS" });{code}
> 2018-11-13T08:03:41.286-06:00 is not being parsed correctly. On
> troubleshooting, we discovered that 2018-11-13T08:03:41.286-06:00 is
> parsing fine.
> How to handle this?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1425) DateUtils.parseDateStrictly() is not parsing millisecond value
[
https://issues.apache.org/jira/browse/LANG-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690846#comment-16690846
]
Michael Osipov commented on LANG-1425:
--
There are several issues here:
# How close is our parsing pattern to {{SimpleDateFormat}}? Not properly
documented
# {{Date}} is millisecond precision: {{SSS}} cannot and will not work.
# {{S}} alreay implies upto three decimal places while parsing, during
formatting it shall add trailing null at most, as far as I remember.
I guess we need to improve docs and tests. I stumbled upon this some time ago
too.
Also look here: https://stackoverflow.com/a/19223267/696632
> DateUtils.parseDateStrictly() is not parsing millisecond value
> --
>
> Key: LANG-1425
> URL: https://issues.apache.org/jira/browse/LANG-1425
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.7
>Reporter: Vamsi Krishna Bhagi
>Priority: Major
>
> We need to parse String to java.util.Date and are having multiple Date
> formats.
> Snippet for this is
> {code:java}
> java.util.Date dt = DateUtils.parseDateStrictly(verificationDate.get_value(),
> Locale.ENGLISH,
> new String[] {
> "-MM-dd'T'HH:mm:ss.SSSXXX","-MM-dd'T'HH:mm::ss.SSS" });{code}
> 2018-11-13T08:03:41.286-06:00 is not being parsed correctly. On
> troubleshooting, we discovered that 2018-11-13T08:03:41.286-06:00 is
> parsing fine.
> How to handle this?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
