[GitHub] commons-lang issue #193: Add isAnyNotEmpty() and isAnyNotBlank() to StringUt...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/193 [](https://coveralls.io/builds/8031415) Coverage decreased (-0.002%) to 93.527% when pulling **d2871a486271d60d49a557bc1f1d296f5efccf97 on ptemplier:stringutils-new-methods** into **db6f7c1d74ba64211221a69cfa9fe7171a9199e8 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #193: Add isAnyNotEmpty() and isAnyNotBlank() to S...
GitHub user ptemplier opened a pull request: https://github.com/apache/commons-lang/pull/193 Add isAnyNotEmpty() and isAnyNotBlank() to StringUtils You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptemplier/commons-lang stringutils-new-methods Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/193.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 #193 commit d2871a486271d60d49a557bc1f1d296f5efccf97 Author: Pierre Templier Date: 2016-09-23T22:49:32Z Add isAnyNotEmpty() and isAnyNotBlank() to StringUtils --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (EL-1) [el] Memory Leak: EL Cache entries never removed.
[
https://issues.apache.org/jira/browse/EL-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517771#comment-15517771
]
Jarek Jarcec Cecho commented on EL-1:
-
I believe that we hit this bug as well in our project. We have one JVM where
we're having a lot of various (and sometimes even half generated) expressions
and I've noticed that the internal caches in {{ExpressionEvaluatorImpl}} can
grow without any limitations - check out details on our [JIRA
SDC-4033|https://issues.streamsets.com/browse/SDC-4033] if you're interested -
the summary is that after approx. a day of running the cache occupied 84% of
heap and consumed more then 6GB of ram :(
I'm happy to take a stab at fixing this, but I'm not sure what would community
prefer me to do. Couple of brainstorming ideas:
* The class {{ExpressionEvaluatorImpl}} currently takes a {{boolean}} argument
in constructor called {{pBypassCache}} that indicates "flag indicating if the
cache should be bypassed". Sadly this flag only causes the class to not use the
cache for reading (checking if this expression was already seen), but [it will
be used for storing regardless of the actual value of this
flag|https://github.com/apache/commons-el/blob/trunk/src/java/org/apache/commons/el/ExpressionEvaluatorImpl.java#L267].
It seems fairly non-controversal to use this existing flag to stop writing
values to the cache if the flag is set to false?
* Another idea is to use a {{LRUMap}} instead normal {{HashMap}} - this way the
size would be limited and would not grow indefinitely. It seems potentially
controversial though as {{commons-el}} doesn't have a lot of dependencies and
I'm not sure if the community would be open to add dependency on let say
{{commons-collections}} to get {{LRUMap}} implementation. It could be shaded to
avoid leaking it to users, but it's still another (and fairly sizable)
dependency.
* Last but not least, perhaps we can expose methods {{cacheSize}} and
{{cleanUpCaches}} that user code can use to control the size?
> [el] Memory Leak: EL Cache entries never removed.
> -
>
> Key: EL-1
> URL: https://issues.apache.org/jira/browse/EL-1
> Project: Commons EL
> Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: All
> Platform: All
>Reporter: Bill Alexander
>
> This bug refers to the two caches on ExpressionEvaluatorImpl,
> sCachedExpressionStrings, but primarily sCachedExpectedTypes.
> Here is a use case to illustrate the problem. A web application typically
> creates 1,000 different objects of classes it defines using the EL language,
> and
> PropertyEditor's. A Tomcat instance is run with 5 of these web applications.
> Each time one of them is reloaded, a new classloader is created for the web
> application, so a new set of 1,000 objects is created in the cache. The old
> objects, and objects they point to (e.g. class and classloader objects), are
> never garbage collected. The only way to recover the associated memory is to
> stop and restart Tomcat.
> There are many possible solutions. A simple one would be to age instances out
> of the caches after a fixed period of time (say one hour). It would be nice if
> whatever cache controls are provided are configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCS-146) IndexedDiskCache: Mismatched memory and disk length (0) for [DED: pos = 63802 len = 9658] during optimization
[ https://issues.apache.org/jira/browse/JCS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517523#comment-15517523 ] Ryan Fong commented on JCS-146: --- We are seeing a lot of these errors using 2.0-beta1. Will you be pushing a beta-2 or release candidate soon? > IndexedDiskCache: Mismatched memory and disk length (0) for [DED: pos = > 63802 len = 9658] during optimization > -- > > Key: JCS-146 > URL: https://issues.apache.org/jira/browse/JCS-146 > Project: Commons JCS > Issue Type: Bug > Components: Indexed Disk Cache >Affects Versions: jcs-2.0 >Reporter: Wiktor N >Assignee: Thomas Vandahl > Fix For: jcs-2.0-beta-2 > > Attachments: IndexedDiskCacheOptimizationUnitTest.patch > > > I've created a small patch to test unit, that show the problem. See attached > file. > Generally, the problem is, that when I insert more than elements into the > Disk Cache, than it's limit, and then try to optimize it, there will be an > IOException thrown: > Mismatched memory and disk length (0) for [DED: pos = 63802 len = 9658] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BEANUTILS-497) Fix javadoc doclint errors
[
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517500#comment-15517500
]
Raviteja Lokineni commented on BEANUTILS-497:
-
[~stain], Submitted a PR
> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
> Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) -
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 -
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
> error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java
> class.
> [ERROR] ^
> [ERROR]
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
> warning: empty tag
> [ERROR] *
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects
> the html we put on our site).
> I notice that beanutils has a large use of
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for
> classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-497) Fix javadoc doclint errors
[
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516462#comment-15516462
]
Stian Soiland-Reyes commented on BEANUTILS-497:
---
If we can't fix them all, we should at least make {{mvn site}} work on Oracle
JDK 8.
(Emmanuel Bourg points out that Doclint has been turned off in Linux distro's
OpenJDK - but it's active on say Windows or OS X with Oracle JDK)
MJAVADOC-387 shows that the javadoc maven plugin has not yet got its own
configuration for doclint.
So a workaround is to add to pom.xml the option -Xdoclint:none - sadly this
option causes an error in older Javas, so it would have to be activated only
for JAva 8 or more.
> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
> Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) -
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 -
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
> error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java
> class.
> [ERROR] ^
> [ERROR]
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
> warning: empty tag
> [ERROR] *
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects
> the html we put on our site).
> I notice that beanutils has a large use of
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for
> classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BEANUTILS-497) Fix javadoc doclint errors
Stian Soiland-Reyes created BEANUTILS-497:
-
Summary: Fix javadoc doclint errors
Key: BEANUTILS-497
URL: https://issues.apache.org/jira/browse/BEANUTILS-497
Project: Commons BeanUtils
Issue Type: Task
Affects Versions: 1.9.3
Reporter: Stian Soiland-Reyes
Priority: Minor
Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) - which
breaks {{mvn site}} there.
Try with:
{code}
mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
{code}
(or if you are brave - {{-Xdoclint:all}} )
and get various errors and warnings like:
{code}
[ERROR] Exit code: 1 -
/home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
error: bad use of '>'
[ERROR] * register your own String --> Object conversions for any given Java
class.
[ERROR] ^
[ERROR]
/home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
warning: empty tag
[ERROR] *
[ERROR] ^
{code}
Most of these relate to wrong use of HTML, which we should fix (it affects the
html we put on our site).
I notice that beanutils has a large use of
{code}
DynaClass
{code}
where perhaps I would have expected
{code}
{@link DynaClass}
{code}
-- but if you fix those - make sure that you also get the full classname for
classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMPRESS-364) ZipArchiveInputStream.closeEntry does not properly advance to next entry if there are junk bytes at end of data section
[ https://issues.apache.org/jira/browse/COMPRESS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516226#comment-15516226 ] Michael Mole commented on COMPRESS-364: --- [~garydgregory] - Hi Gary. Were you able to get the patch working? > ZipArchiveInputStream.closeEntry does not properly advance to next entry if > there are junk bytes at end of data section > --- > > Key: COMPRESS-364 > URL: https://issues.apache.org/jira/browse/COMPRESS-364 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.12 >Reporter: Michael Mole >Priority: Minor > Attachments: > 0001-COMPRESS-364-ZipArchiveInputStream.closeEntry-fails-.patch > > > ZipArchiveInputStream.closeEntry() will not properly advance to the next > entry causing the next call to getNextZipEntry to incorrectly return null if > there are junk bytes at the end of the compressed data section. > More specifically, I found a case where the first entry's local header says > that its compressed data size is 620 bytes. There are in fact 620 bytes > before the next local header. However, when the compressed data is inflated, > it only requires 618 of the 620 bytes to fully inflate (i.e. before it > encounters the DEFLATE end of data code). This means that there is complete > DEFLATE compressed data + extra garbage bytes after it, all within the > specified zip entry data section. > The commons compress ZipArchiveInputStream streaming implementation doesn't > exactly read on zip entry boundaries, but instead it reads 512 bytes at a > time. As a result it tends to read more bytes than necessary per entry and > then seek back to the beginning of the next entry. When it seeks back, it > assumes that number of bytes that were required to be read to reach the end > of the zip entry is the same as the number of bytes needed to inflate the > data. However that assumption does not hold up in this case. 620 bytes need > to be read to reach then end of the zip entry, but only 618 were needed to > inflate the data. After the pushback, the closeEntry() method should perform > a final drain of the remaining bytes to reach the next local file header. > I've created a test case and fix. I will submit a pull request shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
