[jira] Created: (COMMONSSITE-35) Unable to use commons:jira-page on Windows
Unable to use commons:jira-page on Windows
--
Key: COMMONSSITE-35
URL: https://issues.apache.org/jira/browse/COMMONSSITE-35
Project: Commons All
Issue Type: Bug
Components: Commons Build Plugin
Reporter: Dennis Lundberg
I am unable to use the commons:jira-page goal on Windows. It seems to be a
problem with spaces in the path.
Here is the stack trace I get:
{noformat}
G:\apache\commons\trunks-proper\exec>mvn commons:jira-page
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'commons'.
[INFO]
[INFO] Building Commons Exec
[INFO]task-segment: [commons:jira-page]
[INFO]
[INFO] [commons:jira-page]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
Illegal character in path at index 18: file:/C:/Documents and
Settings/dlg01/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
[INFO]
[INFO] Trace
java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:838)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.tools.ant.launch.Locator.fromURI(Locator.java:162)
at
org.apache.tools.ant.launch.Locator.getResourceSource(Locator.java:119)
at org.apache.tools.ant.launch.Locator.getClassSource(Locator.java:90)
at org.apache.tools.ant.Project.setAntLib(Project.java:313)
at org.apache.tools.ant.Project.initProperties(Project.java:309)
at org.apache.tools.ant.Project.init(Project.java:295)
at
org.codehaus.plexus.component.factory.ant.AntScriptInvoker.initializeProject(AntScriptInvoker.java:251)
at
org.codehaus.plexus.component.factory.ant.AntScriptInvoker.invoke(AntScriptInvoker.java:174)
at
org.apache.maven.script.ant.AntMojoWrapper.execute(AntMojoWrapper.java:52)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.net.URISyntaxException: Illegal character in path at index 18:
file:/C:/Documents and
Settings/dlg01/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
at java.net.URI$Parser.fail(URI.java:2752)
at java.net.URI$Parser.checkChars(URI.java:2925)
at java.net.URI$Parser.parseHierarchical(URI.java:3009)
at java.net.URI$Parser.parse(URI.java:2957)
at java.net.URI.(URI.java:574)
at java.net.URI.create(URI.java:836)
... 31 more
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Sat Jun 28 07:58:01 CEST 2008
[INFO] Final Memory: 6M/11M
[INFO]
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue onli
[jira] Moved: (EXEC-15) [exec][patch] ExecTest fails due to improperly formatted src/test/scripts/test.sh
[ https://issues.apache.org/jira/browse/EXEC-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-36 to EXEC-15: Component/s: (was: Exec) Key: EXEC-15 (was: SANDBOX-36) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] ExecTest fails due to improperly formatted > src/test/scripts/test.sh > - > > Key: EXEC-15 > URL: https://issues.apache.org/jira/browse/EXEC-15 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: Linux > Platform: All >Reporter: Jerome Lacoste > Attachments: 36182.diff > > > On Linux, the following script invoked with the BAR argument will result in > FOO BAR > The unit test expects > FOO BAR > -- > #!/bin/sh > echo FOO $TEST_ENV_VAR $1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-6) [exec] Watchdog test cases and argument quotation fix
[
https://issues.apache.org/jira/browse/EXEC-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg moved SANDBOX-192 to EXEC-6:
Component/s: (was: Exec)
Affects Version/s: (was: Nightly Builds)
Key: EXEC-6 (was: SANDBOX-192)
Project: Commons Exec (was: Commons Sandbox)
> [exec] Watchdog test cases and argument quotation fix
> -
>
> Key: EXEC-6
> URL: https://issues.apache.org/jira/browse/EXEC-6
> Project: Commons Exec
> Issue Type: Bug
> Environment: apache commons exec trunk/head; M$ Windows XP
>Reporter: Reinhold Füreder
>Assignee: Siegfried Goeschl
> Attachments: patch_apache-commons-exec.txt, ProcessTest.java,
> ProcessTest.java
>
>
> Please find attached a patch for apache commons exec with respect to two
> issues (note that I have only tested them under M$ Windows yet, but I am very
> confident that these changes should work under *nix too):
> ---
> (1) ExecuteWatchdog test cases (DefaultExecutorTest.java): one for
> synchronous and one for asynchronous execution including the required test
> scripts (watchdog.bat, watchdog.sh) and test app (JavaApp.java). Whereas the
> one for asynchronous is a bit more elaborated and kind of "more correct",
> please note the hint on the well-known Java "bug"/issue under M$ Windows with
> respect to the Process.destroy() method in the asynchronous test case code.
> ---
> (2) Add a method to CommandLine (CommandLine.java) to add arguments without
> quoting, i.e. pre-quoted arguments, because default quoting may not be
> correct in all cases. Note that I have not tried to find out if the default
> quoting can be changed accordingly. And also that maybe this problem is only
> M$ Windows specific, but I don't know (yet). The encountered problem was:
> I want to start an executable (runMemorySud.cmd) with a list of JVM GC
> options that in turn will then start a Java application utilising these JVM
> GC options. I failed to find an accepted way of specifying the following:
> runMemorySud.cmd -XX:+UseParallelGC -XX:ParallelGCThreads=2
> After quite some time I found out that the default quoting of apache commons
> exec is causing the problem, and with default pure standard Java it works as
> expected by using (see attached ProcessTest.java example):
> Process p = new ProcessBuilder("runMemorySud.cmd", "10", "30",
> "-XX:+UseParallelGC", "\"-XX:ParallelGCThreads=2\"").start();
> However, as I said, I found no way of being able to "propagate this to the
> ProcessBuilder through apache commons exec". Thus, the need for adding a
> so-called pre-quoted argument addArgument() method.
> ---
> Would you mind applying these patches? Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-14) [exec] Environment: lack some HashMap methods delegation
[ https://issues.apache.org/jira/browse/EXEC-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-32 to EXEC-14: Component/s: (was: Exec) Key: EXEC-14 (was: SANDBOX-32) Project: Commons Exec (was: Commons Sandbox) > [exec] Environment: lack some HashMap methods delegation > > > Key: EXEC-14 > URL: https://issues.apache.org/jira/browse/EXEC-14 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste > Attachments: 36795_fix_hashmap_inherit.diff > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-9) [exec][patch] Use Contants class to store final static strings, added SafeOutputstream to remove redundant z/Os code
[ https://issues.apache.org/jira/browse/EXEC-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-18 to EXEC-9: --- Component/s: (was: Exec) Key: EXEC-9 (was: SANDBOX-18) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] Use Contants class to store final static strings, added > SafeOutputstream to remove redundant z/Os code > > > Key: EXEC-9 > URL: https://issues.apache.org/jira/browse/EXEC-9 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Kev Jackson >Assignee: Siegfried Goeschl > Attachments: constants_outputstream.patch > > > + Constants.java > - contains final static strings > + SafeOutputStream > - contains safe static method for toString() for use with z/Os (which requires > an encoding before writing) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-8) [exec] Use Java 1.5 support for getting environment
[ https://issues.apache.org/jira/browse/EXEC-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-4 to EXEC-8: -- Component/s: (was: Exec) Key: EXEC-8 (was: SANDBOX-4) Project: Commons Exec (was: Commons Sandbox) > [exec] Use Java 1.5 support for getting environment > --- > > Key: EXEC-8 > URL: https://issues.apache.org/jira/browse/EXEC-8 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Niklas Gustavsson > Attachments: 36222.patch > > > Where available, the new System.getenv() method should be used to retrive the > environment in which the process is executed. > I got a patch for this but since it overlaps with the patch for 36159 I'll > hold > it of until that first patch is commited. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-24) [exec] Watchdog "shutdown"
[
https://issues.apache.org/jira/browse/EXEC-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg moved SANDBOX-193 to EXEC-24:
-
Fix Version/s: (was: Nightly Builds)
Component/s: (was: Exec)
Key: EXEC-24 (was: SANDBOX-193)
Project: Commons Exec (was: Commons Sandbox)
> [exec] Watchdog "shutdown"
> --
>
> Key: EXEC-24
> URL: https://issues.apache.org/jira/browse/EXEC-24
> Project: Commons Exec
> Issue Type: Improvement
>Reporter: Reinhold Füreder
>Assignee: Siegfried Goeschl
>
> In my unit tests I use apache commons exec in combination with the execution
> watchdog for running some (Java) processes. By default, the processes should
> end normally. However, in case of an error the processes might still be
> running so I'd like to shut them down in the tearDown() cleanup step of the
> test case. In order to avoid modifying apache commons exec this is currently
> implemented like:
> @Override
> protected void tearDown() throws Exception {
> ...
> // This will implicitely lead to the required Process.destroy()
> call in case the process has not yet exited:
> watchdog.timeoutOccured(new Watchdog(1));
> watchdog.stop();
> ...
> }
> There are two issues:
> (1) At least in the current implementation there does not seem to be any
> reason anymore for the dummy watchdog argument in the timeoutOccured()
> method. Should we remove that? Of course this would also mean to remove it
> from the corresponding TimeoutObserver interface method. On the other hand,
> it removes some of the flexibility in case e.g. one extends the
> ExecuteWatchdog and requires more than one watchdog or so...
> (2) If this kind of watchdog "shutdown" (is there a better name?) is
> generally useful, shall we introduce an explicit method for it in the
> Watchdog class itself?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-21) [Exec] allow easy mocking of Process creation
[
https://issues.apache.org/jira/browse/EXEC-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg moved SANDBOX-62 to EXEC-21:
Component/s: (was: Exec)
Key: EXEC-21 (was: SANDBOX-62)
Project: Commons Exec (was: Commons Sandbox)
> [Exec] allow easy mocking of Process creation
> -
>
> Key: EXEC-21
> URL: https://issues.apache.org/jira/browse/EXEC-21
> Project: Commons Exec
> Issue Type: Bug
> Environment: Operating System: other
> Platform: Other
>Reporter: Jerome Lacoste
>Assignee: Siegfried Goeschl
> Attachments: 36707_allow_mocking_process_in_execute.diff
>
>
> In order to do proper unit testing, it is practical to use mocked Process
> instances. Unfortunately the Execute class doesn't make it easy to plug these
> classes. It calls the public static launch() method (which cannot be
> overriden)
> and that method uses the vmlauncher which cannot be replaced.
> I see 3 options:
> - mock the Process creation. Create a protected launchCommand() method that
> does
> call the public static launch() method. That protected method can be overriden
> by sub-classes.
> public static Process launch(final CommandLine command,
> final Environment env, final File dir)
> throws IOException {
> CommandLauncher launcher = vmLauncher;
> if (dir != null && !dir.exists()) {
> throw new IOException(dir + " doesn't exist.");
> }
> return launcher.exec(command, env, dir);
> }
> // hook for mock
> protected Process launchCommand(final CommandLine command,
> final Environment env, final File dir)
> throws IOException {
> return launch(command, env, dir);
> }
> - mock the Launcher creation which will itself be mocked.
> public static Process launch(final CommandLine command,
> final Environment env, final File dir)
> throws IOException {
> return launch(command, env, dir, vmLauncher);
> }
> private static Process launch(final CommandLine command,
> final Environment env, final File dir, CommandLauncher launcher)
> throws IOException {
> if (dir != null && !dir.exists()) {
> throw new IOException(dir + " doesn't exist.");
> }
> return launcher.exec(command, env, dir);
> }
> private Process launchCommand(final CommandLine command,
> final Environment env, final File dir)
> throws IOException {
> return launch(command, env, dir, getLauncher());
> }
> // hook for mock
> protected CommandLauncher getLauncher() {
> return vmlauncher;
> }
> - a combination of both
> I attach a patch that solves it using solution #1.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-22) [exec] Generalize ProcessDestroyer
[ https://issues.apache.org/jira/browse/EXEC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-49 to EXEC-22: Component/s: (was: Exec) Key: EXEC-22 (was: SANDBOX-49) Project: Commons Exec (was: Commons Sandbox) > [exec] Generalize ProcessDestroyer > -- > > Key: EXEC-22 > URL: https://issues.apache.org/jira/browse/EXEC-22 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Niklas Gustavsson > Attachments: 36287_generalize_processdestroyer.patch > > > ProcessDestroyer is currently an implementation that destroys all Processes > still alive when the VM exits. It should be generalized so that other > implementations could be plugged in, for example to destroy Processes when an > application is undeployed. > Note that this bug does not cover the issue of ProcessDestroyer being > mandatory, > that another bug soon to be created. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-20) [exec] EnvironmentVariable: inline private constructor
[ https://issues.apache.org/jira/browse/EXEC-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-51 to EXEC-20: Component/s: (was: Exec) Key: EXEC-20 (was: SANDBOX-51) Project: Commons Exec (was: Commons Sandbox) > [exec] EnvironmentVariable: inline private constructor > -- > > Key: EXEC-20 > URL: https://issues.apache.org/jira/browse/EXEC-20 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste >Assignee: Siegfried Goeschl > Attachments: 36796_environment_variable_inline_constructor.diff > > > Move the key=value String parsing inside the factory method and remove the > private constructor. > There's no need for both and parsing logic is better outside of a constructor > (as a rule and to make things similar with the rest of the code), especially > whe > n there's already a factory. > Removing the constructor doesn't create an issue as it's private and there's > already another private one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-19) [exec] several strange design / code decisions
[ https://issues.apache.org/jira/browse/EXEC-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-38 to EXEC-19: Component/s: (was: Exec) Key: EXEC-19 (was: SANDBOX-38) Project: Commons Exec (was: Commons Sandbox) > [exec] several strange design / code decisions > -- > > Key: EXEC-19 > URL: https://issues.apache.org/jira/browse/EXEC-19 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste > Attachments: 36978_TODO_questions.diff > > > add @todo around to show potential problems in the design -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-18) [exec][patch] added Javadoc to CommandLine interface
[ https://issues.apache.org/jira/browse/EXEC-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-94 to EXEC-18: Component/s: (was: Exec) Key: EXEC-18 (was: SANDBOX-94) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] added Javadoc to CommandLine interface > > > Key: EXEC-18 > URL: https://issues.apache.org/jira/browse/EXEC-18 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Kev Jackson > Attachments: CommandLine.patch > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-23) Cleanup the code
[ https://issues.apache.org/jira/browse/EXEC-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-204 to EXEC-23: - Component/s: (was: Exec) Key: EXEC-23 (was: SANDBOX-204) Project: Commons Exec (was: Commons Sandbox) > Cleanup the code > > > Key: EXEC-23 > URL: https://issues.apache.org/jira/browse/EXEC-23 > Project: Commons Exec > Issue Type: Improvement >Reporter: Siegfried Goeschl >Assignee: Siegfried Goeschl >Priority: Minor > > The code looks a bit untidy - broken & missing javadocs, unused imports, > missing comments - might be a good thing to do past midnight when the family > is asleep ... :-) > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-17) Support for non-standard exit values indicating successful execution
[ https://issues.apache.org/jira/browse/EXEC-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-203 to EXEC-17: - Component/s: (was: Exec) Key: EXEC-17 (was: SANDBOX-203) Project: Commons Exec (was: Commons Sandbox) > Support for non-standard exit values indicating successful execution > > > Key: EXEC-17 > URL: https://issues.apache.org/jira/browse/EXEC-17 > Project: Commons Exec > Issue Type: Bug >Reporter: Siegfried Goeschl >Assignee: Siegfried Goeschl > > For printing a PDF document on Windows XP Adobe Acrobat Reader 8.x can be > used - even when successful the application returns "1" as exit value causing > an exception in commons-exec. "1" is considered an execution failure and > there is no way to overwrite the behavior which renders commons-exec useless > here. > PS: Having said that Acrobat Reader 8.x also returns "1" if it can't print > ... :-( -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-16) [exec] EnvironmentVariable: remove empty factory method
[ https://issues.apache.org/jira/browse/EXEC-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-20 to EXEC-16: Component/s: (was: Exec) Key: EXEC-16 (was: SANDBOX-20) Project: Commons Exec (was: Commons Sandbox) > [exec] EnvironmentVariable: remove empty factory method > --- > > Key: EXEC-16 > URL: https://issues.apache.org/jira/browse/EXEC-16 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste >Assignee: Siegfried Goeschl > Attachments: 36797_environment_variable_public_constructor.diff > > > Proposed API change: remove public factory method which seems to add only > complexity. > See comments inside patch header -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-13) [exec] potential threading issue when closing process.getInputStream()
[ https://issues.apache.org/jira/browse/EXEC-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-109 to EXEC-13: - Component/s: (was: Exec) Key: EXEC-13 (was: SANDBOX-109) Project: Commons Exec (was: Commons Sandbox) > [exec] potential threading issue when closing process.getInputStream() > -- > > Key: EXEC-13 > URL: https://issues.apache.org/jira/browse/EXEC-13 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste > > When I started to look into finding common code between ant, plexus, m2 and > cruisecontrol, I found a couple of differences that I think need to be merged > back into commons-exec. > In particular it seems like this plexus-util change [1] contains a threading > fix > which should also be backported to commons-exec. I think we are hitting it now > in CruiseControl in some rare cases: executed process is ant which forks and > spawns a separate process. This makes getInputStream().close() hang, and I > think > your change would fix it. > I haven't yet worked on it, nor wrote a test case. Would appreciate input from > trygvis as he's the one who made the fix for plexus. > [1] > http://svn.codehaus.org/trunk/plexus-utils/src/main/java/org/codehaus/plexus/util/cli/StreamPumper.java?rev=1298&root=plexus&view=rev -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-10) [exec][patch] use final static strings where appropriate
[ https://issues.apache.org/jira/browse/EXEC-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-15 to EXEC-10: Component/s: (was: Exec) Key: EXEC-10 (was: SANDBOX-15) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] use final static strings where appropriate > > > Key: EXEC-10 > URL: https://issues.apache.org/jira/browse/EXEC-10 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Kev Jackson > Attachments: use-final-strings.patch > > > small refactoring of CommandLineImpl to use stringbuffers and final static > strings -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-12) [exec][patch] make ant stores junit test reports in correct directory
[ https://issues.apache.org/jira/browse/EXEC-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-82 to EXEC-12: Component/s: (was: Exec) Key: EXEC-12 (was: SANDBOX-82) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] make ant stores junit test reports in correct directory > - > > Key: EXEC-12 > URL: https://issues.apache.org/jira/browse/EXEC-12 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste >Priority: Trivial > Attachments: 36183.diff > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-11) [exec] setWatchDog method in DefaultExecutor has no affect
[ https://issues.apache.org/jira/browse/EXEC-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-185 to EXEC-11: - Component/s: (was: Exec) Key: EXEC-11 (was: SANDBOX-185) Project: Commons Exec (was: Commons Sandbox) > [exec] setWatchDog method in DefaultExecutor has no affect > -- > > Key: EXEC-11 > URL: https://issues.apache.org/jira/browse/EXEC-11 > Project: Commons Exec > Issue Type: Bug > Environment: All Environments >Reporter: Bindul Bhowmik > Attachments: default-executor.patch > > > The setWatchDog method in org.apache.commons.exec.DefaultExecutor.java does > not have any affect due to a case discrepancy. The method parameter for the > method is watchDog and the value that is assigned is watchdog (the same as > the class field). > I have attached a patch for the same. If required I could add in a test case > for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-7) [exec][patch] ant get-deps target fails to download dependency
[ https://issues.apache.org/jira/browse/EXEC-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-108 to EXEC-7: Component/s: (was: Exec) Key: EXEC-7 (was: SANDBOX-108) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] ant get-deps target fails to download dependency > -- > > Key: EXEC-7 > URL: https://issues.apache.org/jira/browse/EXEC-7 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: Linux > Platform: Other >Reporter: Jerome Lacoste > Attachments: diff.txt > > > get-deps doesn't work if dest directory doesn't exist (ant 1.6.5, Linux) > This one-liner patch fixes it for me. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-4) [exec] Make ProcessDestroyer optional and pluggable
[ https://issues.apache.org/jira/browse/EXEC-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-107 to EXEC-4: Component/s: (was: Exec) Key: EXEC-4 (was: SANDBOX-107) Project: Commons Exec (was: Commons Sandbox) > [exec] Make ProcessDestroyer optional and pluggable > --- > > Key: EXEC-4 > URL: https://issues.apache.org/jira/browse/EXEC-4 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Niklas Gustavsson >Assignee: Siegfried Goeschl > Attachments: 36288_Optional_ProcessDestroyer.patch > > > ProcessDestroyer is currently allways used, and as a shutdown hook. It should > be > made optional and pluggable as the current implementation is not appropriate > in > for example application servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-5) [exec][patch] small refactor of Environment for style
[ https://issues.apache.org/jira/browse/EXEC-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-78 to EXEC-5: --- Component/s: (was: Exec) Key: EXEC-5 (was: SANDBOX-78) Project: Commons Exec (was: Commons Sandbox) > [exec][patch] small refactor of Environment for style > - > > Key: EXEC-5 > URL: https://issues.apache.org/jira/browse/EXEC-5 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Kev Jackson > Attachments: Environment.patch > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-2) [exec] Remove Java 1.1 support
[ https://issues.apache.org/jira/browse/EXEC-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-2 to EXEC-2: -- Component/s: (was: Exec) Key: EXEC-2 (was: SANDBOX-2) Project: Commons Exec (was: Commons Sandbox) > [exec] Remove Java 1.1 support > -- > > Key: EXEC-2 > URL: https://issues.apache.org/jira/browse/EXEC-2 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Niklas Gustavsson > Attachments: commons-exec-20050812.patch, commons-exec-20050812b.patch > > > Attached to this bug report is a patch that removes the Java 1.1 support and > also cleans up much of the remaining code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-1) [exec] Replace Environment with Map
[ https://issues.apache.org/jira/browse/EXEC-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-55 to EXEC-1: --- Component/s: (was: Exec) Key: EXEC-1 (was: SANDBOX-55) Project: Commons Exec (was: Commons Sandbox) > [exec] Replace Environment with Map > --- > > Key: EXEC-1 > URL: https://issues.apache.org/jira/browse/EXEC-1 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Niklas Gustavsson > Attachments: 37951.patch > > > The Environment class (and thereby also EnvironmentVariable) should be > replaced > by using Map. This is in line with the Java 1.5 way of describing the > environment and remove a class which is most ways was just a duplicate of Map. > The functionality for retriveing the current processing environment should be > moved to seperate classes to seperate concerns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Moved: (EXEC-3) [Exec] support getting Environment variables using type checked methods
[ https://issues.apache.org/jira/browse/EXEC-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg moved SANDBOX-112 to EXEC-3: Component/s: (was: Exec) Key: EXEC-3 (was: SANDBOX-112) Project: Commons Exec (was: Commons Sandbox) > [Exec] support getting Environment variables using type checked methods > --- > > Key: EXEC-3 > URL: https://issues.apache.org/jira/browse/EXEC-3 > Project: Commons Exec > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Jerome Lacoste > Attachments: 36708_support_get_env_variable.diff > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-300) Method to query Class to determine if it is a collection
[ https://issues.apache.org/jira/browse/COLLECTIONS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608980#action_12608980 ] Paul Benedict commented on COLLECTIONS-300: --- boolean isCollectionType(Class clazz); Yes. Map, for example, does not implement Collection and yet it is a well-known collection interface. I could not find any other exception in the JDK, however, are there exceptions in Commons Collections that too should be considered? > Method to query Class to determine if it is a collection > > > Key: COLLECTIONS-300 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-300 > Project: Commons Collections > Issue Type: Wish >Reporter: Paul Benedict >Priority: Minor > Fix For: 3.3 > > > Test a Class instance to determine whether it is a known JDK collection type. > Someone else should opine if other Apache Collection interfaces should be > included in the same or different method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAEMON-98) make fails for jsvc on OS X
[ https://issues.apache.org/jira/browse/DAEMON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Malis updated DAEMON-98: - Attachment: osx-leopard.txt Patch to compile on OS X 10.5 Leopard > make fails for jsvc on OS X > --- > > Key: DAEMON-98 > URL: https://issues.apache.org/jira/browse/DAEMON-98 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.0, 1.0.1 > Environment: OS X 10.4.9 Server on i386 > Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007; > root:xnu-792.18.15~1/RELEASE_I386 i386 i386 > java version "1.5.0_07" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164) > Java HotSpot(TM) Server VM (build 1.5.0_07-87, mixed mode) >Reporter: Amos Hayes > Attachments: osx-leopard.txt, osx_patch.txt > > > With both jsvc.tar.gz from tomcat 6.0.10 and the daemon-1.0.1.tar.gz sources > from the commons project, when I try to configure/compile jsvc on OS X, I get > the following: > arthur:/usr/local/apache-tomcat-6.0.10/bin/daemon-1.0.1/src/native/unix root# > ./configure > *** Current host *** > checking build system type... i386-apple-darwin8.9.1 > checking host system type... i386-apple-darwin8.9.1 > checking cached host system type... ok > *** C-Language compilation tools *** > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for ranlib... ranlib > *** Host support *** > checking C flags dependant on host system type... ok > *** Java compilation tools *** > checking for javac... > /System/Library/Frameworks/JavaVM.framework/Home/bin/javac > checking wether the Java compiler > (/System/Library/Frameworks/JavaVM.framework/Home/bin/javac) works... yes > checking for jar... /System/Library/Frameworks/JavaVM.framework/Home/bin/jar > gcc flags added > *** Writing output files *** > configure: creating ./config.status > config.status: creating Makefile > config.status: creating Makedefs > config.status: creating native/Makefile > *** All done *** > Now you can issue "make" > arthur:/usr/local/apache-tomcat-6.0.10/bin/daemon-1.0.1/src/native/unix root# > make > make -C native all > gcc -g -O2 -DOS_DARWIN -DDSO_DYLD -DCPU=\"i386\" > -I/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Headers -Wall > -Wstrict-prototypes -c jsvc-unix.c -o jsvc-unix.o > gcc -g -O2 -DOS_DARWIN -DDSO_DYLD -DCPU=\"i386\" > -I/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Headers -Wall > -Wstrict-prototypes -c arguments.c -o arguments.o > arguments.c: In function 'arguments': > arguments.c:251: warning: unused variable 'temp' > gcc -g -O2 -DOS_DARWIN -DDSO_DYLD -DCPU=\"i386\" > -I/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Headers -Wall > -Wstrict-prototypes -c debug.c -o debug.o > gcc -g -O2 -DOS_DARWIN -DDSO_DYLD -DCPU=\"i386\" > -I/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Headers -Wall > -Wstrict-prototypes -c dso-dlfcn.c -o dso-dlfcn.o > gcc -g -O2 -DOS_DARWIN -DDSO_DYLD -DCPU=\"i386\" > -I/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Headers -Wall > -Wstrict-prototypes -c dso-dyld.c -o dso-dyld.o > dso-dyld.c:54: error: conflicting types for 'dso_init' > dso.h:24: error: previous declaration of 'dso_init' was here > dso-dyld.c: In function 'dso_link': > dso-dyld.c:69: warning: 'NSAddLibrary' is deprecated (declared at > /usr/include/mach-o/dyld.h:224) > dso-dyld.c: At top level: > dso-dyld.c:76: error: conflicting types for 'dso_unlink' > dso.h:26: error: previous declaration of 'dso_unlink' was here > dso-dyld.c: In function 'dso_symbol': > dso-dyld.c:109: warning: operation on 'x' may be undefined > dso-dyld.c:113: warning: 'NSLookupAndBindSymbol' is deprecated (declared at > /usr/include/mach-o/dyld.h:158) > dso-dyld.c: At top level: > dso-dyld.c:127: warning: function declaration isn't a prototype > make[1]: *** [dso-dyld.o] Error 1 > make: *** [native/all] Error 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-300) Method to query Class to determine if it is a collection
[ https://issues.apache.org/jira/browse/COLLECTIONS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608863#action_12608863 ] James Carman commented on COLLECTIONS-300: -- So, you want something that says "does this class implement java.util.Collection or java.util.Map or ..."? > Method to query Class to determine if it is a collection > > > Key: COLLECTIONS-300 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-300 > Project: Commons Collections > Issue Type: Wish >Reporter: Paul Benedict >Priority: Minor > Fix For: 3.3 > > > Test a Class instance to determine whether it is a known JDK collection type. > Someone else should opine if other Apache Collection interfaces should be > included in the same or different method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (VALIDATOR-243) Create standalone domain validator routine
[ https://issues.apache.org/jira/browse/VALIDATOR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened VALIDATOR-243: --- Re-openning since the following announcement probably means this needs to be rethought: http://www.icann.org/en/announcements/announcement-4-26jun08-en.htm > Create standalone domain validator routine > -- > > Key: VALIDATOR-243 > URL: https://issues.apache.org/jira/browse/VALIDATOR-243 > Project: Commons Validator > Issue Type: Task > Components: Routines >Reporter: Ben Speakmon >Assignee: Ben Speakmon > Fix For: 1.4 > > > Since EmailValidator and UrlValidator both need domain name validation, and > since that logic is currently duplicated between them, that logic should be > factored out into a standalone routine for reuse by all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COLLECTIONS-300) Method to query Class to determine if it is a collection
Method to query Class to determine if it is a collection Key: COLLECTIONS-300 URL: https://issues.apache.org/jira/browse/COLLECTIONS-300 Project: Commons Collections Issue Type: Wish Reporter: Paul Benedict Priority: Minor Fix For: 3.3 Test a Class instance to determine whether it is a known JDK collection type. Someone else should opine if other Apache Collection interfaces should be included in the same or different method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-443) DateUtils should test with the extremes
[ https://issues.apache.org/jira/browse/LANG-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated LANG-443: Attachment: LANG-443-rs.patch First set of new tests. If DateUtils.ceil() is available, this file must also test this method > DateUtils should test with the extremes > --- > > Key: LANG-443 > URL: https://issues.apache.org/jira/browse/LANG-443 > Project: Commons Lang > Issue Type: Task >Affects Versions: 2.4 >Reporter: Robert Scholte >Priority: Minor > Fix For: 3.0 > > Attachments: LANG-443-rs.patch > > > Current testdates are a bit to generic. Especially for truncating, ceiling > and rounding you shuold test for the extremes. > So for rounding to hours you should test for 0:29 (rounding down); 0:30 > (rounding up); 1:00 (no rounding required) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-271) Thread safety issues in AbandonedTrace class
[ https://issues.apache.org/jira/browse/DBCP-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608725#action_12608725 ] Sebb commented on DBCP-271: --- Also, as far as I can tell, the parent instance field is used but never initialised. > Thread safety issues in AbandonedTrace class > > > Key: DBCP-271 > URL: https://issues.apache.org/jira/browse/DBCP-271 > Project: Commons Dbcp > Issue Type: Bug >Reporter: Sebb > Fix For: 1.3 > > > DBCP-270 implies that the AbandonedTrace class is called from multiple > threads, however it is not thread-safe: > * SimpleDateFormat is not threadsafe, but it is called without protection. > * various instance fields need to be made final to ensure that they are > published correctly (memory visibility) > * getLastUsed/setLastUsed need to be synchronized - or better, createdBy made > volatile so printStackTrace can access the variable safely > (createdBy is rewritten, not updated, so lost updates are not important) > Also, the Javadoc for printStackTrace() is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-270) Dead lock using the evictor
[ https://issues.apache.org/jira/browse/DBCP-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608721#action_12608721 ] Sebb commented on DBCP-270: --- Note that the patch also adds synchronisation to the getTrace() method. > Dead lock using the evictor > --- > > Key: DBCP-270 > URL: https://issues.apache.org/jira/browse/DBCP-270 > Project: Commons Dbcp > Issue Type: Bug >Affects Versions: 1.2.2 >Reporter: Filip Hanik >Priority: Critical > Fix For: 1.3 > > Attachments: deadlock-abandoned-trace.patch > > > Patch attached, dead lock reported. the abandonedtrace does > synchronized(this) when it really only needs to do synchronized(this.trace) > Dead lock reported when using the evictor > = > "Timer-3": > waiting to lock monitor 0x53b40548 (object 0x2aaabf3210f0, a > org.apache.tomcat.dbcp.dbcp.PoolableConnection), > which is held by "TP-Processor27" > "TP-Processor27": > waiting to lock monitor 0x53b404d0 (object 0x2aaab9fa8b08, a > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool), > which is held by "Timer-3" > Java stack information for the threads listed above: > === > "Timer-3": > at > org.apache.tomcat.dbcp.dbcp.AbandonedTrace.addTrace(AbandonedTrace.java:175) > - waiting to lock <0x2aaabf3210f0> (a > org.apache.tomcat.dbcp.dbcp.PoolableConnection) > at > org.apache.tomcat.dbcp.dbcp.AbandonedTrace.init(AbandonedTrace.java:92) > at > org.apache.tomcat.dbcp.dbcp.AbandonedTrace.(AbandonedTrace.java:82) > at > org.apache.tomcat.dbcp.dbcp.DelegatingStatement.(DelegatingStatement.java:61) > at > org.apache.tomcat.dbcp.dbcp.DelegatingConnection.createStatement(DelegatingConnection.java:224) > at > org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:331) > at > org.apache.tomcat.dbcp.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:312) > at > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.evict(GenericObjectPool.java:1217) > - locked <0x2aaab9fa8b08> (a > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool) > at > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1341) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) > "TP-Processor27": > at > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.addObjectToPool(GenericObjectPool.java:1136) > - waiting to lock <0x2aaab9fa8b08> (a > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool) > at > org.apache.tomcat.dbcp.pool.impl.GenericObjectPool.returnObject(GenericObjectPool.java:1076) > at > org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:87) > - locked <0x2aaabf3210f0> (a > org.apache.tomcat.dbcp.dbcp.PoolableConnection) > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-271) Thread safety issues in AbandonedTrace class
[ https://issues.apache.org/jira/browse/DBCP-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated DBCP-271: -- Description: DBCP-270 implies that the AbandonedTrace class is called from multiple threads, however it is not thread-safe: * SimpleDateFormat is not threadsafe, but it is called without protection. * various instance fields need to be made final to ensure that they are published correctly (memory visibility) * getLastUsed/setLastUsed need to be synchronized - or better, createdBy made volatile so printStackTrace can access the variable safely (createdBy is rewritten, not updated, so lost updates are not important) Also, the Javadoc for printStackTrace() is wrong. was: DBCP-270 implies that the AbandonedTrace class is called from multiple threads, however it is not thread-safe: * SimpleDateFormat is not threadsafe, but it is called without protection. * various instance fields need to be made final to ensure that they are published correctly (memory visibility) * getLastUsed/setLastUsed need to be synchronized Also, the Javadoc for printStackTrace() is wrong. > Thread safety issues in AbandonedTrace class > > > Key: DBCP-271 > URL: https://issues.apache.org/jira/browse/DBCP-271 > Project: Commons Dbcp > Issue Type: Bug >Reporter: Sebb > Fix For: 1.3 > > > DBCP-270 implies that the AbandonedTrace class is called from multiple > threads, however it is not thread-safe: > * SimpleDateFormat is not threadsafe, but it is called without protection. > * various instance fields need to be made final to ensure that they are > published correctly (memory visibility) > * getLastUsed/setLastUsed need to be synchronized - or better, createdBy made > volatile so printStackTrace can access the variable safely > (createdBy is rewritten, not updated, so lost updates are not important) > Also, the Javadoc for printStackTrace() is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DBCP-271) Thread safety issues in AbandonedTrace class
Thread safety issues in AbandonedTrace class Key: DBCP-271 URL: https://issues.apache.org/jira/browse/DBCP-271 Project: Commons Dbcp Issue Type: Bug Reporter: Sebb Fix For: 1.3 DBCP-270 implies that the AbandonedTrace class is called from multiple threads, however it is not thread-safe: * SimpleDateFormat is not threadsafe, but it is called without protection. * various instance fields need to be made final to ensure that they are published correctly (memory visibility) * getLastUsed/setLastUsed need to be synchronized Also, the Javadoc for printStackTrace() is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
