[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-93:


Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/54
  

[![Coverage 
Status](https://:/builds/12097991/badge)](https://:/builds/12097991)

Coverage decreased (-0.02%) to 97.308% when pulling 
**f9177e204d608e7fa708d57fabf0029746f7774a on ameyjadiye:TEXT-93** into 
**569dbc09402a6f28334936567a597e3d0db9185c on apache:master**.



> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



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

[jira] [Commented] (DAEMON-366) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)

[Consultant Leon (JIRA)]

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

Consultant Leon commented on DAEMON-366:


Service is installed with the following settings:
 //IS//%SERVICE_NAME% ^
--Description="FusionFabric Connect (%APP_CONF%)" ^
--DisplayName="%SERVICE_NAME%" ^
--LogPath="%APP_LOGDIR%" ^
--StdOutput=auto ^
--StdError=auto ^
--Jvm="%JAVA_DLL_PATH%" ^
--JvmMs=512 ^
--JvmMx=8192 ^
++JvmOptions=-XX:+UseConcMarkSweepGC ^
++JvmOptions=-XX:MaxGCPauseMillis=2000 ^
++JvmOptions=-XX:GCTimeRatio=10 ^
++JvmOptions=-XX:+CMSIncrementalMode ^
++JvmOptions=-XX:+CMSIncrementalPacing ^
++JvmOptions=-XX:+DisableExplicitGC ^
++JvmOptions="-DAPP.LOG_DIR=%APP_LOGDIR%" ^
++JvmOptions="-DAPP.DATA_DIR=%APP_DATA%" ^
--StartMode=jvm ^
--StopMode=jvm ^
--StartClass=com.misys.tools.integration.director.WindowsServiceWrapper ^
--StopClass=com.misys.tools.integration.director.WindowsServiceWrapper ^
--StartPath="%APP_CONF%" ^
--StartParams="%SERVICE_NAME%" ^
++StartParams="%APP_LOGDIR%" ^
++StartParams=director.properties ^
%ARGS% ^
--StartMethod=start ^
--StopParams=%SERVICE_NAME% ^
--StopMethod=stop

> CLONE - Windows service fails to stop with error code 1053 (using Windows 7 
> service manager)
> 
>
> Key: DAEMON-366
> URL: https://issues.apache.org/jira/browse/DAEMON-366
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 7 64bit - using 64-bit prunsrv.exe in jvm mode
> Using 64-bit Java JRE 1.8.0_73
>Reporter: Consultant Leon
>Assignee: Guillaume Chauvet
>  Labels: prunsrv, stop, windows
>
> Using Windows services manager (services.msc) to start/stop service.
> Service installed with the following start/stop settings.
> --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start 
> --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop 
> Service starts OK.
> When I use services manager to stop the service, the application stops 
> running but the prunsrv.exe process does not terminate.
> Eventually the services manager reports that:
> "Windows could not stop the  service on Local Computer.  Error 
> 1053: The service did not respond to the start or control request in a timely 
> fashion."
> The service then stays at status "stopping" & cannot be restarted without 
> first killing the prunsrv.exe process.
> Looking at the application logs I can see that the application's stop() 
> method gets called - the final line in this method is a logging call which is 
> executing OK.
> The commons-daemon-.log file has the following entries:
> [2013-05-09 17:18:02] [info]  [10944] Commons Daemon procrun (1.0.15.0 
> 32-bit) started
> [2013-05-09 17:18:02] [info]  [10944] Running '' Service...
> [2013-05-09 17:18:02] [info]  [ 9224] Starting service...
> [2013-05-09 17:18:11] [info]  [ 9224] Service started in 9202 ms.
> [2013-05-09 17:18:23] [info]  [10780] Stopping service...
> [2013-05-09 17:18:24] [info]  [10780] Service stop thread completed.
> This problem does not occur in daemon versions 11->14.
> I have only seen it in daemon-1.0.15



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

[jira] [Updated] (DAEMON-366) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)

[Consultant Leon (JIRA)]

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

Consultant Leon updated DAEMON-366:
---
Environment: 
Windows 7 64bit - using 64-bit prunsrv.exe in jvm mode
Using 64-bit Java JRE 1.8.0_73

  was:
Windows 7 64bit - using 32-bit prunsrv.exe in jvm mode
Using 32-bit Java JRE 1.7.0_17


> CLONE - Windows service fails to stop with error code 1053 (using Windows 7 
> service manager)
> 
>
> Key: DAEMON-366
> URL: https://issues.apache.org/jira/browse/DAEMON-366
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.15
> Environment: Windows 7 64bit - using 64-bit prunsrv.exe in jvm mode
> Using 64-bit Java JRE 1.8.0_73
>Reporter: Consultant Leon
>Assignee: Guillaume Chauvet
>  Labels: prunsrv, stop, windows
>
> Using Windows services manager (services.msc) to start/stop service.
> Service installed with the following start/stop settings.
> --StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start 
> --StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop 
> Service starts OK.
> When I use services manager to stop the service, the application stops 
> running but the prunsrv.exe process does not terminate.
> Eventually the services manager reports that:
> "Windows could not stop the  service on Local Computer.  Error 
> 1053: The service did not respond to the start or control request in a timely 
> fashion."
> The service then stays at status "stopping" & cannot be restarted without 
> first killing the prunsrv.exe process.
> Looking at the application logs I can see that the application's stop() 
> method gets called - the final line in this method is a logging call which is 
> executing OK.
> The commons-daemon-.log file has the following entries:
> [2013-05-09 17:18:02] [info]  [10944] Commons Daemon procrun (1.0.15.0 
> 32-bit) started
> [2013-05-09 17:18:02] [info]  [10944] Running '' Service...
> [2013-05-09 17:18:02] [info]  [ 9224] Starting service...
> [2013-05-09 17:18:11] [info]  [ 9224] Service started in 9202 ms.
> [2013-05-09 17:18:23] [info]  [10780] Stopping service...
> [2013-05-09 17:18:24] [info]  [10780] Service stop thread completed.
> This problem does not occur in daemon versions 11->14.
> I have only seen it in daemon-1.0.15



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

[jira] [Commented] (DAEMON-366) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)

[Consultant Leon (JIRA)]

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

Consultant Leon commented on DAEMON-366:


as with all other reporters confirming this bug it's exactly as stated and easy 
to reproduce for me.
The moment we upgraded to a > 1.0.14 tomcat8.exe or tomcat7.exe from a tomcat > 
7.0.39 , the shutdown of the service failed.
The java process terminated nicely and the console reports thread ended but 
tomcat7/8 .exe remains running.

[2017-06-23 04:18:27] [info]  [ 9392] Commons Daemon procrun (1.0.15.0 64-bit) 
started
[2017-06-23 04:18:27] [info]  [ 9392] Running 'HelloWorld6' Service...
[2017-06-23 04:18:27] [info]  [ 1500] Starting service...
[2017-06-23 04:18:28] [info]  [ 1500] Service started in 1270 ms.
[2017-06-23 04:18:36] [info]  [12796] Stopping service...
[2017-06-23 04:18:37] [info]  [12796] Service stop thread completed.

... D:\application\bin\win\AMD64 
$ sc queryex HelloWorld6



SERVICE_NAME: HelloWorld6   

TYPE   : 10  WIN32_OWN_PROCESS  

STATE  : 1  STOPPED 

WIN32_EXIT_CODE: 0  (0x0)   

SERVICE_EXIT_CODE  : 0  (0x0)   

CHECKPOINT : 0x0

WAIT_HINT  : 0x0

PID: 0  

FLAGS  :



... D:\application\bin\win\AMD64 
$ sc start HelloWorld6  



SERVICE_NAME: HelloWorld6   

TYPE   : 10  WIN32_OWN_PROCESS  

STATE  : 2  START_PENDING   

(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN) 

WIN32_EXIT_CODE: 0  (0x0)   

SERVICE_EXIT_CODE  : 0  (0x0)   

CHECKPOINT : 0x0

WAIT_HINT  : 0x7d0  

PID: 11384  

FLAGS  :



... D:\application\bin\win\AMD64 
$ sc queryex HelloWorld6



SERVICE_NAME: HelloWorld6   

TYPE   : 10  WIN32_OWN_PROCESS  

STATE  : 4  RUNNING 

(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN) 

WIN32_EXIT_CODE: 0  (0x0)   

SERVICE_EXIT_CODE  : 0  (0x0)   

CHECKPOINT : 0x0

WAIT_HINT  : 0x0

PID: 11384  

FLAGS  :



... D:\application\bin\win\AMD64 
$ sc stop 

[jira] [Created] (DAEMON-366) CLONE - Windows service fails to stop with error code 1053 (using Windows 7 service manager)

[Consultant Leon (JIRA)]

Consultant Leon created DAEMON-366:
--

 Summary: CLONE - Windows service fails to stop with error code 
1053 (using Windows 7 service manager)
 Key: DAEMON-366
 URL: https://issues.apache.org/jira/browse/DAEMON-366
 Project: Commons Daemon
  Issue Type: Bug
  Components: Procrun
Affects Versions: 1.0.15
 Environment: Windows 7 64bit - using 32-bit prunsrv.exe in jvm mode
Using 32-bit Java JRE 1.7.0_17
Reporter: Consultant Leon
Assignee: Guillaume Chauvet


Using Windows services manager (services.msc) to start/stop service.
Service installed with the following start/stop settings.
--StartMode=jvm --StartClass=com.myorg.MyClass --StartMethod=start 
--StopMode=jvm --StopClass=com.myorg.MyClass --StopMethod=stop 

Service starts OK.

When I use services manager to stop the service, the application stops running 
but the prunsrv.exe process does not terminate.
Eventually the services manager reports that:
"Windows could not stop the  service on Local Computer.  Error 
1053: The service did not respond to the start or control request in a timely 
fashion."

The service then stays at status "stopping" & cannot be restarted without first 
killing the prunsrv.exe process.

Looking at the application logs I can see that the application's stop() method 
gets called - the final line in this method is a logging call which is 
executing OK.

The commons-daemon-.log file has the following entries:
[2013-05-09 17:18:02] [info]  [10944] Commons Daemon procrun (1.0.15.0 32-bit) 
started
[2013-05-09 17:18:02] [info]  [10944] Running '' Service...
[2013-05-09 17:18:02] [info]  [ 9224] Starting service...
[2013-05-09 17:18:11] [info]  [ 9224] Service started in 9202 ms.
[2013-05-09 17:18:23] [info]  [10780] Stopping service...
[2013-05-09 17:18:24] [info]  [10780] Service stop thread completed.


This problem does not occur in daemon versions 11->14.
I have only seen it in daemon-1.0.15




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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12096355/badge)](https://:/builds/12096355)

Coverage increased (+0.04%) to 84.767% when pulling 
**368cb1b7520f78803772b5eff4b28622432479d8 on 
sesuncedu:COMPRESS-407-SYSTEM-PROPERTY** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 on apache:master**.



> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12096330/badge)](https://:/builds/12096330)

Coverage decreased (-0.02%) to 84.704% when pulling 
**abab94288a8b8de05ecfade6517456a2c8dc6fb2 on sesuncedu:COMPRESS-407-WARN** 
into **4be9979b45ceadc50dc24607884d34613fead1f5 on apache:master**.



> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/42
  
The system property is can be discovered by reading the source code. This 
information could be added to the exception message. 


> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

GitHub user sesuncedu opened a pull request:

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

COMPRESS-407:  Allow use of invalid record sizes if a system property is 
set.

I do not recommend using this approach.  #40 is the preferred solution. 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress 
COMPRESS-407-SYSTEM-PROPERTY

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/42.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 #42


commit f0c21325faf6f613821a8b542c73ac380f0feb6a
Author: Simon Spero 
Date:   2017-06-11T22:48:42Z

COMPRESS-407 Validate Block and Record Sizes

Require block size >=0 that is multiple of 512 bytes.
Use block size of 512 if one is not given.
Require record size of 512 bytes. Deprecate constructors taking recordSize 
as parameter

Modify tests to check for enforcement of record size == 512
Modify tests to check for correct overall length  for
different block sizes including PAX default, USTAR default, and unspecified.

Signed-off-by: Simon Spero 

(cherry picked from commit d754d89)
Signed-off-by: Simon Spero 

commit 368cb1b7520f78803772b5eff4b28622432479d8
Author: Simon Spero 
Date:   2017-06-23T00:50:13Z

COMPRESS-407 Validate Block sizes. Detect invalid record sizes. Allow them 
through if a
system property is set.

Signed-off-by: Simon Spero 




> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

GitHub user sesuncedu opened a pull request:

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

COMPRESS-407 - Just Warn

Warn if an invalid record size is set. 

I would not recommend using this approach.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-407-WARN

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/41.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 #41


commit f0c21325faf6f613821a8b542c73ac380f0feb6a
Author: Simon Spero 
Date:   2017-06-11T22:48:42Z

COMPRESS-407 Validate Block and Record Sizes

Require block size >=0 that is multiple of 512 bytes.
Use block size of 512 if one is not given.
Require record size of 512 bytes. Deprecate constructors taking recordSize 
as parameter

Modify tests to check for enforcement of record size == 512
Modify tests to check for correct overall length  for
different block sizes including PAX default, USTAR default, and unspecified.

Signed-off-by: Simon Spero 

(cherry picked from commit d754d89)
Signed-off-by: Simon Spero 

commit abab94288a8b8de05ecfade6517456a2c8dc6fb2
Author: Simon Spero 
Date:   2017-06-23T00:35:13Z

COMPRESS-407 Validate Block sizes. Detect invalid record sizes, but just 
log a  warning.

Signed-off-by: Simon Spero 




> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (RNG-31) Missing signature and checksum files (release process)

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060252#comment-16060252
 ] 

Sebb commented on RNG-31:
-

Checksums are only needed for releases, so aren't normally generated.

You probably need to deploy the component.

http://commons.apache.org/releases/prepare.html#Create_the_Release_Candidate

Also have a look at MATH; IIRC that had extensive build instructions

> Missing signature and checksum files (release process)
> --
>
> Key: RNG-31
> URL: https://issues.apache.org/jira/browse/RNG-31
> Project: Commons RNG
>  Issue Type: Sub-task
>Reporter: Gilles
> Fix For: 1.1
>
>
> Module "dist-archive" contains a
> {noformat}
> src/assembly
> {noformat}
> directory for  creating distribution files.
> The command
> {noformat}
> mvn assembly:single
> {noformat}
> create the "tar.gz" and ".zip" files but not the corresponding ".asc", ".md5" 
> and ".sha1" files.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12096032/badge)](https://:/builds/12096032)

Coverage increased (+0.05%) to 84.777% when pulling 
**f0c21325faf6f613821a8b542c73ac380f0feb6a on sesuncedu:COMPRESS-407-REDUX** 
into **4be9979b45ceadc50dc24607884d34613fead1f5 on apache:master**.



> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

GitHub user sesuncedu opened a pull request:

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

COMPRESS-407 Validate Block and Record Sizes

Original (require correct record size) 

Require block size >=0 that is multiple of 512 bytes.
Use block size of 512 if one is not given.
Require record size of 512 bytes. Deprecate constructors taking recordSize 
as parameter

Modify tests to check for enforcement of record size == 512
Modify tests to check for correct overall length  for
different block sizes including PAX default, USTAR default, and unspecified.

Signed-off-by: Simon Spero 

(cherry picked from commit d754d89)
Signed-off-by: Simon Spero 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-407-REDUX

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/40.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 #40


commit f0c21325faf6f613821a8b542c73ac380f0feb6a
Author: Simon Spero 
Date:   2017-06-11T22:48:42Z

COMPRESS-407 Validate Block and Record Sizes

Require block size >=0 that is multiple of 512 bytes.
Use block size of 512 if one is not given.
Require record size of 512 bytes. Deprecate constructors taking recordSize 
as parameter

Modify tests to check for enforcement of record size == 512
Modify tests to check for correct overall length  for
different block sizes including PAX default, USTAR default, and unspecified.

Signed-off-by: Simon Spero 

(cherry picked from commit d754d89)
Signed-off-by: Simon Spero 




> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12095979/badge)](https://:/builds/12095979)

Changes Unknown when pulling **ace4d5da8bd8504e884d139abf6f34ab4b5dd99d on 
sesuncedu:COMPRESS-407** into ** on apache:master**.



> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on RNG-38:
---

Github user coveralls commented on the issue:

https://github.com/apache/commons-rng/pull/3
  

[![Coverage 
Status](https://:/builds/12095968/badge)](https://:/builds/12095968)

Coverage remained the same at 96.934% when pulling 
**fc42e1d03ef2232ee243d9a1a7cd2db37b22ba14 on C0rWin:RNG-38** into 
**acb61071ae681732a5d70e6d2587dc95a6eb64d4 on apache:master**.



> 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] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user sesuncedu closed the pull request at:

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


> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (COMPRESS-407) Validate Block and Record Sizes

[Simon Spero (JIRA)]

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

Simon Spero commented on COMPRESS-407:
--

It is definitely an error to attempt to create a PAX or USTAR format file a 
record size that is not 512 bytes. Any attempt to use a PAX or USTAR feature 
with a record size not equal to 512 bytes will have to be modified to throw an 
exception. 

[The tar format documentation in libarchive| 
https://github.com/libarchive/libarchive/blob/master/libarchive/tar.5]  shows 
that this goes all the way back to V7.

{panel:title=tar (5) }
*General Format*

A tar archive consists of a series of 512-byte records.  Each file system 
object requires a header record which stores basic metadata (pathname, owner, 
permissions, etc.) and zero or more records containing any file data.  The end 
of the archive is indicated by two records consisting  entirely of zero bytes.

 For compatibility with tape drives that use fixed block sizes, programs 
that read or write tar files always read or write a fixed number of records 
with each I/O operation.  These “blocks” are always a multiple of the record 
size.  The maximum block size supported by early implementations was 10240 
bytes or 20 records.  This is still the default for most implementations 
although block sizes of 1MiB (2048 records) or larger are commonly used with 
modern high-speed tape drives.  (Note: the terms “block” and “record” here are 
not entirely standard; this document follows the convention established by John 
Gilmore in documenting pdtar.)
{panel}
 
If alternative record sizes are to be permitted then these will have to be 512 
bytes or greater in size.  If such uses are permitted then there needs to a 
warning logged. Which means there has to be logging added. 

I will add a second pull request on top of this one that adds a logging 
framework, reduces the errors to a  warning, and removes the tests. 
As an alternative, I will add a third pull request that uses a system property 
to enable invalid tar record sizes. 

I would still advise applying the PR as submitted and rejecting either of the 
above listed  alternatives.  

> Validate Block and Record Sizes
> ---
>
> Key: COMPRESS-407
> URL: https://issues.apache.org/jira/browse/COMPRESS-407
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>
> Reject record sizes not equal to 512 bytes; require block sizes to be 
> multiples of 512 bytes.



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

[jira] [Commented] (RNG-31) Missing signature and checksum files (release process)

[Artem Barger (JIRA)]

[ 
https://issues.apache.org/jira/browse/RNG-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060207#comment-16060207
 ] 

Artem Barger commented on RNG-31:
-

https://github.com/apache/commons-rng/pull/4

I've pushed PR which adds checksum plugging, hence to produces hash files for 
artifacts it has to be executed as 

```mvn clean assembly:single checksum:artifacts```

It turns that assembly plugging is not able to generate checksums.

> Missing signature and checksum files (release process)
> --
>
> Key: RNG-31
> URL: https://issues.apache.org/jira/browse/RNG-31
> Project: Commons RNG
>  Issue Type: Sub-task
>Reporter: Gilles
> Fix For: 1.1
>
>
> Module "dist-archive" contains a
> {noformat}
> src/assembly
> {noformat}
> directory for  creating distribution files.
> The command
> {noformat}
> mvn assembly:single
> {noformat}
> create the "tar.gz" and ".zip" files but not the corresponding ".asc", ".md5" 
> and ".sha1" files.



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

[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on JEXL-227:
-

Looking at Java 8 Nashorn;

{code:java}
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class Scripts {

public static void main(String[] args) {
ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
System.out.println("ENGINE: " + engine.getFactory().getEngineVersion());
System.out.println("LANGUAGE: " + 
engine.getFactory().getLanguageVersion());
}
}
{code}

Gives:

{noformat}
ENGINE: 1.8.0_131
LANGUAGE: ECMA - 262 Edition 5.1
{noformat}

So I believe in our case, the ENGINE_VERSION must match the version of JEXL. 
And Language should either match that version, or be 3.0 until there are 
changes that impact the language (in that case, we need to remember to update 
it should we add/remove features from the language).

>As a reminder, we may want to create a bug that we re-create after each 
>release stating 'verify getLanguageVersion/getEngineVersion before release'. 
>Otherwise, we'll probably keep forgetting about it...

Big +1 for that. Are you going to do that? Otherwise I can create the ticket, 
and assign to the next version, linking to this discussion, and asking the 
assignee to create a new one for the next release.

> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine 
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made 
> to this class
> }
> {code}



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

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

[Artem Barger (JIRA)]

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

Artem Barger reassigned RNG-38:
---

Assignee: Artem Barger

> 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] [Commented] (RNG-38) Wrong badge on Github

[Artem Barger (JIRA)]

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

Artem Barger commented on RNG-38:
-

https://github.com/apache/commons-rng/pull/3

> Wrong badge on Github
> -
>
> Key: RNG-38
> URL: https://issues.apache.org/jira/browse/RNG-38
> Project: Commons RNG
>  Issue Type: Bug
>Reporter: Gilles
>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] [Commented] (CONFIGURATION-258) JSON configuration

[The Alchemist (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060070#comment-16060070
 ] 

The Alchemist commented on CONFIGURATION-258:
-

[~garydgregory]: Jackson actually uses snakeyaml for YAML parsing 
(https://github.com/FasterXML/jackson-dataformats-text/blob/master/yaml/pom.xml#L32),
 so I decided to skip the middle-man to avoid introducing any unnecessary 
dependencies.

> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.2
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON  is a lightweight data-interchange format
> {code}
> {"menu": {
>   "id": "file",
>   "value": "File",
>   "popup": {
> "menuitem": [
>   {"value": "New", "onclick": "CreateNewDoc()"},
>   {"value": "Open", "onclick": "OpenDoc()"},
>   {"value": "Close", "onclick": "CloseDoc()"}
> ]
>   }
> }}
> {code}
> All references can be located at
> http://www.json.org/



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

[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Gilles (JIRA)]

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

Gilles commented on TEXT-93:


Amey,

Referring to the PR; this code
{code}
public Builder selectFromList(List characterList) {
this.characterList = characterList;
return this;
}
{code}
is unsafe; better make a defensive copy (like for the {{char[]}} version).


> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



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

[jira] [Commented] (CONFIGURATION-258) JSON configuration

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16060047#comment-16060047
 ] 

Gary Gregory commented on CONFIGURATION-258:


I see that JSON/YAML support introduced a dep on snakeyaml. Can't we get 
JSON/YAML support through Jackson instead?

> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.2
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON  is a lightweight data-interchange format
> {code}
> {"menu": {
>   "id": "file",
>   "value": "File",
>   "popup": {
> "menuitem": [
>   {"value": "New", "onclick": "CreateNewDoc()"},
>   {"value": "Open", "onclick": "OpenDoc()"},
>   {"value": "Close", "onclick": "CloseDoc()"}
> ]
>   }
> }}
> {code}
> All references can be located at
> http://www.json.org/



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

[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-93:


Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/54
  

[![Coverage 
Status](https://:/builds/12093960/badge)](https://:/builds/12093960)

Coverage decreased (-0.02%) to 97.306% when pulling 
**2dfadf4f8b51ae65d1b1b1f17afa3387b908c31f on ameyjadiye:TEXT-93** into 
**569dbc09402a6f28334936567a597e3d0db9185c on apache:master**.



> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



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

[jira] [Closed] (CONFIGURATION-669) Update optional Spring dependency from 4.2.5.RELEASE to 4.3.9.RELEASE

[Gary Gregory (JIRA)]

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

Gary Gregory closed CONFIGURATION-669.
--
   Resolution: Fixed
Fix Version/s: 2.2

{noformat}
commit -m "[CONFIGURATION-669] Update optional Spring dependency from 
4.2.5.RELEASE to 4.3.9.RELEASE." -N 
C:/vcs/svn/apache/commons/trunks-proper/configuration/src/changes/changes.xml 
C:/vcs/svn/apache/commons/trunks-proper/configuration/pom.xml
SendingC:/vcs/svn/apache/commons/trunks-proper/configuration/pom.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/configuration/src/changes/changes.xml
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1799628.
{noformat}


> Update optional Spring dependency from 4.2.5.RELEASE to 4.3.9.RELEASE
> -
>
> Key: CONFIGURATION-669
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-669
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.1.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.2
>
>
> Update optional Spring dependency from 4.2.5.RELEASE to 4.3.9.RELEASE.



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

[jira] [Created] (CONFIGURATION-669) Update optional Spring dependency from 4.2.5.RELEASE to 4.3.9.RELEASE

[Gary Gregory (JIRA)]

Gary Gregory created CONFIGURATION-669:
--

 Summary: Update optional Spring dependency from 4.2.5.RELEASE to 
4.3.9.RELEASE
 Key: CONFIGURATION-669
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-669
 Project: Commons Configuration
  Issue Type: Task
Affects Versions: 2.1.1
Reporter: Gary Gregory
Assignee: Gary Gregory


Update optional Spring dependency from 4.2.5.RELEASE to 4.3.9.RELEASE.



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

[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-93:


GitHub user ameyjadiye opened a pull request:

https://github.com/apache/commons-text/pull/54

TEXT-93: RandomStringGenerator accepts a list of valid characters

Added selectFrom feature : 
```
selectFromList(char[] chars)
selectFromList(List charList)
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ameyjadiye/commons-text TEXT-93

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-text/pull/54.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 #54


commit 278f1e0fb553fc2d2d6f5563d9e61899776cd80d
Author: Amey Jadiye 
Date:   2017-06-22T21:18:11Z

TEXT-93: RandomStringGenerator accepts a list of valid characters




> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
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=16060024#comment-16060024
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/39
  
Randomly adding  coverage tests  for coveralls


> 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=16060022#comment-16060022
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12093740/badge)](https://:/builds/12093740)

Coverage increased (+0.1%) to 84.828% when pulling 
**a434e5866df38e4b1f089c280f0b1a784e41a86d on sesuncedu:COMPRESS-413** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 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=16060019#comment-16060019
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user sesuncedu closed the pull request at:

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


> 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=16060020#comment-16060020
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

GitHub user sesuncedu reopened a pull request:

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

COMPRESS-413:  Performance improvements for Travis builds 

Change travis configuration to
- skip pre-build install (which runs the install goal).
- remove after_success code.
- use mvnw to use up-to-date version of maven.
- run all goals/phases previously included in after_sucess phase, using 
-Ptravis-jacoco profile if one exists.
  - clean
  - apache-rat:check
  - test
  - jacoco:report
  - coveralls:report

  - This will fail the build if any of the above goals fail. The goals that 
are most likely to fail are: apache-rat:check and test. coveralls configuration 
is changed in pom to not fail the build if the service is not available (e.g. 
for forks that do not have repository registered with coveralls).

 -  Note that the apache-rat: check could be added to the pom (executing by 
default in the validate phase)
 -  Also note that the jacoco:check goal can  be added to the pom 
(executing by default in the verify phase).
 -  the script could then be changed to execute the verify goal.
 - coveralls stuff could be run in an after_success script. That script 
could restrict coveralls notification to a single point in the jdk matrix


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-413

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/39.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 #39


commit ed024e9a6de41f72655674f0c7cdcce5700cf82d
Author: Simon Spero 
Date:   2017-06-19T20:15:16Z

add mvnw

(cherry picked from commit 91a08f4)
Signed-off-by: Simon Spero 

commit 8d543fd017f5c963f25541109fd48ceba1e0666c
Author: Simon Spero 
Date:   2017-06-22T16:13:45Z

COMPRESS-413
Alter pom.xml:
- Add Simon Spero as contributor.
- change javadoc configuration to use  (lowercase e) instead 
of  (uppercase E).
  - see 
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#docencoding
- exclude .mvn/** from rat check (mvnw and mvnw.cmd are ok since they 
already have APL header).
- add plugin configuration for coveralls to pluginManagement. Set 
failOnServiceError to false to avoid breaking the build
if coveralls is not available

Signed-off-by: Simon Spero 

commit 95974fc671661244c83fdead2231f8367a67d2ba
Author: Simon Spero 
Date:   2017-06-22T17:00:13Z

COMPRESS-413
Change travis configuration to
- skip pre-build install (which runs the install goal).
- remove after_success code.
- use mvnw to use up-to-date version of maven.
- run all goals/phases previously included in after_sucess phase, using 
-Ptravis-jacoco profile if one exists.
  - clean
  - apache-rat:check
  - test
  - jacoco:report
  - coveralls:report

  - This will fail the build if any of the above goals fail. The goals that 
are most likely to fail are: apache-rat:check and test. coveralls configuration 
is changed in pom to not fail the build if the service is not available (e.g. 
for forks that do not have repository registered with coveralls).

 -  Note that the apache-rat: check could be added to the pom (executing by 
default in the validate phase)
 -  Also note that the jacoco:check goal can  be added to the pom 
(executing by default in the verify phase).
 -  the script could then be changed to execute the verify goal.
 - coveralls stuff could run in a after_success script that checked and 
only ran for a selected jdk

Signed-off-by: Simon Spero 

commit 7b4ecc9e7c9d2fb32ddfe4f92791aacf9f17d901
Author: Simon Spero 
Date:   2017-06-22T18:32:48Z

Switch to trusty container.
Use only openjdk7 and openjdk8 as jdks

Signed-off-by: Simon Spero 

commit 0a61bfde39bb3e8122101622bb96ca918f85ebc7
Author: Simon Spero 
Date:   2017-06-22T18:42:00Z

Add comment to .travis.yml

Signed-off-by: Simon Spero 

commit a632a7f090ab8dc673fb57f22709bdaddf3ee802
Author: Simon Spero 
Date:   2017-06-22T20:12:56Z

Cover last two extra lines in ExplodingInputStream

Signed-off-by: Simon Spero 

commit 05b849faf0b1fee3d462b71d9e2c350ba791b06c
Author: Simon 

[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=16060018#comment-16060018
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12093695/badge)](https://:/builds/12093695)

Coverage increased (+0.09%) to 84.815% when pulling 
**a434e5866df38e4b1f089c280f0b1a784e41a86d on sesuncedu:COMPRESS-413** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 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] [Closed] (CONFIGURATION-667) Update Apache Commons Lang from 3.3.2 to 3.6.

[Gary Gregory (JIRA)]

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

Gary Gregory closed CONFIGURATION-667.
--
   Resolution: Fixed
Fix Version/s: 2.2

> Update Apache Commons Lang from 3.3.2 to 3.6.
> -
>
> Key: CONFIGURATION-667
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-667
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.1.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.2
>
>
> Update Apache Commons Lang from 3.3.2 to 3.6.



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

[jira] [Reopened] (CONFIGURATION-667) Update Apache Commons Lang from 3.3.2 to 3.6.

[Gary Gregory (JIRA)]

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

Gary Gregory reopened CONFIGURATION-667:


> Update Apache Commons Lang from 3.3.2 to 3.6.
> -
>
> Key: CONFIGURATION-667
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-667
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.1.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.2
>
>
> Update Apache Commons Lang from 3.3.2 to 3.6.



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

[jira] [Created] (CONFIGURATION-668) Update Apache Xerces from 2.6.2 to 2.11.0

[Gary Gregory (JIRA)]

Gary Gregory created CONFIGURATION-668:
--

 Summary: Update Apache Xerces from 2.6.2 to 2.11.0
 Key: CONFIGURATION-668
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-668
 Project: Commons Configuration
  Issue Type: Task
Affects Versions: 2.1.1
Reporter: Gary Gregory
Assignee: Gary Gregory


Update Apache Xerces from 2.6.2 to 2.11.0.



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

[jira] [Closed] (CONFIGURATION-667) Update Apache Commons Lang from 3.3.2 to 3.6.

[Gary Gregory (JIRA)]

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

Gary Gregory closed CONFIGURATION-667.
--
Resolution: Fixed

In SVN.

> Update Apache Commons Lang from 3.3.2 to 3.6.
> -
>
> Key: CONFIGURATION-667
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-667
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.1.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Update Apache Commons Lang from 3.3.2 to 3.6.



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

[jira] [Created] (CONFIGURATION-667) Update Apache Commons Lang from 3.3.2 to 3.6.

[Gary Gregory (JIRA)]

Gary Gregory created CONFIGURATION-667:
--

 Summary: Update Apache Commons Lang from 3.3.2 to 3.6.
 Key: CONFIGURATION-667
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-667
 Project: Commons Configuration
  Issue Type: Task
Affects Versions: 2.1.1
Reporter: Gary Gregory
Assignee: Gary Gregory


Update Apache Commons Lang from 3.3.2 to 3.6.



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

[jira] [Commented] (CONFIGURATION-258) JSON configuration

[The Alchemist (JIRA)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059941#comment-16059941
 ] 

The Alchemist commented on CONFIGURATION-258:
-

[~oliver.he...@t-online.de]: Thanks much!  In the contributors section, I'd be 
perfectly happy with {{The Alchemist }}.

> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.2
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON  is a lightweight data-interchange format
> {code}
> {"menu": {
>   "id": "file",
>   "value": "File",
>   "popup": {
> "menuitem": [
>   {"value": "New", "onclick": "CreateNewDoc()"},
>   {"value": "Open", "onclick": "OpenDoc()"},
>   {"value": "Close", "onclick": "CloseDoc()"}
> ]
>   }
> }}
> {code}
> All references can be located at
> http://www.json.org/



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

[jira] [Resolved] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher resolved TEXT-90.
---
Resolution: Fixed

> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic 
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator 
> today, but I found it hard to replace methods like 
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to 
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
> Edit:
> Added CharacterPredicates#ARABIC_NUMERALS, #ASCII_LOWERCASE_LETTERS, 
> #ASCII_UPPERCASE_LETTERS, #ASCII_LETTERS and #ASCII_ALPHA_NUMERALS.



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

[jira] [Commented] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-90:


Github user asfgit closed the pull request at:

https://github.com/apache/commons-text/pull/50


> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic 
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator 
> today, but I found it hard to replace methods like 
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to 
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
> Edit:
> Added CharacterPredicates#ARABIC_NUMERALS, #ASCII_LOWERCASE_LETTERS, 
> #ASCII_UPPERCASE_LETTERS, #ASCII_LETTERS and #ASCII_ALPHA_NUMERALS.



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

[jira] [Updated] (TEXT-90) Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic numerals

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher updated TEXT-90:
--
Description: 
I tried to migrate a project from RandomStringUtils to RandomStringGenerator 
today, but I found it hard to replace methods like 
RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.

I believe it would ease migration from RandomStringUtils to 
RandomStringGenerator if CharacterPrecidates would offer more predicates.

Edit:

Added CharacterPredicates#ARABIC_NUMERALS, #ASCII_LOWERCASE_LETTERS, 
#ASCII_UPPERCASE_LETTERS, #ASCII_LETTERS and #ASCII_ALPHA_NUMERALS.

  was:
I tried to migrate a project from RandomStringUtils to RandomStringGenerator 
today, but I found it hard to replace methods like 
RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.

I believe it would ease migration from RandomStringUtils to 
RandomStringGenerator if CharacterPrecidates would offer more predicates.


> Add CharacterPredicates for ASCII letters (uppercase/lowercase) and arabic 
> numerals
> ---
>
> Key: TEXT-90
> URL: https://issues.apache.org/jira/browse/TEXT-90
> Project: Commons Text
>  Issue Type: New Feature
>Reporter: Pascal Schumacher
>Assignee: Pascal Schumacher
> Fix For: 1.2
>
>
> I tried to migrate a project from RandomStringUtils to RandomStringGenerator 
> today, but I found it hard to replace methods like 
> RandomStringUtils#randomAlphanumeric and RandomStringUtils#randomAlphabetic.
> I believe it would ease migration from RandomStringUtils to 
> RandomStringGenerator if CharacterPrecidates would offer more predicates.
> Edit:
> Added CharacterPredicates#ARABIC_NUMERALS, #ASCII_LOWERCASE_LETTERS, 
> #ASCII_UPPERCASE_LETTERS, #ASCII_LETTERS and #ASCII_ALPHA_NUMERALS.



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

[jira] [Comment Edited] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher edited comment on TEXT-93 at 6/22/17 6:45 PM:


Thanks for the suggestion.

There is a bit of overlap with RandomStringGenerator#filteredBy.

With some work you can already archive this today, e.g.

{code}
Set characters = Stream.of('a', 'b', '0').map(i -> (int) 
i).collect(Collectors.toSet());
String str = new RandomStringGenerator.Builder().filteredBy(i -> 
characters.contains(i)).build().generate(5);{code}


was (Author: pascalschumacher):
Thanks for the suggestion.

There is a bit of overlap with RandomStringGenerator#filteredBy.

With some work you can already archive this today, e.g.

{code}
Set characters = Stream.of('a', 'b', 'c').map(i -> (int) 
i).collect(Collectors.toSet());
String str = new RandomStringGenerator.Builder().filteredBy(i -> 
characters.contains(i)).build().generate(5);{code}

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



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

[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher commented on TEXT-93:
---

I'm not opposed to adding a new method to make it easier.

I may be wrong, but I believe [~dmjones500] added 
RandomStringGenerator#filteredBy for this use cases like this. I agree that is 
a bit cumbersome to use (especially on java 7). (It's easier if you use the 
build-in CharacterPredicate of the CharacterPredicates class.)





> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



--
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=16059847#comment-16059847
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12091097/badge)](https://:/builds/12091097)

Coverage decreased (-0.008%) to 84.72% when pulling 
**0a61bfde39bb3e8122101622bb96ca918f85ebc7 on sesuncedu:COMPRESS-413** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 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

[Simon Spero (JIRA)]

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

Simon Spero commented on COMPRESS-413:
--

Switching to trusty container, and using  openjdk7 and openjdk8 as jdks
[Build stats| https://travis-ci.org/apache/commons-compress/builds/245906995]
-  Ran for 2 min 57 sec
-  Total time 4 min 12 sec

Note that the changed container means that caches for this build were reset. 


> 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=16059836#comment-16059836
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12090926/badge)](https://:/builds/12090926)

Coverage decreased (-0.008%) to 84.72% when pulling 
**7b4ecc9e7c9d2fb32ddfe4f92791aacf9f17d901 on sesuncedu:COMPRESS-413** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 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

[Simon Spero (JIRA)]

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

Simon Spero commented on COMPRESS-413:
--

Compare: 
[Master| https://travis-ci.org/apache/commons-compress/builds/244058294]
- Ran for 6 min 13 sec
- Total time 14 min 15 sec

[PR| https://travis-ci.org/apache/commons-compress/builds/245887614 ]
- Ran for 4 min 31 sec
- Total time 8 min 22 sec

Further,  Oracle JDK 7 hit EOL *over 2 years* ago! 
OpenJDK 7 has seen only sporadic patching, and is no longer part of any ubuntu 
LTS release. 

It is probably worth only testing under at most one of these environments 
(also, current tests run against  really, really old versions of jdk8)




> 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-93) RandomStringGenerator accepts a list of valid characters

[Amey Jadiye (JIRA)]

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

Amey Jadiye commented on TEXT-93:
-

Hi [~pascalschumacher]

Though your code is generating expected output this seems workaround to achieve 
Random String from given characters and user have to do lot of work himself. 
I'm in favour of having simple API given by [~erans] to which I can pass char 
array or char list and it will return Random String. what do you think ?

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



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

[jira] [Resolved] (CONFIGURATION-258) JSON configuration

[Oliver Heger (JIRA)]

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

Oliver Heger resolved CONFIGURATION-258.

   Resolution: Fixed
Fix Version/s: (was: 2.x)
   2.2

Patch applied with some changes in revision 1799599.

Thanks again. If you want to be added to the contributors section, please 
provide the data you want to get in.

> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.2
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON  is a lightweight data-interchange format
> {code}
> {"menu": {
>   "id": "file",
>   "value": "File",
>   "popup": {
> "menuitem": [
>   {"value": "New", "onclick": "CreateNewDoc()"},
>   {"value": "Open", "onclick": "OpenDoc()"},
>   {"value": "Close", "onclick": "CloseDoc()"}
> ]
>   }
> }}
> {code}
> All references can be located at
> http://www.json.org/



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

[jira] [Resolved] (CONFIGURATION-656) YAML Configuration

[Oliver Heger (JIRA)]

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

Oliver Heger resolved CONFIGURATION-656.

   Resolution: Fixed
Fix Version/s: 2.2

Patch applied with some changes in revision 1799599.

> YAML Configuration
> --
>
> Key: CONFIGURATION-656
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-656
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: Format
>Reporter: Gary Gregory
> Fix For: 2.2
>
>
> Like the missing JSON Configuration, we really should also support YAML.



--
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=16059741#comment-16059741
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

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

[![Coverage 
Status](https://:/builds/12090041/badge)](https://:/builds/12090041)

Coverage remained the same at 84.728% when pulling 
**95974fc671661244c83fdead2231f8367a67d2ba on sesuncedu:COMPRESS-413** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 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=16059730#comment-16059730
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-

GitHub user sesuncedu opened a pull request:

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

COMPRESS-413:  Performance improvements for Travis builds 

Change travis configuration to
- skip pre-build install (which runs the install goal).
- remove after_success code.
- use mvnw to use up-to-date version of maven.
- run all goals/phases previously included in after_sucess phase, using 
-Ptravis-jacoco profile if one exists.
  - clean
  - apache-rat:check
  - test
  - jacoco:report
  - coveralls:report

  - This will fail the build if any of the above goals fail. The goals that 
are most likely to fail are: apache-rat:check and test. coveralls configuration 
is changed in pom to not fail the build if the service is not available (e.g. 
for forks that do not have repository registered with coveralls).

 -  Note that the apache-rat: check could be added to the pom (executing by 
default in the validate phase)
 -  Also note that the jacoco:check goal can  be added to the pom 
(executing by default in the verify phase).
 -  the script could then be changed to execute the verify goal.
 - coveralls stuff could be run in an after_success script. That script 
could restrict coveralls notification to a single point in the jdk matrix


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-413

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/39.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 #39


commit ed024e9a6de41f72655674f0c7cdcce5700cf82d
Author: Simon Spero 
Date:   2017-06-19T20:15:16Z

add mvnw

(cherry picked from commit 91a08f4)
Signed-off-by: Simon Spero 

commit 8d543fd017f5c963f25541109fd48ceba1e0666c
Author: Simon Spero 
Date:   2017-06-22T16:13:45Z

COMPRESS-413
Alter pom.xml:
- Add Simon Spero as contributor.
- change javadoc configuration to use  (lowercase e) instead 
of  (uppercase E).
  - see 
https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#docencoding
- exclude .mvn/** from rat check (mvnw and mvnw.cmd are ok since they 
already have APL header).
- add plugin configuration for coveralls to pluginManagement. Set 
failOnServiceError to false to avoid breaking the build
if coveralls is not available

Signed-off-by: Simon Spero 

commit 95974fc671661244c83fdead2231f8367a67d2ba
Author: Simon Spero 
Date:   2017-06-22T17:00:13Z

COMPRESS-413
Change travis configuration to
- skip pre-build install (which runs the install goal).
- remove after_success code.
- use mvnw to use up-to-date version of maven.
- run all goals/phases previously included in after_sucess phase, using 
-Ptravis-jacoco profile if one exists.
  - clean
  - apache-rat:check
  - test
  - jacoco:report
  - coveralls:report

  - This will fail the build if any of the above goals fail. The goals that 
are most likely to fail are: apache-rat:check and test. coveralls configuration 
is changed in pom to not fail the build if the service is not available (e.g. 
for forks that do not have repository registered with coveralls).

 -  Note that the apache-rat: check could be added to the pom (executing by 
default in the validate phase)
 -  Also note that the jacoco:check goal can  be added to the pom 
(executing by default in the verify phase).
 -  the script could then be changed to execute the verify goal.
 - coveralls stuff could run in a after_success script that checked and 
only ran for a selected jdk

Signed-off-by: Simon Spero 




> 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, 

[jira] [Commented] (TEXT-93) RandomStringGenerator accepts a list of valid characters

[Pascal Schumacher (JIRA)]

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

Pascal Schumacher commented on TEXT-93:
---

Thanks for the suggestion.

There is a bit of overlap with RandomStringGenerator#filteredBy.

With some work you can already archive this today, e.g.

{code}
Set characters = Stream.of('a', 'b', 'c').map(i -> (int) 
i).collect(Collectors.toSet());
String str = new RandomStringGenerator.Builder().filteredBy(i -> 
characters.contains(i)).build().generate(5);{code}

> RandomStringGenerator accepts a list of valid characters
> 
>
> Key: TEXT-93
> URL: https://issues.apache.org/jira/browse/TEXT-93
> Project: Commons Text
>  Issue Type: Wish
>Reporter: Wilson MacGyver
>
>  implement a "selectFrom" feature:
>   RandomStringGenerator gen = new RandomStringGenerator.Builder()
> .selectFrom(charArray)
> .build();
> so we can pass a list of valid characters



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

[jira] [Resolved] (DAEMON-365) Jsvc "Service killed by signal 11"

[Mark Thomas (JIRA)]

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

Mark Thomas resolved DAEMON-365.

Resolution: Invalid

If you follow the link for the workaround and read the background, all the 
evidence points to a faulty kernel update. The stacksize workaround  is the 
best interim solution.

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Commented] (DAEMON-365) Jsvc "Service killed by signal 11"

[Nicholas A Hunter (JIRA)]

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

Nicholas A Hunter commented on DAEMON-365:
--

Found this workaround: changing the stack size by passing in option: '-Xss1280k'

https://community.ubnt.com/t5/UniFi-Wireless/Unifi-Controller-and-Debian-8-kernel-upgrade/td-p/1967647



> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Commented] (DAEMON-365) Jsvc "Service killed by signal 11"

[Nicholas A Hunter (JIRA)]

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

Nicholas A Hunter commented on DAEMON-365:
--

Also having this problem as of very recently on new Ubuntu cloud server builds. 
Getting signal 11 and service never successfully starts, but has a process 
running that I have to kill. 

uname -a :
Linux ip-<...>-generic #170-Ubuntu SMP Wed Jun 14 09:04:33 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux

java -version
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)


+---
| Internal options:  4
|   "-Dcommons.daemon.process.id=2406" (0x)
|   "-Dcommons.daemon.process.parent=2185" (0x)
|   "-Dcommons.daemon.version=1.0.15-dev" (0x)
|   "abort" (0x004056f0)
+---
Service killed by signal 11
Waiting 60 s to prevent looping


> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Commented] (CLI-257) Allow partial parsing

[Johann Petrak (JIRA)]

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

Johann Petrak commented on CLI-257:
---

Sorry Benedikt Ritter, I somehow missed this reply. 
Maybe I should point out what the intended use of ignoring unrecognised options 
is: I have a situation where the same options list is passed on to several 
"option consumers" (separate modules), each knows which options it needs or 
optionally supports, but knows nothing about the options for other modules. 
This means that each module only is interested in their own options and each 
module parses the "command line"  with their own options definitions, expecting 
anything that does not match that definition to simply get ignored. Therefore 
there is no need to retrieve the unknown arguments, because those will be known 
arguments of another module. It is not straightforward to add something to just 
retrieve unknown arguments since the definition tells us a lot about *how* to 
retrieve them and by definition we do not have it. 

My patch above does have one other problem though: if ignore unknown options is 
enabled, then any value after an unknown option is interpreted as a positional 
argument. Positional arguments do not make a lot of sense if there are several 
consumers, but it would probably still be better to handle this slightly 
differently: instead, ignore all non-option tokens until a known option is 
encountered again, if at all. In the worst case this will also ignore any 
actual positional arguments if the last option is an unknown option, but again, 
positional arguments do not really make sense in this scenario.

If you think this would be a useful addition I will provide a modified patch.

> Allow partial parsing
> -
>
> Key: CLI-257
> URL: https://issues.apache.org/jira/browse/CLI-257
> Project: Commons CLI
>  Issue Type: Improvement
>Affects Versions: 1.3.1
> Environment: any
>Reporter: guai
> Attachments: commons-cli.diff
>
>
> commons cli can only throw exception or start skipping once it hit unknown 
> parameter.
> I need a way to tell it to start skip unknown arguments and save them 
> somewhere for later handling, but do handle known arguments to the end



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

[jira] [Comment Edited] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

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

Andrea edited comment on DAEMON-365 at 6/22/17 2:04 PM:


I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16  = { version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized 
= 0 '\000'
(gdb) print arg.options[0] }
$3 = { optionString = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/",
  extraInfo = 0x0 }
(gdb) print arg.options[1]
$4 optionString = 0x613c60 "-Dcommons.daemon.process.id=9448", extraInfo = 0x0
(gdb) print arg.options[2]
$5 optionString = 0x613c90 "-Dcommons.daemon.process.parent=9447", extraInfo = 
0x0
(gdb) print arg.options[3]
$6 optionString = 0x613cc0 "-Dcommons.daemon.version=1.0.15-dev", extraInfo = 
0x0
(gdb) print arg.options[4]
$7 optionString = 0x613cf0 "abort", extraInfo = 0x405730 
(gdb) print arg.nOptions
$11 = 5
{quote}


was (Author: alopumo):
I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16   version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 0 
'\000'
(gdb) print arg.options.extraInfo
$17 = (void *) 0x0
(gdb) print arg.options.optionString
$18 = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/"
{quote}

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Comment Edited] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

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

Andrea edited comment on DAEMON-365 at 6/22/17 2:04 PM:


I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16  =  version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 
0 '\000'
(gdb) print arg.options[0] 
$3 =  optionString = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/",
  extraInfo = 0x0 
(gdb) print arg.options[1]
$4 optionString = 0x613c60 "-Dcommons.daemon.process.id=9448", extraInfo = 0x0
(gdb) print arg.options[2]
$5 optionString = 0x613c90 "-Dcommons.daemon.process.parent=9447", extraInfo = 
0x0
(gdb) print arg.options[3]
$6 optionString = 0x613cc0 "-Dcommons.daemon.version=1.0.15-dev", extraInfo = 
0x0
(gdb) print arg.options[4]
$7 optionString = 0x613cf0 "abort", extraInfo = 0x405730 
(gdb) print arg.nOptions
$11 = 5
{quote}


was (Author: alopumo):
I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16  = { version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized 
= 0 '\000'
(gdb) print arg.options[0] }
$3 = { optionString = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/",
  extraInfo = 0x0 }
(gdb) print arg.options[1]
$4 optionString = 0x613c60 "-Dcommons.daemon.process.id=9448", extraInfo = 0x0
(gdb) print arg.options[2]
$5 optionString = 0x613c90 "-Dcommons.daemon.process.parent=9447", extraInfo = 
0x0
(gdb) print arg.options[3]
$6 optionString = 0x613cc0 "-Dcommons.daemon.version=1.0.15-dev", extraInfo = 
0x0
(gdb) print arg.options[4]
$7 optionString = 0x613cf0 "abort", extraInfo = 0x405730 
(gdb) print arg.nOptions
$11 = 5
{quote}

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Comment Edited] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

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

Andrea edited comment on DAEMON-365 at 6/22/17 1:31 PM:


I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16   version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 0 
'\000'
(gdb) print arg.options.extraInfo
$17 = (void *) 0x0
(gdb) print arg.options.optionString
$18 = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/"
{quote}


was (Author: alopumo):
I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
16 = {version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 0 
'\000'}
(gdb) print arg.options.extraInfo
$17 = (void *) 0x0
(gdb) print arg.options.optionString
$18 = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/"
{quote}

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Comment Edited] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

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

Andrea edited comment on DAEMON-365 at 6/22/17 1:30 PM:


I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
16 = {version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 0 
'\000'}
(gdb) print arg.options.extraInfo
$17 = (void *) 0x0
(gdb) print arg.options.optionString
$18 = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/"
{quote}


was (Author: alopumo):
I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16 = {version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 
0 '\000'}
(gdb) print arg.options.extraInfo
$17 = (void *) 0x0
(gdb) print arg.options.optionString
$18 = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/"
{quote}

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Comment Edited] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

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

Andrea edited comment on DAEMON-365 at 6/22/17 1:29 PM:


I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307, java_init function.

{quote}
bool java_init(arg_data *args, home_data *data)
{
 ...
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

{quote}
(gdb) print jvm
$14 = (JavaVM *) 0x0
(gdb) print env
$15 = (JNIEnv *) 0x0
(gdb) print arg
$16 = {version = 65540, nOptions = 5, options = 0x613b80, ignoreUnrecognized = 
0 '\000'}
(gdb) print arg.options.extraInfo
$17 = (void *) 0x0
(gdb) print arg.options.optionString
$18 = 0x613be0 
"-Djava.class.path=/usr/share/java/commons-daemon.jar:/home/myuser/commons-daemon-1.0.15-src/src/native/unix/native/"
{quote}


was (Author: alopumo):
I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307.

{quote}
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Created] (TEXT-94) Add Damerau option to Levenshtein edit distance

[Ulf Dittmer (JIRA)]

Ulf Dittmer created TEXT-94:
---

 Summary: Add Damerau option to Levenshtein edit distance
 Key: TEXT-94
 URL: https://issues.apache.org/jira/browse/TEXT-94
 Project: Commons Text
  Issue Type: Improvement
Affects Versions: 1.1
Reporter: Ulf Dittmer
Priority: Minor


Please add support for transpositions of two characters as defined by the 
Levenshtein-Damerau edit distance: 
https://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance

It's not hard to implement, and some code for it can be found as part of 
https://issues.apache.org/jira/browse/LUCENE-3662



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

[jira] [Commented] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

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

Andrea commented on DAEMON-365:
---

I debugged with gdb and found that the child process goes in segmentation fault 
in src/native/unix/native/java.c line 307.

{quote}
 symb = (jvm_create_t)dso_symbol(libh, "JNI_CreateJavaVM");
 ...
 ret = (*symb) (, , );   < line 307
{quote}

> Jsvc "Service killed by signal 11"
> --
>
> Key: DAEMON-365
> URL: https://issues.apache.org/jira/browse/DAEMON-365
> Project: Commons Daemon
>  Issue Type: Bug
> Environment: $ cat /etc/lsb-release 
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
> $ uname -a
> Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> $ jsvc --help
> [...]
> jsvc (Apache Commons Daemon) 1.0.15-dev
>Reporter: Andrea
>
> Jsvc is working fine on my machine and on other machines, however on a
> particular one, it is not working.
> In the logs I get "Service killed by signal 11".
> I am using a simple daemon for tests[1]. I compiled it
> with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
> is installed on Ubuntu 16.04 LTS with apt-get and it is version
> 1.0.15-dev.
> [1] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3
> When I run it in the logs I only get "Service killed by signal 11". I am using
> /usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
> /usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
> /tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
> -one -two
> Starting it with -debug, I get no much more[2].
> [2] 
> http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2
> I cannot stop it with -stop and I have to kill -9 it.
> What should I do?
> Do you have any idea?
> Thanks!



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

[jira] [Commented] (NUMBERS-45) Removal of isNaN() and isInfinite() methods from Complex class

[Gilles (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16059309#comment-16059309
 ] 

Gilles commented on NUMBERS-45:
---

Can't we keep them as syntactic sugar (with the Javadoc mentioning that _they 
must not be used within methods that aims to comply with the standard_)?

> Removal of isNaN() and isInfinite() methods from Complex class
> --
>
> Key: NUMBERS-45
> URL: https://issues.apache.org/jira/browse/NUMBERS-45
> Project: Commons Numbers
>  Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Eric Barnhill
>Priority: Minor
> Fix For: 1.0
>
>
> Complex() currently contains the methods isNaN() and isInfinite() which 
> return positive when either the real or the imaginary components of the 
> Complex number are infinite. They are principally used as a "short circuit" 
> in many of the methods, that is, isNaN() is checked and if true, Complex.NaN 
> is returned without further processing.
> isNaN() and isInfinite() should be removed from Complex. For the purposes of 
> ISO C standards, nearly all methods need to handle arguments and return 
> values in which either real or imaginary is NaN or Infinite, but not both. 
> Thus this quick "sanity check" prevents Commons from complying with ISO C 
> standards. 
> It is easy enough to check whether the fields Complex.real and 
> Complex.imaginary with Double.isNaN() or Double.isInfinite() if comparison is 
> desired.
> These methods then need to be removed from certain tests in ComplexTest which 
> call the isNaN() or isInfinite() methods. Most of these methods are 
> superseded by the new C standard tests anyway.



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

[jira] [Created] (NUMBERS-45) Removal of isNaN() and isInfinite() methods from Complex class

[Eric Barnhill (JIRA)]

Eric Barnhill created NUMBERS-45:


 Summary: Removal of isNaN() and isInfinite() methods from Complex 
class
 Key: NUMBERS-45
 URL: https://issues.apache.org/jira/browse/NUMBERS-45
 Project: Commons Numbers
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Eric Barnhill
Priority: Minor
 Fix For: 1.0


Complex() currently contains the methods isNaN() and isInfinite() which return 
positive when either the real or the imaginary components of the Complex number 
are infinite. They are principally used as a "short circuit" in many of the 
methods, that is, isNaN() is checked and if true, Complex.NaN is returned 
without further processing.

isNaN() and isInfinite() should be removed from Complex. For the purposes of 
ISO C standards, nearly all methods need to handle arguments and return values 
in which either real or imaginary is NaN or Infinite, but not both. Thus this 
quick "sanity check" prevents Commons from complying with ISO C standards. 

It is easy enough to check whether the fields Complex.real and 
Complex.imaginary with Double.isNaN() or Double.isInfinite() if comparison is 
desired.

These methods then need to be removed from certain tests in ComplexTest which 
call the isNaN() or isInfinite() methods. Most of these methods are superseded 
by the new C standard tests anyway.



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

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

[Derek Schenk (JIRA)]

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

Derek Schenk commented on DAEMON-363:
-

For reference the upstream kernel commit is :
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1be7107fbe18eed3e319a6c3e83c78254b693acb
I suspect as more people apply this kernel update the number of people affected 
will increase.

> 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

[jira] [Commented] (JEXL-224) The ability to overload call() operator in customized JexlArithmetic implementation

[Dmitri Blinov (JIRA)]

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

Dmitri Blinov commented on JEXL-224:


I have managed to achieve what I whanted by overriding 
{{Uberspect.getMethod()}} and implementing custom JexlMethod class

{code}

   protected class CollectionJexlMethod implements JexlMethod {

  public CollectionJexlMethod() {
  }

  @Override
  public Object invoke(Object obj, Object... params) throws Exception {
 if (obj instanceof Collection && params != null && params.length == 1) 
{
Collection c = (Collection) obj;
int i = TypeCast.getInt(params[0]);

for (Object o : c) {
   if (i-- == 0)
 return o;
}
 }

 return null;
  }

  @Override
  public Object tryInvoke(String name, Object obj, Object... params) {

 if (obj instanceof Collection && "call".equals(name) && params != null 
&& params.length == 1) {

Collection c = (Collection) obj;
int i = TypeCast.getInt(params[0]);

for (Object o : c) {
   if (i-- == 0)
 return o;
}
 }

 return JexlEngine.TRY_FAILED;
  }

  @Override
  public boolean tryFailed(Object rval) {
 return rval == JexlEngine.TRY_FAILED;
  }

  @Override
  public boolean isCacheable() {
 return true;
  }

  @Override
  public Class getReturnType() {
 return Object.class;
  }
   }

   @Override
   public JexlMethod getMethod(Object obj, String method, Object... args) {

  JexlMethod result = super.getMethod(obj, method, args);

  if (result == null) {

 if (obj instanceof Collection && "call".equals(method) && args != null 
&& args.length == 1) {
   result = new CollectionJexlMethod();
 }
  }
  return result;
   }

{code}

The code is not as eloquent as it would be with JEXL-224 implemented, but it 
seems to work and I don't know if the issue is still worth fixing

> The ability to overload call() operator in customized JexlArithmetic 
> implementation
> ---
>
> Key: JEXL-224
> URL: https://issues.apache.org/jira/browse/JEXL-224
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> As of now there is a possibility to overload some operators and property 
> accessors in JexlArithmetic, such as {{[]}}, {{.}} and {{~=}}, which is great 
> extension point of Jexl. Suppose I want to implement index-based access to a 
> {{j.u.Collection}} instance in a manner that {{a(0)}} would return the first 
> element of collection, {{a(1)}} would return the second and so forth. This is 
> different from using common access operator {{[]}} in a way that I specify 
> not the index key of for example ArrayList, but an ordered index of the 
> element. Of course, the is a possibility to introduce some function to this, 
> but for the sake of the scripting simplicity I'm looking for the short 
> version, like the call operator {{()}}. As of now I can only implement this 
> behavior for the classes that are written by me, via adding a call() method 
> to class declaration.But in the case of java.util.Collection this is not 
> possible. So it would be great if Jexl could allow to overload a call() 
> method in JexlArithmetic class in a way the propertyGet/arrayGet methods are 
> now can be overloaded.



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

[jira] [Comment Edited] (DAEMON-364) Latest RHEL kernel update crashes jsvc

[Sven Neuhaus (JIRA)]

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

Sven Neuhaus edited comment on DAEMON-364 at 6/22/17 11:58 AM:
---

This appears to be a duplicate of DAEMON-363.

The workaround of using the "-Xss2m" also works on Debian 8.8 (which is also 
affected).


was (Author: neuhaus):
This appears to be a duplicate of DAEMON-363

> Latest RHEL kernel update crashes jsvc
> --
>
> Key: DAEMON-364
> URL: https://issues.apache.org/jira/browse/DAEMON-364
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
>Reporter: Peter Walsh
>
> After applying the latest RHEL kernel updates (CVE-2017-1000364), all jsvc 
> instance crash on start up with the following:
>  {quote}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f0fcea07bdc, pid=28581, tid=0x7f0fdfc0c700
> #
> # 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
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core 
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # //hs_err_pid28581.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp{quote}
> Manually starting the service does not exhibit the problem.



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

[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=16059219#comment-16059219
 ] 

Sven Neuhaus commented on DAEMON-363:
-

This issue also affects Debian 8.8 kernel 3.16.43-2+deb8u1

Thanks for the workaround!

Also DAEMON-364 appears to be a duplicate of this issue.

> 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 

[jira] [Commented] (DAEMON-364) Latest RHEL kernel update crashes jsvc

[Sven Neuhaus (JIRA)]

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

Sven Neuhaus commented on DAEMON-364:
-

This appears to be a duplicate of DAEMON-363

> Latest RHEL kernel update crashes jsvc
> --
>
> Key: DAEMON-364
> URL: https://issues.apache.org/jira/browse/DAEMON-364
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Jsvc
>Affects Versions: 1.0.15
>Reporter: Peter Walsh
>
> After applying the latest RHEL kernel updates (CVE-2017-1000364), all jsvc 
> instance crash on start up with the following:
>  {quote}#
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0x7) at pc=0x7f0fcea07bdc, pid=28581, tid=0x7f0fdfc0c700
> #
> # 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
> #
> # Failed to write core dump. Core dumps have been disabled. To enable core 
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # //hs_err_pid28581.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp{quote}
> Manually starting the service does not exhibit the problem.



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

[jira] [Commented] (JEXL-227) JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 3.1 as of reporting

[Henri Biestro (JIRA)]

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

Henri Biestro commented on JEXL-227:


Checked the JSR 223; semantics on getLanguageVersion/getEngineVersion is not 
very detailed.
LANGUAGE_VERSION: Reserved key for the named value that identifies the version 
of the scripting language supported by the implementation.
ENGINE_VERSION: Reserved key for a named value that identifies the version of
the ScriptEngine implementation.

As a reminder, we may want to create a bug that we re-create after each release 
stating 'verify getLanguageVersion/getEngineVersion before release'. Otherwise, 
we'll probably keep forgetting about it...

> JexlScriptEngineFactory.getEngineVersion() should return actual version, ie 
> 3.1 as of reporting
> ---
>
> Key: JEXL-227
> URL: https://issues.apache.org/jira/browse/JEXL-227
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> JexlScriptEngineFactory.getEngineVersion() reports "3.0" as a script engine 
> version in 3.1
> {code}
> public String getEngineVersion() {
> return "3.0"; // ensure this is updated if function changes are made 
> to this class
> }
> {code}



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

[jira] [Created] (DAEMON-365) Jsvc "Service killed by signal 11"

[Andrea (JIRA)]

Andrea created DAEMON-365:
-

 Summary: Jsvc "Service killed by signal 11"
 Key: DAEMON-365
 URL: https://issues.apache.org/jira/browse/DAEMON-365
 Project: Commons Daemon
  Issue Type: Bug
 Environment: $ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"

$ uname -a
Linux server 4.4.0-81-generic #104-Ubuntu SMP Wed Jun 14 08:17:06 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

$ jsvc --help
[...]
jsvc (Apache Commons Daemon) 1.0.15-dev


Reporter: Andrea


Jsvc is working fine on my machine and on other machines, however on a
particular one, it is not working.

In the logs I get "Service killed by signal 11".

I am using a simple daemon for tests[1]. I compiled it
with javac -cp /usr/share/java/commons-daemon.jar MyDaemon.java. Jsvc
is installed on Ubuntu 16.04 LTS with apt-get and it is version
1.0.15-dev.

[1] 
http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/3

When I run it in the logs I only get "Service killed by signal 11". I am using
/usr/bin/jsvc -home /usr/lib/jvm/java-8-oracle/ -cp
/usr/share/java/commons-daemon.jar:$PWD/ -user myuser -pidfile
/tmp/mydaemon.pid -outfile /tmp/test.out.log -errfile '&1'  MyDaemon
-one -two

Starting it with -debug, I get no much more[2].

[2] 
http://mail-archives.apache.org/mod_mbox/commons-user/201706.mbox/raw/%3CCABxFBzGfNVFOzySFT1CTTwb56GXr1gLsdmU4vnJYKUUrexBzxQ%40mail.gmail.com%3E/2

I cannot stop it with -stop and I have to kill -9 it.

What should I do?
Do you have any idea?

Thanks!



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

[jira] [Commented] (VFS-637) Zip files with legacy encoding and special characters let VFS crash

[Guido Schnepp (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16058831#comment-16058831
 ] 

Guido Schnepp commented on VFS-637:
---

Not much, because both encodings differ from IBM437 in bigger parts: 

java.nio.charset.StandardCharsets.US-ASCII is a 7 bit charset only, so all 
characters 0x80 and above are missing. That's the most interesting part of 
codepage 437 for non-US people, where you also find the german umlauts for 
example.

ASCII (any) and ANSI (most) are 8 bit charsets which base on US-ASCII but have 
codepoints 0x80-0xFF defined - differently! On a sample with german umlaut Ä 
(Latin capital letter A with diaeresis) and ä (Latin small letter a with 
diaeresis):
IBM437:Ä on 0x8E, ä on 0x84 ( 
https://de.wikipedia.org/wiki/Codepage_437 )
ISO-8859-1: Ä on 0xC4, ä on 0xE4 ( https://de.wikipedia.org/wiki/ISO_8859-1 )
UNICODE:Ä on U+00C4, ä on U+00E4 ( https://de.wikipedia.org/wiki/Umlaut )
US-ASCII: Ä non existent, ä non existent

PKWare is only a vendor of ZIP aware products, but with pkzip one of the first, 
far before zip support has been added to operating systems or Java runtime 
natively. I by myself trust their expertise here. BUT: I've also read on other 
pages, that on development of the ZIP format, encoding was +not defined+ (or 
not in mind) in any way. The language encoding bit has been added later. So 
some functionality is required long-term to set the desired encoding as user 
like, because you can also find ZIP files with native russian characters inside 
potentially - which are even not supported by IBM437.

Another interesting source is the new Oracle Java Zip package javadoc: 
https://docs.oracle.com/javase/7/docs/api/java/util/zip/package-summary.html . 
The, in turn, refer to PKWare Appendix D already mentioned on Ticket above.

> Zip files with legacy encoding and special characters let VFS crash
> ---
>
> Key: VFS-637
> URL: https://issues.apache.org/jira/browse/VFS-637
> Project: Commons VFS
>  Issue Type: Bug
> Environment: Windows 10 64 Bit, Java 8
>Reporter: Guido Schnepp
>  Labels: easyfix
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Oracle has reworked the ZipFile object with Java 7. Since then the default 
> constructor used by commons-vfs2 2.1 is more restrictive than with Java 6. 
> The ZipFile constructor has got a second parameter (Charset) now for 
> specification of the legacy charset to be used explicitly if the ZipFile 
> doesn't state its UTF-8 compliance internally. This affects all ZIP files 
> using a legacy charset for filename encoding but not using UTF-8 is it is 
> common today. This could be a ZIP file with files containing german umlauts 
> or russian characters in archived file's filenames, for example.
> To support this new parameter with (more or less) default values, the class 
> org.apache.commons.vfs2.provider.zip.ZipFileSystem has to be extended by a 
> default charset parameter, getter or setter (as you like) to forward this 
> setting to the java.util.zip.ZipFile constructor.
> Quick workaround for me was to create a new OwnZipFileProvider referring to 
> the even new OwnZipFileSystem (extending ZipFileSystem) with the following 
> modified function. Change has been highlighted:
> {{protected ZipFile createZipFile(final File file) throws 
> FileSystemException {
>   try {
>   return new ZipFile(file{color:red}*, 
> Charset.forName("IBM437")*{color});
>   } catch (final IOException ioe) {
>   throw new 
> FileSystemException("vfs.provider.zip/open-zip-file.error", file, ioe);
>   }
>   }
> }}
> Presetting to charset 437 as legacy default charset seems to be a a good 
> workaround as stated in appendix D here: 
> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT :
> "D.1 The ZIP format has historically supported only the original IBM PC 
> character encoding set, commonly referred to as IBM Code Page 437.  This 
> limits storing file name characters to only those within the original MS-DOS 
> range of values and does not properly support file names in other character 
> encodings, or  languages. [...]"



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