[jira] [Created] (VALIDATOR-386) org.apache.commons.validator.routines.DomainValidator.ArrayType is not public
Auke van Leeuwen created VALIDATOR-386:
--
Summary:
org.apache.commons.validator.routines.DomainValidator.ArrayType is not public
Key: VALIDATOR-386
URL: https://issues.apache.org/jira/browse/VALIDATOR-386
Project: Commons Validator
Issue Type: Bug
Affects Versions: 1.5.0
Reporter: Auke van Leeuwen
Version 1.5.0 adds the possibility to override TLDs using:
{{org.apache.commons.validator.routines.DomainValidator#updateTLDOverride}}
however the first parameter to that function is package scoped. This seems like
a bug to me, to implement an override I have to create a class in
{{org.apache.commons.validator.routines}} for me to use this functionality.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (NET-586) FTPTimestampParserImpl test failure since 1 Jan 2016
Mikolaj Izdebski created NET-586:
Summary: FTPTimestampParserImpl test failure since 1 Jan 2016
Key: NET-586
URL: https://issues.apache.org/jira/browse/NET-586
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.4
Environment: Linux, OpenJDK 8
Reporter: Mikolaj Izdebski
Test method {{testFeb29IfLeapYear}} from class
{{org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest}} started to
fail since 1 January 2016.
Stack trace of the failure:
{code}
testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest)
Time elapsed: 0.005 sec <<< FAILURE!
junit.framework.AssertionFailedError: Test: 'Feb 29th' Server=2016-01-04 11:33.
Failed to parse Feb 29 00:00. Actual 2015-02-28 12:00. Expected 2016-02-29 12:00
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:227)
at
org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest.checkShortParse(FTPTimestampParserImplTest.java:307)
at
org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest.checkShortParse(FTPTimestampParserImplTest.java:279)
at
org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest.checkShortParse(FTPTimestampParserImplTest.java:257)
at
org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest.testFeb29IfLeapYear(FTPTimestampParserImplTest.java:390)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (EXEC-95) Program not found after setWorkingDirectory
[
https://issues.apache.org/jira/browse/EXEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl resolved EXEC-95.
---
Resolution: Not A Problem
> Program not found after setWorkingDirectory
> ---
>
> Key: EXEC-95
> URL: https://issues.apache.org/jira/browse/EXEC-95
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: win7 64 bit.
>Reporter: Lorenzo Cozza
>Assignee: Siegfried Goeschl
>
> I would like to run my script from a different folder, so I tried to use the
> following line of code:
> String path = "C:/user/script/";
> CommandLine cmdLine = CommandLine.parse("myscript.cmd");
> DefaultExecutor executor = new DefaultExecutor();
> executor.setWorkingDirectory(new File(path));
> int exitValue = executor.execute(cmdLine);
> but I got an exception.
> I am using the following workaround:
> CommandLine cmdLine = CommandLine.parse(path+"/myscript.cmd");
> and it's working fine.
> The question is: are Executor and CommandLine related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (EXEC-95) Program not found after setWorkingDirectory
[
https://issues.apache.org/jira/browse/EXEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15082046#comment-15082046
]
Siegfried Goeschl commented on EXEC-95:
---
After some digging through the code
* the WinNTCommandLauncher is copied from a very old ANT source file
* WinNTCommandLauncher is actually never used (the same goes for
OS2CommandLauncher)
So the problem is completely unrelated to "WinNTCommandLauncher"
I assume that "C:/user/script/" is not part of the PATH variable therefore the
"myscript.cmd" was not found
> Program not found after setWorkingDirectory
> ---
>
> Key: EXEC-95
> URL: https://issues.apache.org/jira/browse/EXEC-95
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: win7 64 bit.
>Reporter: Lorenzo Cozza
>Assignee: Siegfried Goeschl
>
> I would like to run my script from a different folder, so I tried to use the
> following line of code:
> String path = "C:/user/script/";
> CommandLine cmdLine = CommandLine.parse("myscript.cmd");
> DefaultExecutor executor = new DefaultExecutor();
> executor.setWorkingDirectory(new File(path));
> int exitValue = executor.execute(cmdLine);
> but I got an exception.
> I am using the following workaround:
> CommandLine cmdLine = CommandLine.parse(path+"/myscript.cmd");
> and it's working fine.
> The question is: are Executor and CommandLine related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (EXEC-95) Program not found after setWorkingDirectory
[
https://issues.apache.org/jira/browse/EXEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15082046#comment-15082046
]
Siegfried Goeschl edited comment on EXEC-95 at 1/5/16 12:12 AM:
After some digging through the code
* the WinNTCommandLauncher is copied from a very old ANT source file
* WinNTCommandLauncher is actually never used (the same goes for
OS2CommandLauncher)
So the problem is completely unrelated to "WinNTCommandLauncher"
I assume that
* "C:/user/script/" is not part of the PATH variable therefore the
"myscript.cmd" was not found
* I'm not sure about Windows here - it seems that the script is not picked up
from the current working directory
was (Author: sgoeschl):
After some digging through the code
* the WinNTCommandLauncher is copied from a very old ANT source file
* WinNTCommandLauncher is actually never used (the same goes for
OS2CommandLauncher)
So the problem is completely unrelated to "WinNTCommandLauncher"
I assume that "C:/user/script/" is not part of the PATH variable therefore the
"myscript.cmd" was not found
> Program not found after setWorkingDirectory
> ---
>
> Key: EXEC-95
> URL: https://issues.apache.org/jira/browse/EXEC-95
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: win7 64 bit.
>Reporter: Lorenzo Cozza
>Assignee: Siegfried Goeschl
>
> I would like to run my script from a different folder, so I tried to use the
> following line of code:
> String path = "C:/user/script/";
> CommandLine cmdLine = CommandLine.parse("myscript.cmd");
> DefaultExecutor executor = new DefaultExecutor();
> executor.setWorkingDirectory(new File(path));
> int exitValue = executor.execute(cmdLine);
> but I got an exception.
> I am using the following workaround:
> CommandLine cmdLine = CommandLine.parse(path+"/myscript.cmd");
> and it's working fine.
> The question is: are Executor and CommandLine related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SCXML-242) Provide JSON based datamodel as replacement for XML/XPath
[
https://issues.apache.org/jira/browse/SCXML-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15082053#comment-15082053
]
Woonsan Ko commented on SCXML-242:
--
Great improvements and simplifications!
I have some remarks below:
First, {{ContentParser}} seems to be used privately by {{SCXMLReader}} at the
moment. If it's intended to be used that way, would it be better to mark it as
package private?
Second,
{code:title=SCXMLReader.java}
private static void readData(final XMLStreamReader reader, final
Configuration configuration, final Datamodel dm)
throws XMLStreamException, ModelException {
// SNIP
if (node.hasChildNodes()) {
NodeList children = node.getChildNodes();
if (children.getLength() == 1 && children.item(0).getNodeType() ==
Node.TEXT_NODE) {
String text =
configuration.contentParser.trimContent(children.item(0).getNodeValue());
if (configuration.contentParser.hasJsonSignature(text)) {
{code}
- Would it be an idea to simply use {{Node#getTextContent()}} instead? Then it
can allow CDATA_NODE as well with excluding comment or processing instruction.
- The {{#hasJsonSignature(String)}} is static, so
{{ContentParser.hasJsonSignature(text)}} looks better.
Finally, one minor thing is, maybe can we add commons-lang3 dependency as well?
We already have commons-io and commons-jexl. So if we can add commons-lang3,
then maybe we can replace {{ContentParser#trimContent(String)}} by
{{StringUtils#strip(String)}}, replace
{{ContentParser#spaceNormalizeContent(String)}} by
{{StringUtils#replacePattern("\s+", " ")}} and remove
{{ContentParser#isWhiteSpace(char)}}.
Anyway, this is a great improvement and thanks a lot for caring all of these.
Cheers,
Woonsan
> Provide JSON based datamodel as replacement for XML/XPath
> -
>
> Key: SCXML-242
> URL: https://issues.apache.org/jira/browse/SCXML-242
> Project: Commons SCXML
> Issue Type: New Feature
>Reporter: Ate Douma
>Assignee: Woonsan Ko
> Fix For: 2.0
>
>
> The XML/XPath datamodel, with 'convenient' support through Data() and
> Location() operations for usage within the Jexl, Javascript and Groovy SCXML
> languages has been the root and cause of many invasive and complicating
> problems in the implementation of Commons SCXML (2.0).
> The [SCXML 1.0 specification|http://www.w3.org/TR/2015/REC-scxml-20150901/]
> has dropped the xpath datamodel from the specification because of
> similar/same complications and (also thereof) lack of 'reference'
> implementations.
> Further maintaining and trying to 'improve' on the XML/XPath datamodel
> support in Commons SCXML therefore will be stopped and removed from the
> implementation all together.
> Instead and as replacement new JSON datamodel support will be added, which
> also aligns with the (optional) Ecmascript datamodel as described in the
> SCXML specification.
> The JSON based datamodel will be parsed (in Java) into a 'raw' object model,
> consisting of plain Maps (JSON Object) and Lists (JSON Array), and thus
> trivially to be used from the Commons SCXML supported languages (Jexl, Groovy
> and Javascript).
> As this new JSON datamodel will replace all XML/XPath usages, part of this
> new feature implementation will be updating and replacing all the
> example/unit-test usages in the codebase, and thereby also removing all
> usages of the custom Data() and Location() functions.
> Once these changes are in place, the Data() and Location() custom functions
> will then be removed as well.
> Finally, the XPath language itself then can be removed, including all the
> supporting logic scattered throughout the engine implementation itself, but
> this will be done as a separate issue afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SCXML-245) Reimplement Nashorn Javascript Evaluator
[ https://issues.apache.org/jira/browse/SCXML-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko resolved SCXML-245. -- Resolution: Fixed Assignee: Ate Douma (was: Woonsan Ko) > Reimplement Nashorn Javascript Evaluator > > > Key: SCXML-245 > URL: https://issues.apache.org/jira/browse/SCXML-245 > Project: Commons SCXML > Issue Type: Improvement >Reporter: Ate Douma >Assignee: Ate Douma > Fix For: 2.0 > > > The current Javascript context binding can be drastically improved and > simplified by using a binding which only delegates to the SCXML context it > wraps, and not (also) another binding and/or the Nashorn Global binding. > The SCXML context will be bound to the ScriptEngine.GLOBAL_SCOPE and for the > ScriptEngine.ENGINE_SCOPE the default Nashorn binding will be used, which > thereby will also hold and maps to the Nashorn Global itself. > Javascript script execution can add/modify new or 'shadowed' variables into > the Nashorn Global, these need to be copied/merged back into the SCXML > context after execution. > A separate ScriptContext will now be used for each JSEvaluator, to be > shared/reused across invocations. JSEvaluator instances therefore must be and > only can be used for a single SCXML instance (btw: like with the > GroovyEvaluator). > As the Nashorn Global cannot be serialized, modifications made from within > Javascript execution to the Global objects themselves (e.g. bind extra > properties/functions) will NOT be retained after serialization, and likewise > creating Javascript objects and 'returning' them to (using within) the SCXML > context will likewise NOT be serializable. > Javscript based SCXML instance serialization therefore is limited within > these constraints! > To support the SCXML requirements for protected system variables, the > Javascript Global will be initialized before first access with specific > "init_global.js" script, loaded as classpath resource, > which will bind these protected SCXML system properties into the Javscript > Global state, as well as the required SCXML In() predicate function. > Note that this uses the ECMAScript Object.bindProperties function, which is > NOT (yet) implemented by the Mozilla Rhino engine, which thus cannot be used > anymore, not even as optional extra dependency! > The Javascript engine itself, as the init_global.js script resource, is now > created statically only once and reused across all SCXML instances, which > might give a performance improvement as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SCXML-245) Reimplement Nashorn Javascript Evaluator
[ https://issues.apache.org/jira/browse/SCXML-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15082381#comment-15082381 ] Woonsan Ko commented on SCXML-245: -- Great fixes and cleanups! I thought we might be able to make it serializable with JS evaluator (with SCXML-233) before, but now I think you're totally right. The limitation should be accepted to do it right without any hacky / dead-end approaches. Thanks a lot! Cheers, Woonsan > Reimplement Nashorn Javascript Evaluator > > > Key: SCXML-245 > URL: https://issues.apache.org/jira/browse/SCXML-245 > Project: Commons SCXML > Issue Type: Improvement >Reporter: Ate Douma >Assignee: Woonsan Ko > Fix For: 2.0 > > > The current Javascript context binding can be drastically improved and > simplified by using a binding which only delegates to the SCXML context it > wraps, and not (also) another binding and/or the Nashorn Global binding. > The SCXML context will be bound to the ScriptEngine.GLOBAL_SCOPE and for the > ScriptEngine.ENGINE_SCOPE the default Nashorn binding will be used, which > thereby will also hold and maps to the Nashorn Global itself. > Javascript script execution can add/modify new or 'shadowed' variables into > the Nashorn Global, these need to be copied/merged back into the SCXML > context after execution. > A separate ScriptContext will now be used for each JSEvaluator, to be > shared/reused across invocations. JSEvaluator instances therefore must be and > only can be used for a single SCXML instance (btw: like with the > GroovyEvaluator). > As the Nashorn Global cannot be serialized, modifications made from within > Javascript execution to the Global objects themselves (e.g. bind extra > properties/functions) will NOT be retained after serialization, and likewise > creating Javascript objects and 'returning' them to (using within) the SCXML > context will likewise NOT be serializable. > Javscript based SCXML instance serialization therefore is limited within > these constraints! > To support the SCXML requirements for protected system variables, the > Javascript Global will be initialized before first access with specific > "init_global.js" script, loaded as classpath resource, > which will bind these protected SCXML system properties into the Javscript > Global state, as well as the required SCXML In() predicate function. > Note that this uses the ECMAScript Object.bindProperties function, which is > NOT (yet) implemented by the Mozilla Rhino engine, which thus cannot be used > anymore, not even as optional extra dependency! > The Javascript engine itself, as the init_global.js script resource, is now > created statically only once and reused across all SCXML instances, which > might give a performance improvement as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (EXEC-65) Watchdog can't destroy 'sudo' and 'sleep'
[
https://issues.apache.org/jira/browse/EXEC-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl updated EXEC-65:
--
Attachment: EXEC_65.patch
> Watchdog can't destroy 'sudo' and 'sleep'
> -
>
> Key: EXEC-65
> URL: https://issues.apache.org/jira/browse/EXEC-65
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: RedHat Enterprise Linux 64bit, JDK 1.6.0_25 64bit.
> {code}
> $ uname -a
> Linux demo-vrs1-happdb1.lts.stgt.vrs.cust.disy.net 2.6.9-42.ELsmp #1 SMP Wed
> Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
> {code}
> {code}
> $ java -version
> java version "1.6.0_25"
> Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
> Java HotSpot(TM) Server VM (build 20.0-b11, mixed mode)
> {code}
>Reporter: Rusi Filipov
>Assignee: Siegfried Goeschl
>Priority: Critical
> Attachments: EXEC_65.patch
>
>
> I want to run a command from a shell script with make sure the process will
> be destroyed after a timeout, especially if it asks for user input or
> contains sleep commands.
> {code:title=Java}
> DefaultExecutor executor = new DefaultExecutor();
> executor.setStreamHandler(new PumpStreamHandler(System.out, System.err));
> ExecuteWatchdog watchDog = new ExecuteWatchdog(3000);
> executor.setWatchdog(watchDog);
> CommandLine command = new CommandLine("./client.sh");
> int exitValue = executor.execute(command);
> System.out.println(exitValue);
> {code}
> I run this code on the server like this:
> {code}
> java -cp .:commons-exec-1.1.jar App
> {code}
> *Problem 1.* I want to run {{sudo}} in order to execute a script as a
> different user:
> {code:title=client.sh}
> #!/bin/bash
> sudo -u occ02 /apps/occ02/catalina_base/bin/restart-occ.sh
> {code}
> In case of a misconfiguration of {{/etc/sudoers}} this prompts me for a
> password.
> {code}
> Password:
> {code}
> And terminates only after about 5 minutes, not 3 seconds:
> {code}
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 143 (Exit value: 143)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy2(App.java:51)
> at App.main(App.java:21)
> {code}
> Only if I use the {{sudo -S ...}} the process is killed after about 4 seconds:
> {code}
> Password:
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 1 (Exit value: 1)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy2(App.java:51)
> at App.main(App.java:21)
> {code}
> *Problem 2.* I want to prevent a too long {{sleep}}:
> {code:title=client.sh}
> #!/bin/bash
> sleep 900
> {code}
> The Process just hangs! After 15 minutes the process terminates with this
> error:
> {code}
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 143 (Exit value: 143)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy2(App.java:51)
> at App.main(App.java:21)
> {code}
> If I run the {{sleep}} command directly from within Java without the
> shell-script, the process is destroyed on time:
> {code}
> DefaultExecutor executor = new DefaultExecutor();
> executor.setStreamHandler(new PumpStreamHandler(System.out, System.err));
> ExecuteWatchdog watchDog = new ExecuteWatchdog(3000);
> executor.setWatchdog(watchDog);
> CommandLine command = new CommandLine("sleep");
> command.addArgument("900");
> int exitValue = executor.execute(command);
> System.out.println(exitValue);
> {code}
> {code}
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 143 (Exit value: 143)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy4(App.java:67)
> at App.main(App.java:23)
> {code}
> The problems were not visible when I tested on my development machine with
> Windows 7 64bit and JDK
[jira] [Updated] (EXEC-95) Program not found after setWorkingDirectory
[
https://issues.apache.org/jira/browse/EXEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl updated EXEC-95:
--
Summary: Program not found after setWorkingDirectory (was: Programm not
found after setWorkingDirectory)
> Program not found after setWorkingDirectory
> ---
>
> Key: EXEC-95
> URL: https://issues.apache.org/jira/browse/EXEC-95
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: win7 64 bit.
>Reporter: Lorenzo Cozza
>Assignee: Siegfried Goeschl
>
> I would like to run my script from a different folder, so I tried to use the
> following line of code:
> String path = "C:/user/script/";
> CommandLine cmdLine = CommandLine.parse("myscript.cmd");
> DefaultExecutor executor = new DefaultExecutor();
> executor.setWorkingDirectory(new File(path));
> int exitValue = executor.execute(cmdLine);
> but I got an exception.
> I am using the following workaround:
> CommandLine cmdLine = CommandLine.parse(path+"/myscript.cmd");
> and it's working fine.
> The question is: are Executor and CommandLine related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (EXEC-95) Programm not found after setWorkingDirectory
[
https://issues.apache.org/jira/browse/EXEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl updated EXEC-95:
--
Summary: Programm not found after setWorkingDirectory (was: programm not
found after setWorkingDirectory)
> Programm not found after setWorkingDirectory
>
>
> Key: EXEC-95
> URL: https://issues.apache.org/jira/browse/EXEC-95
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: win7 64 bit.
>Reporter: Lorenzo Cozza
>Assignee: Siegfried Goeschl
>
> I would like to run my script from a different folder, so I tried to use the
> following line of code:
> String path = "C:/user/script/";
> CommandLine cmdLine = CommandLine.parse("myscript.cmd");
> DefaultExecutor executor = new DefaultExecutor();
> executor.setWorkingDirectory(new File(path));
> int exitValue = executor.execute(cmdLine);
> but I got an exception.
> I am using the following workaround:
> CommandLine cmdLine = CommandLine.parse(path+"/myscript.cmd");
> and it's working fine.
> The question is: are Executor and CommandLine related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (EXEC-65) Watchdog can't destroy 'sudo' and 'sleep'
[
https://issues.apache.org/jira/browse/EXEC-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081389#comment-15081389
]
Siegfried Goeschl commented on EXEC-65:
---
Wrote a few tests but I'm unable to reproduce the problem :-)
> Watchdog can't destroy 'sudo' and 'sleep'
> -
>
> Key: EXEC-65
> URL: https://issues.apache.org/jira/browse/EXEC-65
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: RedHat Enterprise Linux 64bit, JDK 1.6.0_25 64bit.
> {code}
> $ uname -a
> Linux demo-vrs1-happdb1.lts.stgt.vrs.cust.disy.net 2.6.9-42.ELsmp #1 SMP Wed
> Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
> {code}
> {code}
> $ java -version
> java version "1.6.0_25"
> Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
> Java HotSpot(TM) Server VM (build 20.0-b11, mixed mode)
> {code}
>Reporter: Rusi Filipov
>Assignee: Siegfried Goeschl
>Priority: Critical
> Attachments: EXEC_65.patch
>
>
> I want to run a command from a shell script with make sure the process will
> be destroyed after a timeout, especially if it asks for user input or
> contains sleep commands.
> {code:title=Java}
> DefaultExecutor executor = new DefaultExecutor();
> executor.setStreamHandler(new PumpStreamHandler(System.out, System.err));
> ExecuteWatchdog watchDog = new ExecuteWatchdog(3000);
> executor.setWatchdog(watchDog);
> CommandLine command = new CommandLine("./client.sh");
> int exitValue = executor.execute(command);
> System.out.println(exitValue);
> {code}
> I run this code on the server like this:
> {code}
> java -cp .:commons-exec-1.1.jar App
> {code}
> *Problem 1.* I want to run {{sudo}} in order to execute a script as a
> different user:
> {code:title=client.sh}
> #!/bin/bash
> sudo -u occ02 /apps/occ02/catalina_base/bin/restart-occ.sh
> {code}
> In case of a misconfiguration of {{/etc/sudoers}} this prompts me for a
> password.
> {code}
> Password:
> {code}
> And terminates only after about 5 minutes, not 3 seconds:
> {code}
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 143 (Exit value: 143)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy2(App.java:51)
> at App.main(App.java:21)
> {code}
> Only if I use the {{sudo -S ...}} the process is killed after about 4 seconds:
> {code}
> Password:
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 1 (Exit value: 1)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy2(App.java:51)
> at App.main(App.java:21)
> {code}
> *Problem 2.* I want to prevent a too long {{sleep}}:
> {code:title=client.sh}
> #!/bin/bash
> sleep 900
> {code}
> The Process just hangs! After 15 minutes the process terminates with this
> error:
> {code}
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 143 (Exit value: 143)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy2(App.java:51)
> at App.main(App.java:21)
> {code}
> If I run the {{sleep}} command directly from within Java without the
> shell-script, the process is destroyed on time:
> {code}
> DefaultExecutor executor = new DefaultExecutor();
> executor.setStreamHandler(new PumpStreamHandler(System.out, System.err));
> ExecuteWatchdog watchDog = new ExecuteWatchdog(3000);
> executor.setWatchdog(watchDog);
> CommandLine command = new CommandLine("sleep");
> command.addArgument("900");
> int exitValue = executor.execute(command);
> System.out.println(exitValue);
> {code}
> {code}
> Exception in thread "main" org.apache.commons.exec.ExecuteException: Process
> exited with an error: 143 (Exit value: 143)
> at
> org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:377)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:160)
> at
> org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:147)
> at App.destroy4(App.java:67)
> at App.main(App.java:23)
> {code}
> The problems were not visible
[jira] [Commented] (EXEC-95) Program not found after setWorkingDirectory
[
https://issues.apache.org/jira/browse/EXEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081398#comment-15081398
]
Siegfried Goeschl commented on EXEC-95:
---
Mhmm, it looks that way :-(
Since the original code of this class comes from Apache Ant I'm checking the
current implementation
> Program not found after setWorkingDirectory
> ---
>
> Key: EXEC-95
> URL: https://issues.apache.org/jira/browse/EXEC-95
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: win7 64 bit.
>Reporter: Lorenzo Cozza
>Assignee: Siegfried Goeschl
>
> I would like to run my script from a different folder, so I tried to use the
> following line of code:
> String path = "C:/user/script/";
> CommandLine cmdLine = CommandLine.parse("myscript.cmd");
> DefaultExecutor executor = new DefaultExecutor();
> executor.setWorkingDirectory(new File(path));
> int exitValue = executor.execute(cmdLine);
> but I got an exception.
> I am using the following workaround:
> CommandLine cmdLine = CommandLine.parse(path+"/myscript.cmd");
> and it's working fine.
> The question is: are Executor and CommandLine related?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (EXEC-89) Unit tests failing in WIn7 Pro 64-bit with Java 6 and 7
[
https://issues.apache.org/jira/browse/EXEC-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siegfried Goeschl updated EXEC-89:
--
Description:
I'm getting errors when running the unit tests in Windows7 Pro 64-bit. I've
tried with both JDK 6 and 7.
Specifically the problem seems to be with getting return codes from running
batch files. Seems like it always returns a zero even when there is an 'exit 1'
or 'exec /b 1' in the batch file.
The main test I need resolving is the
DefaultExecutorTest.testExecuteWithCustomExitValue1 test.
Here's the maven output. Sorry there seems to be no attachment button in this
bug report screen.
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Apache Commons Exec 1.2
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ commons-exec ---
[INFO] Deleting C:\java\commons-exec-1.2-src\target
[INFO]
[INFO] --- maven-antrun-plugin:1.7:run (javadoc.resources) @ commons-exec ---
[INFO] Executing tasks
main:
[copy] Copying 2 files to
C:\java\commons-exec-1.2-src\target\apidocs\META-INF
[INFO] Executed tasks
[INFO]
[INFO] --- maven-remote-resources-plugin:1.4:process (default) @ commons-exec
---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.2:create (default) @ commons-exec ---
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: cmd.exe /X /C "svn --non-interactive info"
[INFO] Working directory: C:\java\commons-exec-1.2-src
[INFO] Storing buildNumber: ?? at timestamp: 1413197018890
[INFO] Executing: cmd.exe /X /C "svn --non-interactive info"
[INFO] Working directory: C:\java\commons-exec-1.2-src
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
commons-exec ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\java\commons-exec-1.2-src\src\main\resources
[INFO] Copying 2 resources to META-INF
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ commons-exec
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 31 source files to C:\java\commons-exec-1.2-src\target\classes
[INFO]
[INFO] --- maven-bundle-plugin:2.4.0:manifest (bundle-manifest) @ commons-exec
---
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
commons-exec ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\java\commons-exec-1.2-src\src\test\resources
[INFO] Copying 2 resources to META-INF
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
commons-exec ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 11 source files to
C:\java\commons-exec-1.2-src\target\test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.15:test (default-test) @ commons-exec ---
[INFO] Surefire report directory:
C:\java\commons-exec-1.2-src\target\surefire-reports
---
T E S T S
---
Running org.apache.commons.exec.CommandLineTest
testToStringTroubleshooting
cmd1: [sh, -c, echo 1]
cmd2: [sh, -c, echo, 1]
Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec - in
org.apache.commons.exec.CommandLineTest
Running org.apache.commons.exec.DefaultExecutorTest
FOO..
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Process completed in 2015 millis; below is its output
Process timed out and was killed by watchdog.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit
value: 1)
Process completed in 2137 millis; below is its output
Process timed out and was killed.
FOO..
The test 'testExec36_1' does not support the following OS : Windows 7
The test 'testSyncInvocationOfBackgroundProcess' does not support the following
OS : Windows 7
Processes terminated: 0 killed: 181 Multiplier: 1 MaxRetries: 180 Elapsed (avg
ms): 1416
FOO..
{java.runtime.name=Java(TM) SE Runtime Environment,
sun.boot.library.path=C:\programs\jdk1.7.0_40\jre\bin,
java.vm.version=24.0-b56, java.vm.vendor=Oracle Corporation,
java.vendor.url=http://java.oracle.com/, path.separator=;, java.vm.name=Java
HotSpot(TM) 64-Bit Server VM, file.encoding.pkg=sun.io, user.country=GB,
user.script=, sun.java.launcher=SUN_STANDARD, sun.os.patch.level=Service Pack
1, java.vm.specification.name=Java Virtual Machine Specification,
user.dir=C:\java\commons-exec-1.2-src, java.runtime.version=1.7.0_40-b43,
basedir=C:\java\commons-exec-1.2-src,
[jira] [Resolved] (EXEC-85) error running mvn on eclipse
[ https://issues.apache.org/jira/browse/EXEC-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl resolved EXEC-85. --- Resolution: Incomplete No way to analyse the issue with the given information > error running mvn on eclipse > > > Key: EXEC-85 > URL: https://issues.apache.org/jira/browse/EXEC-85 > Project: Commons Exec > Issue Type: Bug >Reporter: Ramiro Matteoda > > I am using DefaultExecutor to run maven on my eclipse plugin. If I run the > command mvn --version to check maven version on my eclipse on Mac OSX Snow > Leopard It work fine, but, if I run it on MAC OSx Maverick it give an error > (error=2 ..) command not found or something like that. I can not figure out > the problem, In both OSx the maven is installed correct and running mvn > --version on a terminal It works. > Regards > Ramiro -- This message was sent by Atlassian JIRA (v6.3.4#6332)
