[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Amey Jadiye (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070970#comment-16070970
 ] 

Amey Jadiye commented on TEXT-96:
-

I want to keep both, i dont see any harm in that :)

> Convenience methods needed for RandomStringGenerator
> 
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated 
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new 
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate 
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point 
> is in the first place so then trying to get our automation testers to use the 
> new API to implement random alphanumeric character generation would be 
> difficult.
> I therefore suggest that commons-text should have a copy of 
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or 
> alternatively convenience static methods for the common use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-416) Tests failing under jdk 9 : one reflection issue, one change to ZipEntry related issue

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070835#comment-16070835
 ] 

Gary Gregory commented on COMPRESS-416:
---

After GitHub PR #43 I only have:
{noformat}
Failed tests:
  X5455_ExtendedTimestampTest.testSampleFile:185 
expected:<[2105-01-01/00:00:02] +> but was:<[1968-11-24/17:31:45] +>
Tests in error:
  
ZCompressorInputStreamTest.testFailsToCreateZCompressorInputStreamAndThrowsIOException
 ╗

Tests run: 842, Failures: 1, Errors: 1, Skipped: 4
{noformat}

> Tests failing under jdk 9 : one reflection issue, one change to ZipEntry 
> related issue
> --
>
> Key: COMPRESS-416
> URL: https://issues.apache.org/jira/browse/COMPRESS-416
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.14, 1.15
> Environment: JDK 9 ( jdk9 tree tip - I believe this is what will be 
> the RC, or if not, what would have been RC). 
> java.runtime.version = 9-internal+0-adhoc.ses.jdk9
> java.specification.version = 9
> java.version = 9-internal
> java.vm.specification.version = 9
> os.arch = amd64
> os.name = Linux
> os.version = 4.4.0-81-generic
>Reporter: Simon Spero
> Fix For: 1.15
>
> Attachments: surefire-reports.zip
>
>
> X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to 
> be a bogus value returned from getTime().  It seems like the test failure 
> might be due to the changes introduced for this: 
> https://bugs.openjdk.java.net/browse/JDK-8073497
> Tests were run using intelliJ TestRunner, using the openjdk9 build from the 
> tip of the jdk9 tree (not dev).  I believe that this is at most one commit 
> away from what will be the RC (which was delayed at the last minute due to 
> two issues, one of which was javadoc related, and the other hotspot. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved COMPRESS-413.
---
Resolution: Fixed

Thank you for the PR. Patch applied except for the removal of Oracle 7 and 8 
from the Travis build.

Please verify and close or continue.

I only see 1 error and one failure now instead of a bunch:

{noformat}
Failed tests:
  X5455_ExtendedTimestampTest.testSampleFile:185 
expected:<[2105-01-01/00:00:02] +> but was:<[1968-11-24/17:31:45] +>
Tests in error:
  
ZCompressorInputStreamTest.testFailsToCreateZCompressorInputStreamAndThrowsIOException
 ╗

Tests run: 842, Failures: 1, Errors: 1, Skipped: 4
{noformat}

> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070831#comment-16070831
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user asfgit closed the pull request at:

https://github.com/apache/commons-compress/pull/43


> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NET-638) Telnet subnegotiations hard-limited to 512 bytes

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/NET-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070823#comment-16070823
 ] 

Sebb commented on NET-638:
--

Patches welcome

> Telnet subnegotiations hard-limited to 512 bytes
> 
>
> Key: NET-638
> URL: https://issues.apache.org/jira/browse/NET-638
> Project: Commons Net
>  Issue Type: Improvement
>  Components: Telnet
>Affects Versions: 3.6
>Reporter: Daniel Leong
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently using Commons.net's Telnet client for connecting to MUD/MUSH 
> servers, and some servers use subnegotiation for sending out-of-band data 
> with more than the hard-coded 512 bytes that TelnetInputStream limits it to. 
> It looks like it would be straightforward to add an (optional) int 
> constructor parameter to TelnetClient that passes it to a similar, new 
> TelnetInputStream constructor parameter.
> I've got a workaround using a bunch of reflection, but it'd be nice to not 
> need that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070784#comment-16070784
 ] 

Simon Spero commented on COMPRESS-413:
--

Oracle JDK 7 is EOL and is missing critical security patches.  OpenJDK  7
is at least lightly patched.

Oracle JDK and OpenJDK are in a different situation to IBM java.
Open/Oracle JDKs both use the same virtual machine, and the roughly the
same source trees, whereas IBM java uses a completely different VM
implementation (J9), and also has a few differences in the runtime
libraries (mostly openjdk, but there are a few differences).  Any code that
uses private interfaces not covered by the TCK is having problems.

I haven't had any

On Fri, Jun 30, 2017 at 5:23 PM, ASF GitHub Bot (JIRA) 



> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070746#comment-16070746
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user garydgregory commented on the issue:

https://github.com/apache/commons-compress/pull/43
  
We all know that Java 7 is EOL but that is the required platform currently. 
As we have seen in Commons with other components, the IBM JDK sometimes gives 
surprising results. It is my opinion that we do loose confidence that all is 
well everywhere by omitting building on Oracle's JDK.


> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (RNG-33) Consider adding convenience methods to UniformRandomProvider

[Gilles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RNG-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles resolved RNG-33.
---
Resolution: Not A Problem

> Consider adding convenience methods to UniformRandomProvider
> 
>
> Key: RNG-33
> URL: https://issues.apache.org/jira/browse/RNG-33
> Project: Commons RNG
>  Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Duncan Jones
>Priority: Minor
>
> Commons Lang maintains a class called 
> [{{RandomUtils}}|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/RandomUtils.html],
>  which supplements the methods offered by {{java.util.Random}}.
> If similar methods were added to {{UniformRandomProvider}}, we could 
> deprecate {{RandomUtils}} in favour of using RNG.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (RNG-38) Wrong badge on Github

[Gilles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/RNG-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles resolved RNG-38.
---
Resolution: Workaround

Badges were manually added.

The "README.md" file should not be re-generated before there is a solution to 
COMMONSSITE-90 for modular components.


> Wrong badge on Github
> -
>
> Key: RNG-38
> URL: https://issues.apache.org/jira/browse/RNG-38
> Project: Commons RNG
>  Issue Type: Bug
>Reporter: Gilles
>Assignee: Artem Barger
>Priority: Minor
>  Labels: github, readme, web-site
> Fix For: 1.1
>
>
> The (auto-generated) "README.md" file contains the following line:
> {noformat}
> [![Maven 
> Central](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-rng/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-rng/)
> {noformat}
> which results in the badge showing "maven central unknown" on the GitHub 
> mirror main page (and clicking on it leads to a page, on Maven Central, that 
> shows: "No records found, try new search criteria").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (COMMONSSITE-90) Include badges in the README.md file

[Gilles (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMMONSSITE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles reopened COMMONSSITE-90:
---

For a component that defines modules, the current template will display a badge 
that links to a non-existent artefact (see RNG-38).
Is there a way for the template to generate one badge for each relevant module?

> Include badges in the README.md file
> 
>
> Key: COMMONSSITE-90
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-90
> Project: Commons All
>  Issue Type: New Feature
>  Components: Commons Build Plugin
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.7
>
>
> Add option to include badges in the README.md file
> For example from Commons Lang:
> {noformat}
> Apache Commons Lang
> ===
> [![Build 
> Status](https://travis-ci.org/apache/commons-lang.svg?branch=master)](https://travis-ci.org/apache/commons-lang)
> [![Coverage 
> Status](https://coveralls.io/repos/apache/commons-lang/badge.svg?branch=master)](https://coveralls.io/r/apache/commons-lang)
> [![Maven 
> Central](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-lang3/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.apache.commons/commons-lang3/)
> [![License](http://img.shields.io/:license-apache-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0.html)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070642#comment-16070642
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/43
  
Oracle JDK 7 has been dead for two years. Openjdk 7 has some back ports of 
security patches, but both are gone from most Linux distros. 

Openjdk and oraclejdk 8 are essentially in sync, with the only differences 
really being the oracle proprietary stuff. There's not much win testing against 
both unless the oracle commercial stuff is being used. 


> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070632#comment-16070632
 ] 

Gilles commented on TEXT-96:


IIUC, you mean to remove
{code}
withinRange(char ...)
{code}
and have
{code}
withinRange(char[] ...)
{code}
instead. That's fine with me.

> Convenience methods needed for RandomStringGenerator
> 
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated 
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new 
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate 
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point 
> is in the first place so then trying to get our automation testers to use the 
> new API to implement random alphanumeric character generation would be 
> difficult.
> I therefore suggest that commons-text should have a copy of 
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or 
> alternatively convenience static methods for the common use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-416) Tests failing under jdk 9 : one reflection issue, one change to ZipEntry related issue

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070616#comment-16070616
 ] 

Simon Spero commented on COMPRESS-416:
--

I've replaced the use of mocks in SevenZNativeHeapTest with delegation.  I'm 
not sure whether this test is really testing much, but it's easy enough to just 
convert a couple of anonymous classes to named package private ones, and to 
generate trivial delegates. 

I can see where the bad code is in the mock libs, but that's not my problem 
anymore :-) 

All JDK 9 changes are going into the fixed travis tree, since I've learned my 
lesson and won't try splitting PRs that depend on other  dependencies.

> Tests failing under jdk 9 : one reflection issue, one change to ZipEntry 
> related issue
> --
>
> Key: COMPRESS-416
> URL: https://issues.apache.org/jira/browse/COMPRESS-416
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.14, 1.15
> Environment: JDK 9 ( jdk9 tree tip - I believe this is what will be 
> the RC, or if not, what would have been RC). 
> java.runtime.version = 9-internal+0-adhoc.ses.jdk9
> java.specification.version = 9
> java.version = 9-internal
> java.vm.specification.version = 9
> os.arch = amd64
> os.name = Linux
> os.version = 4.4.0-81-generic
>Reporter: Simon Spero
> Fix For: 1.15
>
> Attachments: surefire-reports.zip
>
>
> X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to 
> be a bogus value returned from getTime().  It seems like the test failure 
> might be due to the changes introduced for this: 
> https://bugs.openjdk.java.net/browse/JDK-8073497
> Tests were run using intelliJ TestRunner, using the openjdk9 build from the 
> tip of the jdk9 tree (not dev).  I believe that this is at most one commit 
> away from what will be the RC (which was delayed at the last minute due to 
> two issues, one of which was javadoc related, and the other hotspot. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070604#comment-16070604
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/43
  

[![Coverage 
Status](https://coveralls.io/builds/12210519/badge)](https://coveralls.io/builds/12210519)

Coverage increased (+0.3%) to 85.034% when pulling 
**ae1f61cbd73615829b2d25a9ee8f2eb734d73119 on sesuncedu:COMPRESS-413-REDUX** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070588#comment-16070588
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user garydgregory commented on a diff in the pull request:

https://github.com/apache/commons-compress/pull/43#discussion_r125108952
  
--- Diff: .travis.yml ---
@@ -13,17 +13,26 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-language: java
 sudo: false
+# Use Trusty as dist
+dist: trusty
+language: java
+
 
 jdk:
   - openjdk7
-  - oraclejdk7
-  - oraclejdk8
--- End diff --

Why drop the Oracle JDK builds?


> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-416) Tests failing under jdk 9 : one reflection issue, one change to ZipEntry related issue

[Simon Spero (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070536#comment-16070536
 ] 

Simon Spero commented on COMPRESS-416:
--

The issues are being caused by jacoco making a class unloadable by twiddling 
with a final field outside a constructor. 

This is fixed by using a newer version of jacoco. 

I have made a few changes to the enhanced travis branch, which reduces the, er, 
non-successes to three tests.  
See: https://github.com/apache/commons-compress/pull/43

Some of these are changes to outdated plugin versions. I blame the parents.

There are two "failures" and one "error". Quotation marks are used because one 
of the failures is actually an error.

The real failure is the change in the handling of zip dates in the jdk 
ZipEntry.  This is an actual incompatibility. 

The second failure is really an illegal access from a mocker; it just happens 
to take place in test for an expected exception.   This  presents as  a warning 
in the (probable) RC -
{noformat}
Running org.apache.commons.compress.compressors.z.ZCompressorInputStreamTest
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.mockito.cglib.core.ReflectUtils$2 
(file:/home/ses/.m2/repository/org/mockito/mockito-core/1.10.19/mockito-core-1.10.19.jar)
 to method 
java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of 
org.mockito.cglib.core.ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}

I'm not sure how I feel about having to locate the maintainers of an anonymous 
inner class :-) 



> Tests failing under jdk 9 : one reflection issue, one change to ZipEntry 
> related issue
> --
>
> Key: COMPRESS-416
> URL: https://issues.apache.org/jira/browse/COMPRESS-416
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.14, 1.15
> Environment: JDK 9 ( jdk9 tree tip - I believe this is what will be 
> the RC, or if not, what would have been RC). 
> java.runtime.version = 9-internal+0-adhoc.ses.jdk9
> java.specification.version = 9
> java.version = 9-internal
> java.vm.specification.version = 9
> os.arch = amd64
> os.name = Linux
> os.version = 4.4.0-81-generic
>Reporter: Simon Spero
> Fix For: 1.15
>
> Attachments: surefire-reports.zip
>
>
> X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to 
> be a bogus value returned from getTime().  It seems like the test failure 
> might be due to the changes introduced for this: 
> https://bugs.openjdk.java.net/browse/JDK-8073497
> Tests were run using intelliJ TestRunner, using the openjdk9 build from the 
> tip of the jdk9 tree (not dev).  I believe that this is at most one commit 
> away from what will be the RC (which was delayed at the last minute due to 
> two issues, one of which was javadoc related, and the other hotspot. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070533#comment-16070533
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/43
  

[![Coverage 
Status](https://coveralls.io/builds/12209789/badge)](https://coveralls.io/builds/12209789)

Coverage increased (+0.09%) to 84.856% when pulling 
**71eb8304944a50c30ff6b057ecdd9f6210477e4d on sesuncedu:COMPRESS-413-REDUX** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



> Travis build redundantly repeats compilation and tests redundantly
> --
>
> Key: COMPRESS-413
> URL: https://issues.apache.org/jira/browse/COMPRESS-413
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.14
> Environment: Travis
>Reporter: Simon Spero
>Priority: Minor
>  Labels: CI
> Fix For: 1.15
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; 
> this time with 
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run 
> tests with coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if 
> the service is unreachable, so forks that don't have jacoco enabled won't 
> always have their builds fail. 
> Also, the jdk switching in the trusty container seems to be not working 
> properly at the moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Amey Jadiye (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070462#comment-16070462
 ] 

Amey Jadiye commented on TEXT-96:
-

*Yes*, For scope of this JIRA I strongly believe that. what Mr. [~greenth] want 
can be accommodated easily with flexibility of the API.

Ex. for
*.randomNumeric()*
{code}
char [][]  ranges = {{'0','9'}};
RandomStringGenerator generator = new 
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}

*.randomAlphabetic()*
{code}
char [][]  ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}}
RandomStringGenerator generator = new 
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}

*.randomAlphanumeric()*
{code}
char [][]  ranges = {{'0','9'},{'A','Z'},{'a','b'}};
RandomStringGenerator generator = new 
RandomStringGenerator.Builder().withinRange(ranges).build();
{code}


> Convenience methods needed for RandomStringGenerator
> 
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated 
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new 
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate 
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point 
> is in the first place so then trying to get our automation testers to use the 
> new API to implement random alphanumeric character generation would be 
> difficult.
> I therefore suggest that commons-text should have a copy of 
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or 
> alternatively convenience static methods for the common use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070439#comment-16070439
 ] 

Gilles commented on TEXT-96:


Would
{code}
withinRanges(char[] ...)
{code}
cover every such needs?


> Convenience methods needed for RandomStringGenerator
> 
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated 
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new 
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate 
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point 
> is in the first place so then trying to get our automation testers to use the 
> new API to implement random alphanumeric character generation would be 
> difficult.
> I therefore suggest that commons-text should have a copy of 
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or 
> alternatively convenience static methods for the common use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Amey Jadiye (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070339#comment-16070339
 ] 

Amey Jadiye commented on TEXT-96:
-

{{RandomStringGenerator}} is certainly better and flexible in terms of your 
desired output and I don't know what was motivation behind deprecating 
{{RandomStringUtils}} and giving away simple API's. but at some point those 
simple things should be accommodated somewhere in {{RandomStringGenerator}} 
*or* at least should provide more examples in Javadocs. *or* helper utilities 
should me present somewhere which will bring back usefulness of 
{{RandomStringUtils}} to -> {{RandomStringGenerator}}

> Convenience methods needed for RandomStringGenerator
> 
>
> Key: TEXT-96
> URL: https://issues.apache.org/jira/browse/TEXT-96
> Project: Commons Text
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Peter Phillips
>Priority: Minor
>
> {{RandomStringGenerator}} is extremely verbose compared to the deprecated 
> commons.lang3 {{RandomStringUtils}}.
> Previously we could write:
> {code:java}
> RandomStringUtils.randomNumeric(10)
> {code}
> to generate a numeric string whereas this now has become:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10)
> {code}
> although in practice we would then also use static imports too.
> The {{randomAlphabetic}} conversion is even more verbose:
> {code:java}
> new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new 
> CharacterPredicate() {
> @Override
> public boolean test(int codePoint) {
> return codePoint >= 'a' || codePoint <= 'Z';
> }
> }).build().generate(10))
> {code} and at that point I lost enthusiam with trying to replicate 
> {{randomAlphanumeric}}.
> I don't think the average java developer would understand what a code point 
> is in the first place so then trying to get our automation testers to use the 
> new API to implement random alphanumeric character generation would be 
> difficult.
> I therefore suggest that commons-text should have a copy of 
> {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or 
> alternatively convenience static methods for the common use cases.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types

[Dmitri Blinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JEXL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitri Blinov updated JEXL-234:
---
Attachment: patch0.patch

> Extend application of operators startsWith and endsWith from String to 
> CharSequence types
> -
>
> Key: JEXL-234
> URL: https://issues.apache.org/jira/browse/JEXL-234
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Attachments: patch0.patch
>
>
> It would be more useful to have operators {{=$}} and {{=^}} to work with 
> objects that support {{CharSequence}} interface, like {{StringBuilder}}, 
> which would have more broad usage then just with {{String}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types

[Dmitri Blinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16070283#comment-16070283
 ] 

Dmitri Blinov commented on JEXL-234:


I usually try to propose an improvement if I think the use case is generic and 
regards basic java classes so that the community may benefit from it. Here is 
the patch.

> Extend application of operators startsWith and endsWith from String to 
> CharSequence types
> -
>
> Key: JEXL-234
> URL: https://issues.apache.org/jira/browse/JEXL-234
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Attachments: patch0.patch
>
>
> It would be more useful to have operators {{=$}} and {{=^}} to work with 
> objects that support {{CharSequence}} interface, like {{StringBuilder}}, 
> which would have more broad usage then just with {{String}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types

[Henri Biestro (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069998#comment-16069998
 ] 

Henri Biestro commented on JEXL-234:


The startsWith & endsWIth methods can be overloaded; the operator resolution 
will pick the most appropriate version based on signature.
This can be implemented easily in a user-specialized version of JexlArithmetic.
You are always welcome to submit a patch + tests.

> Extend application of operators startsWith and endsWith from String to 
> CharSequence types
> -
>
> Key: JEXL-234
> URL: https://issues.apache.org/jira/browse/JEXL-234
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> It would be more useful to have operators {{=$}} and {{=^}} to work with 
> objects that support {{CharSequence}} interface, like {{StringBuilder}}, 
> which would have more broad usage then just with {{String}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JEXL-234) Extend application of operators startsWith and endsWith from String to CharSequence types

[Dmitri Blinov (JIRA)]

Dmitri Blinov created JEXL-234:
--

 Summary: Extend application of operators startsWith and endsWith 
from String to CharSequence types
 Key: JEXL-234
 URL: https://issues.apache.org/jira/browse/JEXL-234
 Project: Commons JEXL
  Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Minor


It would be more useful to have operators {{=$}} and {{=^}} to work with 
objects that support {{CharSequence}} interface, like {{StringBuilder}}, which 
would have more broad usage then just with {{String}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64

[Youssef OUMANZOU (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069796#comment-16069796
 ] 

Youssef OUMANZOU edited comment on DAEMON-363 at 6/30/17 10:02 AM:
---

Hi Derek,

Do you have an idea about the solution that the patch implements?

In fact, I dont' know how the problem could be resolved since the 
CVE-2017-1000364 increases the stack guard gap size from one page to 1M, to 
limit the security flaw.  Will the kernel deal with the jsvc as an exception to 
allow less than 1M memory allocation?






was (Author: youmanzou):
Hi Derek,

Do you have an idea about the solution that the patch implements?

In fact, I dont' know how the problem could be resolved since the 
CVE-2017-1000364 increases the stack guard gap size from one page to 1 MiB, to 
limit the security flaw.  Will the kernel deal with the jsvc as an exception to 
allow less than 1MIB memory allocation?





> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 
> 2.6.32-696.3.2.el6.x86_64
> 
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel 
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a 
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version:  (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # j  java.lang.Object.()V+0
> {code}
> The following reproduces the problem.  Note that the target class is not 
> relevant as it never reaches that point.
> ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
>  ret = (*symb) (, , );
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE 
> | Java Home:   "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs:  1
> | JVM Name:"server"
> |  "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/ 
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0

[jira] [Comment Edited] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64

[Sven Neuhaus (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069809#comment-16069809
 ] 

Sven Neuhaus edited comment on DAEMON-363 at 6/30/17 9:54 AM:
--

As far as Ubuntu 16.04 LTS is concerned, this kernel regression was apparently 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/].

Quote:
bq. "USN 3328-1 fixed a vulnerability in the Linux kernel. However, that fix 
introduced regressions for some Java applications. This update addresses the 
issue. We apologize for the inconvenience."


was (Author: neuhaus):
As far as Ubuntu 16.04 LTS is concerned, this kernel regression was apparently 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/].

Quote:
bq. "_USN 3328-1 fixed a vulnerability in the Linux kernel. However, that
bq. fix introduced regressions for some Java applications. This update
bq. addresses the issue. We apologize for the inconvenience._"

> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 
> 2.6.32-696.3.2.el6.x86_64
> 
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel 
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a 
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version:  (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # j  java.lang.Object.()V+0
> {code}
> The following reproduces the problem.  Note that the target class is not 
> relevant as it never reaches that point.
> ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
>  ret = (*symb) (, , );
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE 
> | Java Home:   "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs:  1
> | JVM Name:"server"
> |  "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/ 
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:  

[jira] [Commented] (JEXL-233) Documentation rewrite

[Henri Biestro (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069812#comment-16069812
 ] 

Henri Biestro commented on JEXL-233:



I was just wondering myself about the numerous missing (or shallow) elements of 
documentation, starting with the (dreadful) introductory example and the (so) 
many ways we can now customize JEXL to expose objects and methods.
About the syntax though, I've always looked at it from an 'end-user' 
prospective. I'm not sure it is the place to differentiate between duck-types 
and indexed-container; again, from an end-user prospective, the variables 
exposed and their types, including their properties and wether they 
appear/behave as arrays, as well as the functions and namespaces, should be 
documented separately. These should be part of the reference manual 
accompanying the platform that uses JEXL as scripting engine. But as an 
end-user, I should not have to make the distinctions between all those 
different property accessors. And the syntax reference should remain free of 
them (imho).
It is true though that somewhere is missing a good overview of the different 
means of exposing properties or functions to the engine (Javadoc covers some) 
including their resolution orders. Good examples/use cases would certainly make 
a huge difference.

> Documentation rewrite
> -
>
> Key: JEXL-233
> URL: https://issues.apache.org/jira/browse/JEXL-233
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
> Attachments: syntax.xml
>
>
> I have reorganized the JEXL syntax doc, basically adjusted the document 
> structure to be more logical in my view, and brushed up some descriptions.
> Comments are welcome! If it is ok, please promote the attachment to the 
> source tree. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64

[Sven Neuhaus (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069809#comment-16069809
 ] 

Sven Neuhaus edited comment on DAEMON-363 at 6/30/17 9:53 AM:
--

As far as Ubuntu 16.04 LTS is concerned, this kernel regression was apparently 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/].

Quote:
bq. "_USN 3328-1 fixed a vulnerability in the Linux kernel. However, that
bq. fix introduced regressions for some Java applications. This update
bq. addresses the issue. We apologize for the inconvenience._"


was (Author: neuhaus):
As far as Ubuntu 16.04 LTS is concerned, this kernel regression was apparently 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/].

> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 
> 2.6.32-696.3.2.el6.x86_64
> 
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel 
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a 
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version:  (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # j  java.lang.Object.()V+0
> {code}
> The following reproduces the problem.  Note that the target class is not 
> relevant as it never reaches that point.
> ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
>  ret = (*symb) (, , );
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE 
> | Java Home:   "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs:  1
> | JVM Name:"server"
> |  "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/ 
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name: 

[jira] [Comment Edited] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64

[Sven Neuhaus (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069809#comment-16069809
 ] 

Sven Neuhaus edited comment on DAEMON-363 at 6/30/17 9:52 AM:
--

As far as Ubuntu 16.04 LTS is concerned, this kernel regression was apparently 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/].


was (Author: neuhaus):
As far as Ubuntu is concerned, it appears that this kernel regression was 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/]

> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 
> 2.6.32-696.3.2.el6.x86_64
> 
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel 
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a 
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version:  (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # j  java.lang.Object.()V+0
> {code}
> The following reproduces the problem.  Note that the target class is not 
> relevant as it never reaches that point.
> ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
>  ret = (*symb) (, , );
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE 
> | Java Home:   "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs:  1
> | JVM Name:"server"
> |  "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/ 
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in 

[jira] [Commented] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64

[Sven Neuhaus (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069809#comment-16069809
 ] 

Sven Neuhaus commented on DAEMON-363:
-

As far as Ubuntu is concerned, it appears that this kernel regression was 
addressed by [USN-3344-1|https://www.ubuntu.com/usn/usn-3344-1/]

> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 
> 2.6.32-696.3.2.el6.x86_64
> 
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel 
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a 
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version:  (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # j  java.lang.Object.()V+0
> {code}
> The following reproduces the problem.  Note that the target class is not 
> relevant as it never reaches that point.
> ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
>  ret = (*symb) (, , );
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE 
> | Java Home:   "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs:  1
> | JVM Name:"server"
> |  "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/ 
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration 

[jira] [Commented] (DAEMON-363) JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 2.6.32-696.3.2.el6.x86_64

[Youssef OUMANZOU (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069796#comment-16069796
 ] 

Youssef OUMANZOU commented on DAEMON-363:
-

Hi Derek,

Do you have an idea about the solution that the patch implements?

In fact, I dont' know how the problem could be resolved since the 
CVE-2017-1000364 increases the stack guard gap size from one page to 1 MiB, to 
limit the security flaw.  Will the kernel deal with the jsvc as an exception to 
allow less than 1MIB memory allocation?





> JSVC Fails to launch (SIGBUS 0x7) on Centos 6.9 Kernel 
> 2.6.32-696.3.2.el6.x86_64
> 
>
> Key: DAEMON-363
> URL: https://issues.apache.org/jira/browse/DAEMON-363
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
> Environment: CentOS 6.9
> Kernel: 2.6.32-696.3.2.el6.x86_64
> Updated for CVE: CVE-2017-1000364
> JSVC compiled from latest source.
>Reporter: Derek Schenk
>Priority: Critical
> Attachments: hs_err_pid4035.log
>
>
> After applying the update for CVE-2017-1000364 to CentOS 6.9 (kernel 
> 2.6.32-696.3.2.el6.x86_64) JSVC no longer launches the JVM.
> The process starts, and when it attempts to launch the JVM it fails with a 
> SIGBUS (0x7).
> {code}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f4785109bfc, pid=21204, tid=0x7f4796bbd700
> #
> # JRE version:  (8.0_121-b13) (build )
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
> linux-amd64 compressed oops)
> # Problematic frame:
> # j  java.lang.Object.()V+0
> {code}
> The following reproduces the problem.  Note that the target class is not 
> relevant as it never reaches that point.
> ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> Tracing the code it reaches this point and then fails:
> {code}
> java.c
> bool java_init(arg_data *args, home_data *data)
>  ret = (*symb) (, , );
> {code}
> The following is the output:
> {code}
> # ./jsvc -debug -verbose  -home /opt/java/1.8.0_121/  com.does.not.Matter
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in /opt/java/1.8.0_121/
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/jvm.cfg
> Attempting to locate VM configuration file /opt/java/1.8.0_121//lib/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//jre/lib/amd64/jvm.cfg
> Attempting to locate VM configuration file 
> /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM configuration file at /opt/java/1.8.0_121//lib/amd64/jvm.cfg
> Found VM server definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/server/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Found VM client definition in configuration
> Checking library /opt/java/1.8.0_121//jre/lib/amd64/client/libjvm.so
> Checking library /opt/java/1.8.0_121//lib/amd64/client/libjvm.so
> Cannot locate library for VM client (skipping)
> Java Home located in /opt/java/1.8.0_121/
> +-- DUMPING JAVA HOME STRUCTURE 
> | Java Home:   "/opt/java/1.8.0_121/"
> | Java VM Config.: "/opt/java/1.8.0_121//lib/amd64/jvm.cfg"
> | Found JVMs:  1
> | JVM Name:"server"
> |  "/opt/java/1.8.0_121//lib/amd64/server/libjvm.so"
> +---
> Using default JVM in /opt/java/1.8.0_121//lib/amd64/server/libjvm.so
> Invoking w/ 
> LD_LIBRARY_PATH=/opt/java/1.8.0_121//lib/amd64/server:/opt/java/1.8.0_121//lib/amd64
> +-- DUMPING PARSED COMMAND LINE ARGUMENTS --
> | Detach:  True
> | Show Version:No
> | Show Help:   No
> | Check Only:  Disabled
> | Stop:False
> | Wait:0
> | Run as service:  No
> | Install service: No
> | Remove service:  No
> | JVM Name:"null"
> | Java Home:   "/opt/java/1.8.0_121/"
> | PID File:"/var/run/jsvc.pid"
> | User Name:   "null"
> | Extra Options:   1
> |   "-verbose"
> | Class Invoked:   "com.does.not.Matter"
> | Class Arguments: 0
> +---
> Attempting to locate Java Home in 

[jira] [Commented] (CLI-217) Optional partial matching for long options

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069652#comment-16069652
 ] 

ASF GitHub Bot commented on CLI-217:


Github user rubin55 commented on the issue:

https://github.com/apache/commons-cli/pull/15
  
Is someone looking at this PR?


> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLI-217) Optional partial matching for long options

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069651#comment-16069651
 ] 

ASF GitHub Bot commented on CLI-217:


Github user rubin55 commented on the issue:

https://github.com/apache/commons-cli/pull/15
  
Is someone looking at this PR?


> Optional partial matching for long options
> --
>
> Key: CLI-217
> URL: https://issues.apache.org/jira/browse/CLI-217
> Project: Commons CLI
>  Issue Type: Improvement
>  Components: Parser
>Affects Versions: 1.3
>Reporter: Emmanuel Bourg
> Attachments: CLI-217.patch, optPartialMatch.patch
>
>
> DefaultParser support partial long options (i.e --ver matches --version if 
> there is no ambiguity), but for some cases it might be necessary to disable 
> this feature.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-416) Tests failing under jdk 9 : one reflection issue, one change to ZipEntry related issue

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069586#comment-16069586
 ] 

Gary Gregory commented on COMPRESS-416:
---

I think I need a Java 9 that implements {{--permit-illegal-access}}. I'll 
attache my surefire reports.

> Tests failing under jdk 9 : one reflection issue, one change to ZipEntry 
> related issue
> --
>
> Key: COMPRESS-416
> URL: https://issues.apache.org/jira/browse/COMPRESS-416
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.14, 1.15
> Environment: JDK 9 ( jdk9 tree tip - I believe this is what will be 
> the RC, or if not, what would have been RC). 
> java.runtime.version = 9-internal+0-adhoc.ses.jdk9
> java.specification.version = 9
> java.version = 9-internal
> java.vm.specification.version = 9
> os.arch = amd64
> os.name = Linux
> os.version = 4.4.0-81-generic
>Reporter: Simon Spero
> Fix For: 1.15
>
> Attachments: surefire-reports.zip
>
>
> X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to 
> be a bogus value returned from getTime().  It seems like the test failure 
> might be due to the changes introduced for this: 
> https://bugs.openjdk.java.net/browse/JDK-8073497
> Tests were run using intelliJ TestRunner, using the openjdk9 build from the 
> tip of the jdk9 tree (not dev).  I believe that this is at most one commit 
> away from what will be the RC (which was delayed at the last minute due to 
> two issues, one of which was javadoc related, and the other hotspot. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COMPRESS-416) Tests failing under jdk 9 : one reflection issue, one change to ZipEntry related issue

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated COMPRESS-416:
--
Attachment: surefire-reports.zip

> Tests failing under jdk 9 : one reflection issue, one change to ZipEntry 
> related issue
> --
>
> Key: COMPRESS-416
> URL: https://issues.apache.org/jira/browse/COMPRESS-416
> Project: Commons Compress
>  Issue Type: Bug
>Affects Versions: 1.14, 1.15
> Environment: JDK 9 ( jdk9 tree tip - I believe this is what will be 
> the RC, or if not, what would have been RC). 
> java.runtime.version = 9-internal+0-adhoc.ses.jdk9
> java.specification.version = 9
> java.version = 9-internal
> java.vm.specification.version = 9
> os.arch = amd64
> os.name = Linux
> os.version = 4.4.0-81-generic
>Reporter: Simon Spero
> Fix For: 1.15
>
> Attachments: surefire-reports.zip
>
>
> X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to 
> be a bogus value returned from getTime().  It seems like the test failure 
> might be due to the changes introduced for this: 
> https://bugs.openjdk.java.net/browse/JDK-8073497
> Tests were run using intelliJ TestRunner, using the openjdk9 build from the 
> tip of the jdk9 tree (not dev).  I believe that this is at most one commit 
> away from what will be the RC (which was delayed at the last minute due to 
> two issues, one of which was javadoc related, and the other hotspot. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (DAEMON-367) Windows service fails to start after Windows 10 Creators Update

[Dave Bennett (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAEMON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069590#comment-16069590
 ] 

Dave Bennett commented on DAEMON-367:
-

I haven't used an ImageFile parameter as I don't know how that might be used, 
and I don't understand what you mean by a 'start time' parameter. The service 
logs-on with a 'Local System Account'. 

I installed the service via the following .bat file as I had learnt to do when 
I first used this method.

set SERVICE_NAME=BSS2SRVB2
set PR_INSTALL=C:\Data\Eclipse_Projects\BSS2\BSS2_01.07\jar\prunsrv.exe
REM Service log configuration
set PR_LOGPREFIX=BSS2SRVB2
set PR_LOGPATH=C:\Data\Eclipse_Projects\BSS2\BSS2_01.07\jar\logs
set PR_STDOUTPUT=C:\Data\Eclipse_Projects\BSS2\BSS2_01.07\jar\logs\stdoutb2.txt
set PR_STDERROR=C:\Data\Eclipse_Projects\BSS2\BSS2_01.07\jar\logs\stderrb2.txt
set PR_LOGLEVEL=Error
REM Path to java installation
set PR_JVM=C:\Program Files (x86)\Java\jdk1.7.0_13\jre\bin\server\jvm.dll
set PR_CLASSPATH=BSS2SRVB2.jar
REM Startup configuration (manual or auto)
set PR_STARTUP=auto
set PR_STARTMODE=jvm
set PR_STARTCLASS=uk.co.parkthorn.services.Basic2Service
set PR_STARTMETHOD=startService
REM Shutdown configuration
set PR_STOPMODE=jvm
set PR_STOPCLASS=uk.co.parkthorn.services.Basic2Service
set PR_STOPMETHOD=stopService
REM JVM configuration
set PR_JVMMS=256
set PR_JVMMX=1024
set PR_JVMSS=4000
set PR_JVMOPTIONS=-Duser.language=EN;-Duser.region=gb
REM Install service
C:\Data\Eclipse_Projects\BSS2\BSS2_01.07\jar\prunsrv.exe //IS//BSS2SRVB2
C:\Data\Eclipse_Projects\BSS2\BSS2_01.07\jar\prunsrv.exe //US//BSS2SRVB2 
--Description "BSS2 Basic2 Service"


> Windows service fails to start after Windows 10 Creators Update
> ---
>
> Key: DAEMON-367
> URL: https://issues.apache.org/jira/browse/DAEMON-367
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 10 Home and Pro after Creators Update. Windows 
> version 10.0.15063 Build 15063
>Reporter: Dave Bennett
>  Labels: prunsrv, windows10
>
> I have been running windows services via prunsrv for quite a long time 
> without any problem. Since updating my PC (Windows 10 Home) recently with the 
> Creators Update version of Windows 10 any new service that I install will not 
> start. Similar services that were installed prior to the update work ok as 
> before. When I try to start a new service, the system event log contains the 
> message "The BSS2SRVB2 service terminated with the following service-specific 
> error: Incorrect function". The service was initially configured with 
> PR_LOGLEVEL set to "Error" and no log files were created. When I set the 
> level to "Debug", the following log files were created,
> - stderrb2.txt contains,
> 2017-06-29 08:45:34 Commons Daemon procrun stderr initialized
> - stdoutb2.txt contains,
> 2017-06-29 08:45:34 Commons Daemon procrun stdout initialized
> - commons-daemon.2017-06-29.log contains,
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:1679) [20104] Commons Daemon 
> procrun log initialized
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1683) [20104] Commons Daemon 
> procrun (1.0.15.0 32-bit) started
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1596) [20104] Running 'BSS2SRVB2' 
> Service...
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:1374) [19220] Inside ServiceMain...
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:844 ) [19220] reportServiceStatusE: 
> 2, 0, 3000, 0
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1127) [19220] Starting service...
> [2017-06-29 08:45:34] [error] ( prunsrv.c:1190) [19220] Missing service 
> ImageFile
> [2017-06-29 08:45:34] [error] ( prunsrv.c:1536) [19220] ServiceStart returned 
> 1
> [2017-06-29 08:45:34] [debug] ( prunsrv.c:844 ) [19220] reportServiceStatusE: 
> 1, 1066, 0, 1
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1598) [20104] Run service finished.
> [2017-06-29 08:45:34] [info]  ( prunsrv.c:1764) [20104] Commons Daemon 
> procrun finished
> The service processes have been written by myself in Java. 
> I have also seen the same problem on another PC (Windows 10 Pro) so this 
> suggests that it is not specific to my PC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)