[jira] [Commented] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution

[Bruno P. Kinoshita (JIRA)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062216#comment-16062216
 ] 

Bruno P. Kinoshita commented on FILEUPLOAD-279:
---

Updated the version in JIRA, with release date the same as the announce e-mail 
in the commons mailing list.

> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation 
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
>  Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can 
> be manipulated in such a way that when it is deserialized, it can write or 
> copy files to disk in arbitrary locations. Furthermore, while the Object can 
> be used alone, this new vector can be integrated with ysoserial to upload and 
> execute binaries in a single deserialization call. This may or may not work 
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s 
> yososerial tool to gain remote code execution on a variety of commercial 
> products, based on a presentation at AppSec Cali in January, 2015. The 
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and 
> Spring that do “unexpected” things during deserialization. Specifically, the 
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing 
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make 
> “it easy to add robust, high-performance, file upload capability to your 
> servlets and web applications.” One of the classes in the FileUpload library 
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads. 
> Interestingly, DiskFileItem is serializable and implements custom 
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository 
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the 
> JVMs are
> 639 * on different machines It is possible that the repository 
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null 
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after 
> analyzing the state of DiskFileItem after serialization it became clear that 
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not 
> serialized. dfos is regenerated by the getOutputStream() call above (which 
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid 
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file 
> from disk.
> That filename is always generated via getOutputStream.
> Serialized Object Modification
> The rules 

[jira] [Updated] (FILEUPLOAD-283) Add tests to the portlet package

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita updated FILEUPLOAD-283:
--
Fix Version/s: 1.4

> Add tests to the portlet package
> 
>
> Key: FILEUPLOAD-283
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-283
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: coverage, test
> Fix For: 1.4
>
>
> Currently, the o.a.c.fileupload.portlet is reported as having 0% coverage in 
> the cobertura report.
> During the last vote thread I noted that and added a post-it to add some 
> tests. Creating a ticket so that I do not forget.



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

[jira] [Resolved] (FILEUPLOAD-283) Add tests to the portlet package

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita resolved FILEUPLOAD-283.
---
Resolution: Fixed

Pull request merged. Coverage increased a bit, tests adapted to cover servlet, 
legacy class, and portlets. No tests were removed, only moved to other test 
classes or new ones added.

> Add tests to the portlet package
> 
>
> Key: FILEUPLOAD-283
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-283
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: coverage, test
>
> Currently, the o.a.c.fileupload.portlet is reported as having 0% coverage in 
> the cobertura report.
> During the last vote thread I noted that and added a post-it to add some 
> tests. Creating a ticket so that I do not forget.



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

[jira] [Commented] (FILEUPLOAD-283) Add tests to the portlet package

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062214#comment-16062214
 ] 

ASF GitHub Bot commented on FILEUPLOAD-283:
---

Github user asfgit closed the pull request at:

https://github.com/apache/commons-fileupload/pull/8


> Add tests to the portlet package
> 
>
> Key: FILEUPLOAD-283
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-283
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: coverage, test
>
> Currently, the o.a.c.fileupload.portlet is reported as having 0% coverage in 
> the cobertura report.
> During the last vote thread I noted that and added a post-it to add some 
> tests. Creating a ticket so that I do not forget.



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

Simon Spero commented on COMPRESS-413:
--

I'll strip out the AsiExtraField foo.  I just have the strategic reserve of 
coverage increasers for coverall-shutting-up. 

My main issue with Java 7 compatibility is that the primary use case  now is 
some older android releases (which can't do Java 8 default/static methods), but 
android compatibility testing at its most basic requires using a different 
animal-sniffer scent (anything else is difficult without gradle). 

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

ASF GitHub Bot commented on COMPRESS-413:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/39
  
Replaced by PR https://github.com/apache/commons-compress/pull/43


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



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

[jira] [Commented] (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=16062133#comment-16062133
 ] 

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

ASF GitHub Bot commented on COMPRESS-413:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/39
  
Closing because there's a new PR without the coveralls bait. 
Coveralls complains. 

The mvnw is not essential yet, but it's good to have  3.5.0 in place.  


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

ASF GitHub Bot commented on COMPRESS-413:
-

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/43
  
That's why there was random coveralls stuff in the PR... 
coverage/coveralls — Coverage decreased (-0.02%) to 84.742%



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

ASF GitHub Bot commented on COMPRESS-413:
-

Github user coveralls commented on the issue:

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

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

Coverage decreased (-0.02%) to 84.742% when pulling 
**2fc4afa8f6571048604616a8edb2bbd55b4776f4 on sesuncedu:COMPRESS-413-REDUX** 
into **19e1b02f754a9b7bc969eb17bd52cc36a85c4d74 on apache:master**.



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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COMPRESS-413:
-

GitHub user sesuncedu opened a pull request:

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

COMPRESS-413 : Improved build performance with travis

Now without unrelated sacrifices to coveralls

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-413-REDUX

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

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


commit 2fc4afa8f6571048604616a8edb2bbd55b4776f4
Author: Simon Spero 
Date:   2017-06-24T20:37:47Z

COMPRESS-413 : Improved build performance with travis

Now without unrelated sacrifices to coveralls

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

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/12118668/badge)](https://:/builds/12118668)

Coverage increased (+0.04%) to 84.766% when pulling 
**233536b0d1b1df8296fe254c59af5bed7e8c3e32 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] (DAEMON-366) 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=16062098#comment-16062098
 ] 

Consultant Leon commented on DAEMON-366:


Firstly I've now managed to resolve the shutdown problem by fixing our 
application and ensure it properly terminates all threads - this is confirmed 
as one solution.

Secondly I'm not sure what the best behaviour should be for procrun when a 
process does not behave so I created the debug log to help you to determine if 
this is really a 1.0.15 procrun issue as well. I do not see the 'waiting 1 
minute message'.

So I reinstalled the service with option --LogLevel=Debug

Then perform sc stop TestC (TestC is the name of my service at this point)

Once I shutdown I see our own application log:
2017-06-24_20:43:07.711- 
INFO-[FileExportDestination-HelloWorld.OutputDest]-rename/move temporary file 
...
2017-06-24_20:43:07.711- 
INFO-[FileExportDestination-HelloWorld.OutputDest]-consume done 
[FileSource_15cdb6a2ca3_1], status=PROCESSING 
2017-06-24_20:43:54.466- INFO-[Thread-3
]-Stopping APP service 'TestC'... 
2017-06-24_20:43:54.466- INFO-[Thread-3
]-HelloWorld-SYSTEM: pause all sources configured with 
pause.before.shutdown=true, request remaining sources to stop 
2017-06-24_20:43:54.482- INFO-[Thread-3
]-HelloWorld-SYSTEM: all sources set to pause 'before shutdown' have now 
paused, other sources have stopped 
2017-06-24_20:43:54.482- INFO-[Thread-3
]-HelloWorld-SYSTEM: wait max 30 seconds for queues to flush 
2017-06-24_20:43:54.482- INFO-[Thread-3
]-HelloWorld-SYSTEM: all queues are flushed 
2017-06-24_20:43:54.482- INFO-[Thread-3
]-HelloWorld-SYSTEM: pause all components configured with 
pause.on.shutdown=true... 
2017-06-24_20:43:54.482- INFO-[Thread-3
]-HelloWorld-SYSTEM: all components set to pause 'on shutdown' have now paused 
2017-06-24_20:43:54.482- INFO-[Thread-3
]-ServiceResponder: close service connection 
2017-06-24_20:43:54.482- INFO-[Thread-3]-all 
services stopped timely 
2017-06-24_20:43:54.482- INFO-[Thread-3]-APP 
service 'TestC' stopped. 

So at 20:43:54.482 the main java application shutdown is complete.

I then run jstack -F  and see many threads left running indeed:
$ sc queryex TestC

SERVICE_NAME: TestC
TYPE   : 10  WIN32_OWN_PROCESS
STATE  : 3  STOP_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE: 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT : 0x3
WAIT_HINT  : 0x493e0
PID: 11088
FLAGS  :

> D:\app_home\app-2.0.0.0.0-5145\etc
$ jstack -F 11088

Then now a good 20 minutes later the service is still in STATE STOP_PENDING:

The only other logs are from the proc daemon:
commons-daemon.2017-06-24.log
[2017-06-24 20:40:38] [debug] ( prunsrv.c:1679) [10484] Commons Daemon procrun 
log initialized
[2017-06-24 20:40:38] [info]  ( prunsrv.c:1683) [10484] Commons Daemon procrun 
(1.0.15.0 64-bit) started
[2017-06-24 20:40:38] [debug] ( prunsrv.c:561 ) [10484] Installing service...
[2017-06-24 20:40:38] [info]  ( prunsrv.c:600 ) [10484] Service TestC name TestC
[2017-06-24 20:40:38] [debug] ( prunsrv.c:616 ) [10484] Setting service 
description FusionFabric Connect 
(D:\APP_home\APP-2.0.0.0.0-5145\config\samples\HelloWorld)
[2017-06-24 20:40:38] [info]  ( prunsrv.c:634 ) [10484] Service 'TestC' 
installed
[2017-06-24 20:40:38] [info]  ( prunsrv.c:1764) [10484] Commons Daemon procrun 
finished
[2017-06-24 20:40:55] [debug] ( prunsrv.c:1679) [ 7180] Commons Daemon procrun 
log initialized
[2017-06-24 20:40:55] [info]  ( prunsrv.c:1683) [ 7180] Commons Daemon procrun 
(1.0.15.0 64-bit) started
[2017-06-24 20:40:55] [info]  ( prunsrv.c:1596) [ 7180] Running 'TestC' 
Service...
[2017-06-24 20:40:55] [debug] ( prunsrv.c:1374) [ 8884] Inside ServiceMain...
[2017-06-24 20:40:55] [debug] ( prunsrv.c:844 ) [ 8884] reportServiceStatusE: 
2, 0, 3000, 0
[2017-06-24 20:40:55] [info]  ( prunsrv.c:1127) [ 8884] Starting service...
[2017-06-24 20:40:55] [debug] ( javajni.c:233 ) [ 8884] loading jvm 'C:\Program 
Files\Java\jdk1.8.0_73\jre\bin\server\jvm.dll'
[2017-06-24 20:40:55] [debug] ( javajni.c:704 ) [ 2824] Jvm Option[0] 
-XX:+UseConcMarkSweepGC
[2017-06-24 20:40:55] [debug] ( javajni.c:704 ) [ 2824] Jvm Option[1] 
-XX:MaxGCPauseMillis=2000
[2017-06-24 20:40:55] [debug] ( javajni.c:704 ) [ 2824] Jvm Option[2] 
-XX:GCTimeRatio=10
[2017-06-24 20:40:55] [debug] ( javajni.c:704 ) [ 2824] Jvm Option[3] 
-XX:+CMSIncrementalMode
[2017-06-24 20:40:55] [debug] ( 

[jira] [Updated] (DAEMON-366) 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:
---
Attachment: screenshot-1.png

> 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
> Attachments: screenshot-1.png
>
>
> 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] [Created] (COMPRESS-414) Provide API for Channel(-ish) Seekable, Possibly Read/Write, Possibly Transactional Compressors & Archivers,

[Simon Spero (JIRA)]

Simon Spero created COMPRESS-414:


 Summary: Provide API for Channel(-ish) Seekable, Possibly 
Read/Write, Possibly Transactional  Compressors & Archivers, 
 Key: COMPRESS-414
 URL: https://issues.apache.org/jira/browse/COMPRESS-414
 Project: Commons Compress
  Issue Type: Improvement
Reporter: Simon Spero


It would be very useful to have APIs  to support random-access, possibly 
read-write archives & compressors. 

These interfaces should probably be based around Seekable, Scatter, and Gather 
ByteChannels.  
It might  be necessary or desirable to have these classes extend FileChannel, 
since there are some important methods that first make their appearance as 
abstract methods on that class. 

The methods of interest are the absolute positioned read and write methods, 
plus force/sync.

  The use case I'm thinking of for the the non-relative read/write would be for 
a random-access compressed "file", where it may be useful to keep a cache of 
decompressed blocks, and where a task may require access to several parts of 
the file simultaneously.   Nesting this deeper, there might be (well, there 
are)  a tar.xz file containing a sequence of versions of a maven artifact jar,  
and with  an analysis process that  needs  access to two or more of the files 
simultaneously. 

A use case requiring  read/write + transactional + sync support would be to 
support in-place  appending new items to a tar.xz file.  It can be quite useful 
to be able to perform such updates "in-place"; for safety this requires a log 
the parts of the existing file that are going to be changed, so that the 
contents can be recovered in the event of failure.  

If there is related metadata in a separate transactional resource, it is good 
to have both stores remain in sync.  The complicated parts are the job of a 
transaction manager (e.g.  Aries); basic XAResource support is relatively 
simple.There are other bits of glue that are useful for handling simple 
transactions with no transaction manager around, but those can be optional 
imports.






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

[jira] [Closed] (COMPRESS-408) If block size is unspecified, use 512 bytes

[Simon Spero (JIRA)]

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

Simon Spero closed COMPRESS-408.


Work done as part of COMPRESS-407

> If block size is unspecified, use 512 bytes
> ---
>
> Key: COMPRESS-408
> URL: https://issues.apache.org/jira/browse/COMPRESS-408
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>




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

[jira] [Commented] (COMPRESS-408) If block size is unspecified, use 512 bytes

[Simon Spero (JIRA)]

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

Simon Spero commented on COMPRESS-408:
--

Completed as part of COMPRESS-407

> If block size is unspecified, use 512 bytes
> ---
>
> Key: COMPRESS-408
> URL: https://issues.apache.org/jira/browse/COMPRESS-408
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>




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

Simon Spero commented on COMPRESS-407:
--

Maxi-Min For The Not-losing-as-badly-as-possible :-)

I will also close COMPRESS-408, since that sub-task got addressed as part of 
this one. 



> 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
> Fix For: 1.15
>
>
> 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] (LANG-1341) equalsBuilder.appendSuper() has incorrect behavior if the object you call equals() on is a direct supertype of Object

[Benedikt Ritter (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062061#comment-16062061
 ] 

Benedikt Ritter commented on LANG-1341:
---

Patches welcome!

> equalsBuilder.appendSuper() has incorrect behavior if the object you call 
> equals() on is a direct supertype of Object
> -
>
> Key: LANG-1341
> URL: https://issues.apache.org/jira/browse/LANG-1341
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Kevin Binswanger
>Priority: Minor
>
> If you use EqualsBuilder.appendSuper(super.equals(Object)) on an Object whose 
> direct supertype is Object, it will succeed if and only if the two references 
> are the same (because that's what Object.equals does).
> Reading it out loud, this is obvious, but I think the Javadoc for 
> EqualsBuilder encourages you to make this mistake. In particular, here's some 
> text in the summary of the Javadoc:
> {quote}Typical use for the code is as follows:{quote}
> {code}
>  public boolean equals(Object obj) {
>if (obj == null) { return false; }
>if (obj == this) { return true; }
>if (obj.getClass() != getClass()) {
>  return false;
>}
>MyClass rhs = (MyClass) obj;
>return new EqualsBuilder()
>  .appendSuper(super.equals(obj))
>  .append(field1, rhs.field1)
>  .append(field2, rhs.field2)
>  .append(field3, rhs.field3)
>  .isEquals();
>   }{code}
> There's also no mention of this in the javadocs for the appendSuper() method 
> itself.
> My suggestion is to fix the example at the beginning. The way HashCodeBuilder 
> does this, which I think is the best, is to leave appendSuper out of the 
> example and adds this line after: {quote}If required, the superclass 
> hashCode() can be added using appendSuper(int).{quote}
> For completeness, here's a snippet of code that illustrates this problem.
> {code}
> public class Thing {
> public String text;
> @Override
> public boolean equals(final Object other) {
> if (other == null) {
> return false;
> }
> if (other == this) {
> return true;
> }
> if (other.getClass() != getClass()) {
> return false;
> }
> final Thing thing = (Thing) other;
> return new EqualsBuilder()
> .appendSuper(super.equals(other))
> .append(text, thing.text)
> .isEquals();
> }
> }{code}



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

[jira] [Commented] (DAEMON-288) Hang while stopping procrun service

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels commented on DAEMON-288:


Discussiong this in DAEMON-366 since it looks like the change (probably) causes 
1.0.15 be less forcefull in terminating a JVM. Any idea when it will happen 
that the main thread does not see the gShutdownEvent (should we maybe add a 
warning log in this case?)

> Hang while stopping procrun service
> ---
>
> Key: DAEMON-288
> URL: https://issues.apache.org/jira/browse/DAEMON-288
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: Procrun
>Affects Versions: 1.0.13
> Environment: Windows 7 64 bit
>Reporter: Mike Miller
> Fix For: 1.0.15
>
> Attachments: prunsrv.c.patch
>
>
> There is a hang of the procrun service while it is attempting to stop.  It is 
> not easy to reproduce ( 30%-5% depending on pc ).  Using a debugging to 
> analyze the hang, both the serviceMain() and serviceStop() threads appear to 
> have run and exited.  I can tell this from the state of the global variables 
> like gSargs and gShutdownEvents.  Looking at the code, both are calling 
> reportServiceStatus( SERVICE_STOPPED...).  Typically when either one reports 
> SERVICE_STOPPED, the main thread unblocks and the process terminates.  This 
> often occurs without both threads running to completion.  I think this is a 
> race condition caused by the reportServiceStatus() usage.  The MSDN 
> documentation for SetServiceStatus() states to only call SetServiceStatus() 
> with SERVICE_STOPPED after all cleanup has occurred and to only call it once. 
>  It appears that procrun has a race condition where 2 threads will both 
> attempt to report SERVICE_STOPPED and will likely report this while the other 
> thread is still running.  I believe this is the root cause of why the Service 
> Control Manager sometimes is unable to stop the service.   
>  
> As a potential solution, I modified serviceStop() to not call 
> reportServiceStatus(SERVICE_STOPPED...) and to move the SetEvent( 
> gShutdownEvent) to the end of the method.  This change allows the thread 
> running the  serviceStop() to complete.  Now the only method reporting 
> stopped is when serviceMain() exits.  With this refactoring to only report 
> SERVICE_STOPPED once (per MSDN) the hang has not been reproducible.  



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

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

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels edited comment on DAEMON-366 at 6/24/17 3:53 PM:
-

I just diffed the releases and there is a change in this area, the global 
shutdown event which terminates the main service loop is set a bit later:

http://svn.apache.org/viewvc/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15/src/native/windows/apps/prunsrv/prunsrv.c?r1=1460101=1461070_format=h

This is I guess a bugfix for a similiar issue (DAEMON-288) to allow a clean 
shutdown.

However this does not look directly like the issue, but It might be possible 
that the shutdown event might be missed and the shutdown wont be forcefully.  

Can you provide us with a debug-level logfile of procrun? (--LogLevel=Debug)

This is expected:
  "Waiting 1 minute for all threads to exit"
  
http://svn.apache.org/viewvc/commons/proper/daemon/branches/1.0.x/src/native/windows/apps/prunsrv/prunsrv.c?diff_format=h=1461070=markup#l1559

this would block:
  "Waiting for all threads to exit" 
  
http://svn.apache.org/viewvc/commons/proper/daemon/branches/1.0.x/src/native/windows/apps/prunsrv/prunsrv.c?diff_format=h=1461070=markup#l1559


was (Author: b.eckenfels):
I just diffed the releases and there is a change in this area, the global 
shutdown event which terminates the main service loop is set only after the JVM 
has exited.

http://svn.apache.org/viewvc/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15/src/native/windows/apps/prunsrv/prunsrv.c?r1=1460101=1461070_format=h

This is I guess a bugfix for a similiar issue (DAEMON-288) to allow a clean 
shutdown. It might be possible that the shutdown event might be missed and the 
shutdown wont be forcefully.  

Can you provide us with a debug-level logfile of procrun? (--LogLevel=Debug)

This is expected:
  "Waiting 1 minute for all threads to exit"
  
http://svn.apache.org/viewvc/commons/proper/daemon/branches/1.0.x/src/native/windows/apps/prunsrv/prunsrv.c?diff_format=h=1461070=markup#l1559

this would block:
  "Waiting for all threads to exit" 
  
http://svn.apache.org/viewvc/commons/proper/daemon/branches/1.0.x/src/native/windows/apps/prunsrv/prunsrv.c?diff_format=h=1461070=markup#l1559



, but it has the consequence that it wont anymore forcefully terminate your 
service. If I see it right it will set the event after the stop timeout, so try 
setting the stop timeout to something a bit smaller than the windows service 
manager timeout of 30s.



> 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) Windows service fails to stop with error code 1053 (using Windows 7 service manager)

[Bernd Eckenfels (JIRA)]

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

Bernd Eckenfels commented on DAEMON-366:


I just diffed the releases and there is a change in this area, the global 
shutdown event which terminates the main service loop is set only after the JVM 
has exited.

http://svn.apache.org/viewvc/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_15/src/native/windows/apps/prunsrv/prunsrv.c?r1=1460101=1461070_format=h

This is I guess a bugfix for a similiar issue (DAEMON-288) to allow a clean 
shutdown. It might be possible that the shutdown event might be missed and the 
shutdown wont be forcefully.  

Can you provide us with a debug-level logfile of procrun? (--LogLevel=Debug)

This is expected:
  "Waiting 1 minute for all threads to exit"
  
http://svn.apache.org/viewvc/commons/proper/daemon/branches/1.0.x/src/native/windows/apps/prunsrv/prunsrv.c?diff_format=h=1461070=markup#l1559

this would block:
  "Waiting for all threads to exit" 
  
http://svn.apache.org/viewvc/commons/proper/daemon/branches/1.0.x/src/native/windows/apps/prunsrv/prunsrv.c?diff_format=h=1461070=markup#l1559



, but it has the consequence that it wont anymore forcefully terminate your 
service. If I see it right it will set the event after the stop timeout, so try 
setting the stop timeout to something a bit smaller than the windows service 
manager timeout of 30s.



> 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] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on COMPRESS-400:
-

Let me retry, as I really like your changes and would like to merge them. I 
don't think we need {{addXattr}} and {{getXattr}} - and thus {{XATTR_PREFIX}}. 
They'd only ever be used by people who should know what they are doing and 
could add the prefixes themselves. They are convenience methods for an 
extremely small subset of our users that would be trivial to write outside of 
our code base.

I'd be happy to merge your change without these two methods.

> It should be possible for users to create and access extra PAX headers to tar 
> archives 
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
>  Issue Type: Improvement
>  Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries.  For 
> example, a tar file containing maven artifacts could have extra headers 
> carrying the groupid, artifactid, version, classifier, etc.  
> If the appropriate prefixes are used, these headers can be extracted to posix 
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra 
> headers, plus modifications to the TarArchive*Stream to save unrecognized 
> headers when reading, and to add any extra headers when writing. 
> I have created a prototype implementation, but have not merged it into my 
> fork of the project.  I don't have full tests written, because I was using 
> gnutar as an oracle.
>  I have also ignored the issue of writing values to standard headers like 
> size, though since the PAX specification states that doing things like 
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm 
> technically in compliance.  The temptation is  to do what was asked, then on 
> close pop up a "Were you sure?" dialog, but that's mean.  I guess I could use 
> this to set the appropriate entry fields if doing so makes sense, but the 
> easiest approach  is to block setting any headers that would be consumed by 
> the tar implementation when reading. 



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

ASF GitHub Bot commented on COMPRESS-413:
-

Github user bodewig commented on the issue:

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

TBH I'm not too sure why we've got Travis builds at all, probably so we can 
run Coveralls. I'll leave this request open for those more interested in the 
Travis CI setup. I'll rather invest some time in adding a Jenkins matrix build 
for the JDKs we want to support instead.

Commons Compress aims to be compatible with Java7, no matter how old or 
deprecated, but we already cover that with Jenkins - the pull request builder 
over there uses Oracle JDK 7, so we've got that covered independent of Travis 
CI. We do run SonarQube for Compress already.

Personally I dislike `mvnw` scripts, but this is probably a matter of 
taste. I won't veto its introduction.

Please strip the changes to `AsiExtraField` from this PR, they are 
completely unrelated.


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



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

[jira] [Resolved] (COMPRESS-408) If block size is unspecified, use 512 bytes

[Simon Spero (JIRA)]

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

Simon Spero resolved COMPRESS-408.
--
Resolution: Fixed

> If block size is unspecified, use 512 bytes
> ---
>
> Key: COMPRESS-408
> URL: https://issues.apache.org/jira/browse/COMPRESS-408
> Project: Commons Compress
>  Issue Type: Sub-task
>  Components: Archivers
>Reporter: Simon Spero
>




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

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

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved COMPRESS-407.
-
   Resolution: Fixed
Fix Version/s: 1.15

Thanks, Simon!

> 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
> Fix For: 1.15
>
>
> 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=16062027#comment-16062027
 ] 

ASF GitHub Bot commented on COMPRESS-407:
-

Github user asfgit closed the pull request at:

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


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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user asfgit closed the pull request at:

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


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

ASF GitHub Bot commented on COMPRESS-407:
-

Github user asfgit closed the pull request at:

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


> 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

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on COMPRESS-407:
-

Oh my, one option worse than the other ;-)

Currently we haven't got any external dependency on a logging framework by 
choice and I really wouldn't want to introduce it just in order to support a 
use-case like "people want to keep their broken tar-link outputs".

I intend to merge #40 and mark it as a change that is going to break backwards 
compatibility. We'll see if people start to complain and can think about 
options after that. I'll close #41 via the commit 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] (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=16062008#comment-16062008
 ] 

ASF GitHub Bot commented on TEXT-93:


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

https://github.com/apache/commons-text/pull/54#discussion_r123877950
  
--- Diff: src/main/java/org/apache/commons/text/RandomStringGenerator.java 
---
@@ -76,23 +78,29 @@
 private final TextRandomProvider random;
 
 /**
+ * The source of provided charachters.
+ */
+private final List characterList;
+
+/**
  * Constructs the generator.
- *
- * @param minimumCodePoint
+ *  @param minimumCodePoint
  *smallest allowed code point (inclusive)
  * @param maximumCodePoint
  *largest allowed code point (inclusive)
  * @param inclusivePredicates
- *filters for code points
- * @param random
- *source of randomness
+ *filters for code points
--- End diff --

yeah, seems like IntelliJ did this unknowingly, fixed it!


> 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] (FILEUPLOAD-279) CVE-2016-1000031 - Apache Commons FileUpload DiskFileItem File Manipulation Remote Code Execution

[Mark Symons (JIRA)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062007#comment-16062007
 ] 

Mark Symons commented on FILEUPLOAD-279:


Thanks very much for the release. 1.3.3 is 
[available|http://repo1.maven.org/maven2/commons-fileupload/commons-fileupload/1.3.3/]
 in Maven Central.

Just one thing...  1.3.3 has not yet been released in JIRA.

> CVE-2016-131 - Apache Commons FileUpload DiskFileItem File Manipulation 
> Remote Code Execution
> -
>
> Key: FILEUPLOAD-279
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-279
> Project: Commons FileUpload
>  Issue Type: Bug
>Affects Versions: 1.3.2
>Reporter: Michiel Weggen
>Priority: Critical
>  Labels: security
> Fix For: 1.3.3
>
> Attachments: fix2.patch
>
>
> http://www.tenable.com/security/research/tra-2016-12
> Summary
> There exists a Java Object in the Apache Commons FileUpload library that can 
> be manipulated in such a way that when it is deserialized, it can write or 
> copy files to disk in arbitrary locations. Furthermore, while the Object can 
> be used alone, this new vector can be integrated with ysoserial to upload and 
> execute binaries in a single deserialization call. This may or may not work 
> depending on an application's implementation of the FileUpload library.
> Background
> In late 2015 FoxGlove Security released a write up on using Chris Frohoff’s 
> yososerial tool to gain remote code execution on a variety of commercial 
> products, based on a presentation at AppSec Cali in January, 2015. The 
> ysoserial tool uses “gadgets” in Apache Commons Collections, Groovy, and 
> Spring that do “unexpected” things during deserialization. Specifically, the 
> ysoserial payloads eventually execute Runtime.getRuntime().exec() allowing 
> for remote Java code execution.
> The Apache Commons project maintains a library called “FileUpload” to make 
> “it easy to add robust, high-performance, file upload capability to your 
> servlets and web applications.” One of the classes in the FileUpload library 
> is called “DiskFileItem”. A DiskFileItem is used to handle file uploads. 
> Interestingly, DiskFileItem is serializable and implements custom 
> writeObject() and readObject() functions.
> DiskFileItem’s readObject Implementation
> Here is the implementation that currently exists at the projects repository 
> tip (as of 1/28/16):
> 632private void readObject(ObjectInputStream in)
> 633throws IOException, ClassNotFoundException {
> 634// read values
> 635in.defaultReadObject();
> 636
> 637/* One expected use of serialization is to migrate HTTP sessions
> 638 * containing a DiskFileItem between JVMs. Particularly if the 
> JVMs are
> 639 * on different machines It is possible that the repository 
> location is
> 640 * not valid so validate it.
> 641 */
> 642if (repository != null) {
> 643if (repository.isDirectory()) {
> 644// Check path for nulls
> 645if (repository.getPath().contains("\0")) {
> 646throw new IOException(format(
> 647"The repository [%s] contains a null 
> character",
> 648repository.getPath()));
> 649}
> 650} else {
> 651throw new IOException(format(
> 652"The repository [%s] is not a directory",
> 653repository.getAbsolutePath()));
> 654}
> 655}
> 656
> 657OutputStream output = getOutputStream();
> 658if (cachedContent != null) {
> 659output.write(cachedContent);
> 660} else {
> 661FileInputStream input = new FileInputStream(dfosFile);
> 662IOUtils.copy(input, output);
> 663IOUtils.closeQuietly(input);
> 664dfosFile.delete();
> 665dfosFile = null;
> 666}
> 667output.close();
> 668
> 669cachedContent = null;
> 670}
> This is interesting due to the apparent creation of files. However, after 
> analyzing the state of DiskFileItem after serialization it became clear that 
> arbitrary file creation was not supposed to be intended:
> dfos (a type of OutputStream) is transient and therefore it is not 
> serialized. dfos is regenerated by the getOutputStream() call above (which 
> also generates the new File to write out to).
> The “repository” (or directory that the file is written to) has to be valid 
> at the time of serialization in order for successful deserialization to occur.
> If there is no “cachedContent” then readObject() tries to read in the file 
> from disk.
> That 

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

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/12116448/badge)](https://:/builds/12116448)

Coverage decreased (-0.02%) to 97.305% when pulling 
**9db77088ecc557c2f209dd36972746d6de8dfc4a 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] (TEXT-95) Convenience formatting method in ExtendedMethodFormat

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on TEXT-95:


It sounds interesting! Reduces verbosity, makes code simpler. I haven't used 
much the ExtendedMessageFormat, so will spend some time reading the code, 
javadocs, and playing with it over the next days before committing to a aye or 
nay :-)

Thanks for reporting.
Bruno

> Convenience formatting method in ExtendedMethodFormat
> -
>
> Key: TEXT-95
> URL: https://issues.apache.org/jira/browse/TEXT-95
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>
> It would be nice to have a simple formatting method in ExtendedMethodFormat:
> {code}
> String format(Object... arguments)
> {code}
> Intended use:
> {code}
> ExtendedMessageFormat messageFormat = new ExtendedMessageFormat("{0}, {1}", 
> Locale.ROOT);
> String output = messageFormat.format("Hello", "World");
> {code}
> The current formatting method of (Extended)MethodFormat is quite inconvenient 
> for simple use cases:
> {code}
> ExtendedMessageFormat messageFormat = new ExtendedMessageFormat("{0}, {1}", 
> Locale.ROOT);
> Object[] arguments = { "Hello", "World" };
> StringBuffer outputBuffer = messageFormat.format(arguments, new 
> StringBuffer(), null);
> String output = outputBuffer.toString();
> {code}



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

[jira] [Commented] (FILEUPLOAD-283) Add tests to the portlet package

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16061896#comment-16061896
 ] 

ASF GitHub Bot commented on FILEUPLOAD-283:
---

Github user kinow commented on the issue:

https://github.com/apache/commons-fileupload/pull/8
  
No objections so far, will merge it tomorrow after reviewing the code once 
more :+1: 


> Add tests to the portlet package
> 
>
> Key: FILEUPLOAD-283
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-283
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
>  Labels: coverage, test
>
> Currently, the o.a.c.fileupload.portlet is reported as having 0% coverage in 
> the cobertura report.
> During the last vote thread I noted that and added a post-it to add some 
> tests. Creating a ticket so that I do not forget.



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

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

[Bruno P. Kinoshita (JIRA)]

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

Bruno P. Kinoshita commented on TEXT-93:


>Well, Yes nowadays programmers prefer List over arrays

That can lead to a whole new conversation, and you will probably find people 
supporting List over arrays, and others supporting arrays over Lists :-) I, 
myself, have no preference, normally the libraries/framework kind of dictate 
what I am using...

> and it's convineant too, but I'm not biased towards either decision to have 
> that method or not as far as we have another method to perform task for us

I'm +0 to having the other method. i.e. fine if the method is added, but fine 
too if others prefer not to add it. We can add it later too if that's the case. 
However, looking at classes at o.a.c.text, most I believe operate on 
Character[], char...,char[], etc.

> 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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TEXT-93:


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

https://github.com/apache/commons-text/pull/54#discussion_r123874569
  
--- Diff: src/main/java/org/apache/commons/text/RandomStringGenerator.java 
---
@@ -76,23 +78,29 @@
 private final TextRandomProvider random;
 
 /**
+ * The source of provided charachters.
+ */
+private final List characterList;
+
+/**
  * Constructs the generator.
- *
- * @param minimumCodePoint
+ *  @param minimumCodePoint
  *smallest allowed code point (inclusive)
  * @param maximumCodePoint
  *largest allowed code point (inclusive)
  * @param inclusivePredicates
- *filters for code points
- * @param random
- *source of randomness
+ *filters for code points
--- End diff --

Indentation got a bit messed up here, and the param entry for 
minimumCodePoint too


> 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

[Amey Jadiye (JIRA)]

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

Amey Jadiye commented on TEXT-93:
-

Well, Yes nowadays programmers prefer List over arrays and it's convineant too, 
but I'm not biased towards either decision to have that method or not as far as 
we have another method to perform task for us. [~pascalschumacher] and 
[~wmacgyver]  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] [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=16061867#comment-16061867
 ] 

Gilles commented on TEXT-93:


It is not obvious to me that such a method is not useful (and even more so when 
one can pass any {{Collection}})...


> 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] [Created] (TEXT-95) Convenience formatting method in ExtendedMethodFormat

[Arend v. Reinersdorff (JIRA)]

Arend v. Reinersdorff created TEXT-95:
-

 Summary: Convenience formatting method in ExtendedMethodFormat
 Key: TEXT-95
 URL: https://issues.apache.org/jira/browse/TEXT-95
 Project: Commons Text
  Issue Type: Improvement
Reporter: Arend v. Reinersdorff


It would be nice to have a simple formatting method in ExtendedMethodFormat:
{code}
String format(Object... arguments)
{code}

Intended use:
{code}
ExtendedMessageFormat messageFormat = new ExtendedMessageFormat("{0}, {1}", 
Locale.ROOT);

String output = messageFormat.format("Hello", "World");
{code}

The current formatting method of (Extended)MethodFormat is quite inconvenient 
for simple use cases:
{code}
ExtendedMessageFormat messageFormat = new ExtendedMessageFormat("{0}, {1}", 
Locale.ROOT);

Object[] arguments = { "Hello", "World" };
StringBuffer outputBuffer = messageFormat.format(arguments, new StringBuffer(), 
null);
String output = outputBuffer.toString();
{code}



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