[jira] [Commented] (EXEC-64) DefaultExecutor swallows IOException cause instead of propagating it
[
https://issues.apache.org/jira/browse/EXEC-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110878#comment-15110878
]
Michael Vorburger commented on EXEC-64:
---
Thanks. [~s...@apache.org] nice one how to still provide the cause using
initCause() even on < 1.6!
> DefaultExecutor swallows IOException cause instead of propagating it
>
>
> Key: EXEC-64
> URL: https://issues.apache.org/jira/browse/EXEC-64
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Michael Vorburger
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: exec-64.patch
>
>
> DefaultExecutor line 372 does:
> {noformat}
> } catch (Exception e) {
> throw new IOException(e.getMessage());
> }
> {noformat}
> when it may be better to do:
> {noformat}
> } catch (Exception e) {
> throw new IOException(e.getMessage(), e);
> }
> {noformat}
> This didn't cause any real issues for me - I just came across it as I was
> browsing the Commons Exec source, in the context of implementing a launch
> helper (BTW: see
> https://github.com/vorburger/MariaDB4j/blob/master/src/main/java/ch/vorburger/exec/ManagedProcess.java
> - would that, once further cleaned-up, potentially be something of any
> interest to you for integration into Commons Exec?).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (EXEC-93) Handling of escaped values by StringUtils
[
https://issues.apache.org/jira/browse/EXEC-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14910130#comment-14910130
]
Michael Vorburger commented on EXEC-93:
---
Aloha.. is commons-exec still actively maintained? Can you guys merge this? I'm
asking because this issue is affecting me too.. while fixing
https://github.com/vorburger/MariaDB4j/issues/30 I've found that something à la
addArgument("--datadir='/tmp/dir with space'") is not correctly handled,
because the current (in commons-exec v1.3) code seems to assume that quotes are
necessarily around a complete Argument, which is not correct, so in this
example it seems to strip the trailing ' but leave the one after = and creates
a mess. From what I glanced over in the attached EXEC-93.patch (not tried out /
not code reviewed in more details) it would appear that this would fix that
problem - it would be great to see this in a commons-exec v1.4 release.
> Handling of escaped values by StringUtils
> -
>
> Key: EXEC-93
> URL: https://issues.apache.org/jira/browse/EXEC-93
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3, 1.4
>Reporter: Viktor Sadovnikov
> Fix For: 1.4
>
> Attachments: EXEC-93.patch
>
>
> An arguments can contain an environment variable value. For example, in
> command {{cd /tmp && STORAGE_DIR=/tmp resolve.sh}} {{STORAGE_DIR=/tmp}} is an
> argument, which is used by {{resolve.sh}}.
> However values of the variables can be more complicated and can contain
> escaped quotes. Current implementation of
> {{StringUtils#quoteArgument(String)}} does not handle these values correctly.
> Attached patch contains fix for this problem and unit tests to demonstrate
> the problem and the fix
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (VFS-537) use WatchService when it is available
[ https://issues.apache.org/jira/browse/VFS-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491540#comment-14491540 ] Michael Vorburger commented on VFS-537: --- I just published something similar, see http://blog2.vorburger.ch/2015/04/java-7-watchservice-based.html; DirectoryWatcher etc. src currently part of https://github.com/vorburger/HoTea - if this is of any interest to Apache Commons, feel free to use it.. > use WatchService when it is available > - > > Key: VFS-537 > URL: https://issues.apache.org/jira/browse/VFS-537 > Project: Commons VFS > Issue Type: Wish >Reporter: Sam Halliday > > I'm sure you're aware of the WatchService in JDK7. > It would be utterly amazing if you could detect at runtime that the code is > running on Java 7 and then use the WatchService as the backend for > DefaultFileMonitor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-470) Using WatchService in Tailer instead of polling
[ https://issues.apache.org/jira/browse/IO-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491541#comment-14491541 ] Michael Vorburger commented on IO-470: -- I just published something similar, see http://blog2.vorburger.ch/2015/04/java-7-watchservice-based.html; DirectoryWatcher etc. src currently part of https://github.com/vorburger/HoTea - if this is of any interest to Apache Commons, feel free to use it.. > Using WatchService in Tailer instead of polling > --- > > Key: IO-470 > URL: https://issues.apache.org/jira/browse/IO-470 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Jeremiah Orr > Labels: Java7, Tailer > Fix For: 2.5 > > Original Estimate: 24h > Remaining Estimate: 24h > > Tailer would benefit from using Java 7's WatchService to detect file changes > instead of polling at a set interval. Tailer could respond quicker to > changes, and it would save the system from constant polling. This of course > would mean that commons-io would require Java 7. > I don't know what the future release plans are for commons-io; if there's an > upcoming version that will require Java 7, I'll happily make this change > myself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (EXEC-63) Race condition in DefaultExecutor#execute(cmd, handler)
[
https://issues.apache.org/jira/browse/EXEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Vorburger updated EXEC-63:
--
Attachment: EXEC-63_DefaultExecutor.patch
Just in case this may help in moving forward with integrating this one, as I've
noticed that commons-exec is still on SVN and not Git, I've created the
attached via svn diff >EXEC-63_DefaultExecutor.patch of the change proposed
above (manually retyped it, exact same thing; as I wanted to try this out
applied on top of current latest commons-exec trunk). I'm too lazy to do the
same for the other patch for new testExec_63() in DefaultExecutorTest.
It appears this proposed change breaks existing Exec60Test.testExec_60() line
86 ("Not a single process was killed by the watch dog") when applied as-is to
current latest SVN rev 1640638. I have not investigated if this would be easy
to fix, or is a sign of a real regression this patch would cause.. and how to
improve this patch.. [~britter] perhaps you could look into this?
PS: I was trying out if this one fixes my
https://github.com/vorburger/MariaDB4j/issues/10 issue (it does not, that's an
unrelated problem).
> Race condition in DefaultExecutor#execute(cmd, handler)
> ---
>
> Key: EXEC-63
> URL: https://issues.apache.org/jira/browse/EXEC-63
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Windows 7/64 bit, JDK 1.6.0_27
>Reporter: Martin Sandiford
> Labels: deadlock
> Attachments: EXEC-63_DefaultExecutor.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> {{DefaultExecutor#execute(CommandLine, ExecuteResultHandler)}} can, and
> usually does, return before the target process has actually started. This
> can result in a race condition where several asynchronous processes are
> coupled by {{PipedInputStream}}/{{PipedOutputStream}} objects.
> The following example shows the issue:
> {code:title=Borken.java|borderStyle=solid}
> import java.io.*;
> import org.apache.commons.exec.*;
> public class Borken {
> public static int pipe(OutputStream out, OutputStream err, InputStream in,
> CommandLine cmd0, CommandLine cmd1)
> throws IOException {
> PipedInputStream pipeIn = new PipedInputStream();
> PipedOutputStream pipeOut = new PipedOutputStream(pipeIn);
> DefaultExecutor exec0 = new DefaultExecutor();
> exec0.setStreamHandler(new PumpStreamHandler(pipeOut, null, in));
> exec0.execute(cmd0, new DefaultExecuteResultHandler());
>
> // If the following line is commented, deadlock occurs
> //try { Thread.sleep(100); } catch (InterruptedException e) { }
> DefaultExecutor exec1 = new DefaultExecutor();
> exec1.setStreamHandler(new PumpStreamHandler(out, err, pipeIn));
> return exec1.execute(cmd1);
> }
>
> public static void main(String... args) {
> CommandLine cmd0 = new
> CommandLine("cmd").addArgument("/c").addArgument("dir");
> //CommandLine cmd0 = new CommandLine("ls").addArgument("-l");
> CommandLine cmd1 = new CommandLine("sort");
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> ByteArrayOutputStream err = new ByteArrayOutputStream();
> ByteArrayInputStream in = new ByteArrayInputStream(new byte[0]);
> try {
> int result = pipe(out, err, in, cmd0, cmd1);
> System.out.format("Result code: %d%n", result);
> System.out.format("Out: %s%n", out.toString());
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> {code}
> One possible solution is to pass in a semaphore object into
> {{DefaultExecutor#executeInternal}} which is notified once the process is
> started. The {{execute(CommandLine, Map, ExecuteResultHandler)}} method can
> then wait on this before returning.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (EXEC-88) ManagedProcess, higher-level abstraction for controlling async "daemon tools" (contribution from MariaDB4j)
Michael Vorburger created EXEC-88: - Summary: ManagedProcess, higher-level abstraction for controlling async "daemon tools" (contribution from MariaDB4j) Key: EXEC-88 URL: https://issues.apache.org/jira/browse/EXEC-88 Project: Commons Exec Issue Type: New Feature Reporter: Michael Vorburger Hello Commons Exec-ians, see https://github.com/vorburger/MariaDB4j/blob/10747327a1822a719ff35aaba6b4a4a42103424c/src/main/java/ch/vorburger/exec/ManagedProcess.java would my ManagedProcess helper (and a few related util classes from ch.vorburger.exec), which extends commons-exec with a higher-level abstraction over your for controlling async "daemon tools" be of possibly interest as a contribution to commons-exec? I wrote it for and am using it in MariaDB4j https://github.com/vorburger/MariaDB4j. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (EXEC-69) DefaultExecutor async execute prevents shutdown hooks running
[ https://issues.apache.org/jira/browse/EXEC-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072472#comment-14072472 ] Michael Vorburger commented on EXEC-69: --- Hello! I've just hit this problem as well... :-( +1 for fixing this, and releasing a commons-exec 1.3! Background of context I ran into this is in https://github.com/vorburger/MariaDB4j/issues/12, in case anyone is interested (part of my https://github.com/vorburger/MariaDB4j mySQL embedder - shameless plug). Also note how in https://github.com/vorburger/MariaDB4j/blob/c05ec7650afee823f505a530c75945f7e008c54e/src/main/java/ch/vorburger/exec/BetterExecutor.java I've used Thread t = super.createThread(runnable, name); instead of new Thread(runnable, name); as in attached DaemonExecutor.java (thank you [~richarda]!) - just in the (unlikely, yes) case that a newer commons-exec does anything else in there (like set a more suitable Thread name, perhaps?). > DefaultExecutor async execute prevents shutdown hooks running > - > > Key: EXEC-69 > URL: https://issues.apache.org/jira/browse/EXEC-69 > Project: Commons Exec > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Richard Atkins > Attachments: DaemonExecutor.java > > > The DefaultExecutor asynchronous execute methods create a user-level thread > to monitor the process it starts. This prevents shutdown hooks - like the one > in ShutdownHookProcessDestroyer - from running. This makes these two classes > incompatible. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (BEANUTILS-406) DynaClassReader to read DynaClass definitions from a "DSL"
[
https://issues.apache.org/jira/browse/BEANUTILS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591832#comment-13591832
]
Michael Vorburger commented on BEANUTILS-406:
-
Benedikt, if you / Apache Commons think that this is of interest / still
relevant, then I would be more than happy to contribute to BeanUtils. As you
can see from https://github.com/vorburger/mon, even though I personally dropped
above since, related matters continue to fascinate me.. ;)
> DynaClassReader to read DynaClass definitions from a "DSL"
> --
>
> Key: BEANUTILS-406
> URL: https://issues.apache.org/jira/browse/BEANUTILS-406
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: DynaBean
>Affects Versions: 1.8.3
>Reporter: Michael Vorburger
>Assignee: Benedikt Ritter
> Fix For: LATER THAN 1.8.4
>
> Attachments:
> 0002-BEANUTILS-406-DynaClassReader-to-read-DynaClass-defi.patch
>
>
> It could sometimes be very useful to create DynaClass definitions not only
> programmatically (as is possible today), but to define data structures in
> some textual format (a "DSL"), and load that into DynaClass/DynaProperty and
> create DynaBeans from that.
> This isn't very hard to add to BeanUtils (I've done it and will attach a
> patch) and would allow the following usage, given:
> {noformat}Address {
> zip: java.lang.Long
> }
> Employee {
> firstName : java.lang.String
> lastName :java.lang.String
>
> mainAddress : Address
> boss : Employee
> subordinates : Employee *
> address : Address <>
> }{noformat}
> one could then use the new proposed DynaClassReader like so:
> {noformat}DynaClassReader r = new DynaClassReader();
> r.readClasspathResource("/DynaClassReaderTest.domain.txt");
> DynaClass klass = r.getDynaClass("Employee");
> {noformat}
> This requires BEANUTILS-405.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BEANUTILS-406) DynaClassReader to read DynaClass definitions from a "DSL"
[
https://issues.apache.org/jira/browse/BEANUTILS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591560#comment-13591560
]
Michael Vorburger commented on BEANUTILS-406:
-
Hi Benedikt, thanks for the interest. This was a while ago.. ;) Personally I've
moved on since then to EMF which thanks to http://wiki.eclipse.org/Xcore now
offers something very similar. Unfortunately many people (unjustifieldy!) still
think of EMF as an "Eclipse technology only" (when, actually, if runs just fine
"standalone"), and my impression has been that Bean Utils Dyna Beans, though
dated, appears to still be better known within the Java community at large.
> DynaClassReader to read DynaClass definitions from a "DSL"
> --
>
> Key: BEANUTILS-406
> URL: https://issues.apache.org/jira/browse/BEANUTILS-406
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: DynaBean
>Affects Versions: 1.8.3
>Reporter: Michael Vorburger
>Assignee: Benedikt Ritter
> Fix For: LATER THAN 1.8.4
>
> Attachments:
> 0002-BEANUTILS-406-DynaClassReader-to-read-DynaClass-defi.patch
>
>
> It could sometimes be very useful to create DynaClass definitions not only
> programmatically (as is possible today), but to define data structures in
> some textual format (a "DSL"), and load that into DynaClass/DynaProperty and
> create DynaBeans from that.
> This isn't very hard to add to BeanUtils (I've done it and will attach a
> patch) and would allow the following usage, given:
> {noformat}Address {
> zip: java.lang.Long
> }
> Employee {
> firstName : java.lang.String
> lastName :java.lang.String
>
> mainAddress : Address
> boss : Employee
> subordinates : Employee *
> address : Address <>
> }{noformat}
> one could then use the new proposed DynaClassReader like so:
> {noformat}DynaClassReader r = new DynaClassReader();
> r.readClasspathResource("/DynaClassReaderTest.domain.txt");
> DynaClass klass = r.getDynaClass("Employee");
> {noformat}
> This requires BEANUTILS-405.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-503) GetterMethodsReflectionToStringBuilder (code attached, proposal for integration)
[ https://issues.apache.org/jira/browse/LANG-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709512#action_12709512 ] Michael Vorburger commented on LANG-503: http://www.vorburger.ch/blog1/2009/05/gettermethodsreflectiontostringbuilder.html > GetterMethodsReflectionToStringBuilder (code attached, proposal for > integration) > > > Key: LANG-503 > URL: https://issues.apache.org/jira/browse/LANG-503 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Michael Vorburger > Fix For: 3.0 > > Attachments: GetterMethodsReflectionToStringBuilder.java, > GetterMethodsReflectionToStringBuilderTest.java, SomeTestBean.java > > > The ReflectionToStringBuilder "reflects" on fields... I needed one that works > based on public getters(). > This is useful for example with some kind of value objects where the internal > private field structure is not really what you would want to see in a > toString(), but which have a series of getters which were exactly what was > frequently required to be dumped. There is probably other uses too (e.g. > works even with a SecurityManager - that's not what I wrote it for, but could > be an advantage over the ReflectionToStringBuilder?). > I have hacked this and will attach a > GetterMethodsReflectionToStringBuilder.java (which extends > ReflectionToStringBuilder; works fine, for my use) with a > GetterMethodsReflectionToStringBuilderTest (which may need some coverage > extension, but is certainly a valid basic unit test) with its SomeTestBean. > I'll attach for your consideration to integrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-503) GetterMethodsReflectionToStringBuilder (code attached, proposal for integration)
[ https://issues.apache.org/jira/browse/LANG-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger updated LANG-503: --- Attachment: SomeTestBean.java GetterMethodsReflectionToStringBuilderTest.java GetterMethodsReflectionToStringBuilder.java > GetterMethodsReflectionToStringBuilder (code attached, proposal for > integration) > > > Key: LANG-503 > URL: https://issues.apache.org/jira/browse/LANG-503 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Michael Vorburger > Fix For: 3.0 > > Attachments: GetterMethodsReflectionToStringBuilder.java, > GetterMethodsReflectionToStringBuilderTest.java, SomeTestBean.java > > > The ReflectionToStringBuilder "reflects" on fields... I needed one that works > based on public getters(). > This is useful for example with some kind of value objects where the internal > private field structure is not really what you would want to see in a > toString(), but which have a series of getters which were exactly what was > frequently required to be dumped. There is probably other uses too (e.g. > works even with a SecurityManager - that's not what I wrote it for, but could > be an advantage over the ReflectionToStringBuilder?). > I have hacked this and will attach a > GetterMethodsReflectionToStringBuilder.java (which extends > ReflectionToStringBuilder; works fine, for my use) with a > GetterMethodsReflectionToStringBuilderTest (which may need some coverage > extension, but is certainly a valid basic unit test) with its SomeTestBean. > I'll attach for your consideration to integrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-503) GetterMethodsReflectionToStringBuilder (code attached, proposal for integration)
GetterMethodsReflectionToStringBuilder (code attached, proposal for integration) Key: LANG-503 URL: https://issues.apache.org/jira/browse/LANG-503 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.4 Reporter: Michael Vorburger Fix For: 3.0 The ReflectionToStringBuilder "reflects" on fields... I needed one that works based on public getters(). This is useful for example with some kind of value objects where the internal private field structure is not really what you would want to see in a toString(), but which have a series of getters which were exactly what was frequently required to be dumped. There is probably other uses too (e.g. works even with a SecurityManager - that's not what I wrote it for, but could be an advantage over the ReflectionToStringBuilder?). I have hacked this and will attach a GetterMethodsReflectionToStringBuilder.java (which extends ReflectionToStringBuilder; works fine, for my use) with a GetterMethodsReflectionToStringBuilderTest (which may need some coverage extension, but is certainly a valid basic unit test) with its SomeTestBean. I'll attach for your consideration to integrate this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
