[jira] Commented: (SANDBOX-185) [exec] setWatchDog method in DefaultExecutor has no affect
[ https://issues.apache.org/jira/browse/SANDBOX-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491150 ] Reinhold Füreder commented on SANDBOX-185: -- This was fixed by user sgoeschl on 15.03.2007 12:56 (Fixed typo that broke the usage of the watchdog (watchDog vs. watchdog)). [exec] setWatchDog method in DefaultExecutor has no affect -- Key: SANDBOX-185 URL: https://issues.apache.org/jira/browse/SANDBOX-185 Project: Commons Sandbox Issue Type: Bug Components: Exec 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-192) [exec] Watchdog test cases and argument quotation fix
[ https://issues.apache.org/jira/browse/SANDBOX-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhold Füreder updated SANDBOX-192: - Attachment: ProcessTest.java [exec] Watchdog test cases and argument quotation fix - Key: SANDBOX-192 URL: https://issues.apache.org/jira/browse/SANDBOX-192 Project: Commons Sandbox Issue Type: Bug Components: Exec Affects Versions: Nightly Builds Environment: apache commons exec trunk/head; M$ Windows XP Reporter: Reinhold Füreder Fix For: Nightly Builds Attachments: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-192) [exec] Watchdog test cases and argument quotation fix
[ https://issues.apache.org/jira/browse/SANDBOX-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhold Füreder updated SANDBOX-192: - Attachment: patch_apache-commons-exec.txt [exec] Watchdog test cases and argument quotation fix - Key: SANDBOX-192 URL: https://issues.apache.org/jira/browse/SANDBOX-192 Project: Commons Sandbox Issue Type: Bug Components: Exec Affects Versions: Nightly Builds Environment: apache commons exec trunk/head; M$ Windows XP Reporter: Reinhold Füreder Fix For: Nightly Builds Attachments: patch_apache-commons-exec.txt, 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SANDBOX-192) [exec] Watchdog test cases and argument quotation fix
[exec] Watchdog test cases and argument quotation fix - Key: SANDBOX-192 URL: https://issues.apache.org/jira/browse/SANDBOX-192 Project: Commons Sandbox Issue Type: Bug Components: Exec Affects Versions: Nightly Builds Environment: apache commons exec trunk/head; M$ Windows XP Reporter: Reinhold Füreder Fix For: Nightly Builds Attachments: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SANDBOX-192) [exec] Watchdog test cases and argument quotation fix
[ https://issues.apache.org/jira/browse/SANDBOX-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhold Füreder updated SANDBOX-192: - Attachment: ProcessTest.java [exec] Watchdog test cases and argument quotation fix - Key: SANDBOX-192 URL: https://issues.apache.org/jira/browse/SANDBOX-192 Project: Commons Sandbox Issue Type: Bug Components: Exec Affects Versions: Nightly Builds Environment: apache commons exec trunk/head; M$ Windows XP Reporter: Reinhold Füreder Fix For: Nightly Builds 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DAEMON-80) [daemon] Syslog support for jsvc
[
https://issues.apache.org/jira/browse/DAEMON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491210
]
Marcus Better commented on DAEMON-80:
-
A patch implementing this is available here:
http://svn.debian.org/wsvn/pkg-java?op=comp[EMAIL PROTECTED][EMAIL
PROTECTED]manualorder=1
This adds syslog support, and also tweaks the debug output to prevent adding
timestamp and process id to each line, which is superfluous at least if syslog
is used.
(Also, a section of old Linux-only code which seems unnecessary has been
disabled.)
[daemon] Syslog support for jsvc
Key: DAEMON-80
URL: https://issues.apache.org/jira/browse/DAEMON-80
Project: Commons Daemon
Issue Type: Improvement
Affects Versions: 1.0.1
Environment: Operating System: Linux
Platform: PC
Reporter: Mike Polek
Priority: Minor
Currently, the only way to rotate the logs produced via jsvc
is to restart the tomcat server. I've coded up support for
using syslog through the local0.* channels. It probably needs
a little work, but hopefully it can be incorporated into a
future release.
--- jsvc-unix.c 2005-05-17 06:13:39.0 -0700
+++ /tmp/jsvc-unix.c2005-11-08 14:18:18.0 -0800
@@ -25,6 +25,8 @@
#include stdio.h
#include pwd.h
#include grp.h
+#include syslog.h
+#include errno.h
#ifdef OS_LINUX
#include sys/prctl.h
#include sys/syscall.h
@@ -35,6 +37,7 @@
extern char **environ;
pid_t controlled=0; /* the son process pid */
+pid_t logger=0; /* the logger process pid */
static bool stopping=false;
static bool doreload=false;
static void (*handler_int)(int)=NULL;
@@ -562,10 +565,53 @@
return(freopen(outfile,mode,stream));
}
+static int logger_child (int outpipe, int errpipe, char *procname) {
+ /* Read from file descriptors. Log to syslog. */
+ fd_set rfds;
+ struct timeval tv;
+ int retval, n;
+ int bufsz = 1024;
+ char buf[bufsz];
+
+ if (outpipe errpipe) {
+n = outpipe + 1;
+ } else {
+n = errpipe + 1;
+ }
+
+ openlog(procname, LOG_PID, LOG_LOCAL0);
+
+ while (1) {
+/* Watch two pipes for input */
+FD_ZERO(rfds);
+FD_SET(outpipe, rfds);
+FD_SET(errpipe, rfds);
+/* Wait for a minute */
+tv.tv_sec = 60;
+tv.tv_usec = 0;
+
+retval = select (n, rfds, NULL, NULL, tv);
+if (retval == -1)
+ perror(select());
+else if (retval) {
+ if (FD_ISSET(outpipe, rfds)) {
+read(outpipe, buf, bufsz);
+syslog(LOG_INFO, %s, buf);
+ }
+ if (FD_ISSET(errpipe, rfds)) {
+read(errpipe, buf, bufsz);
+syslog(LOG_ERR, %s, buf);
+ }
+}
+ }
+}
+
/**
* Redirect stdin, stdout, stderr.
*/
-static void set_output(char *outfile, char *errfile) {
+static void set_output(char *outfile, char *errfile, char *procname) {
+int stdoutdes[2] = {0,0}, stderrdes[2] = {0,0},
+forkoutlogger=0, forkerrlogger=0;
freopen(/dev/null, r, stdin);
log_debug(redirecting stdout to %s and stderr to %s,outfile,errfile);
@@ -577,11 +623,28 @@
if(strcmp(outfile, 2) == 0 strcmp(errfile,1) == 0) {
outfile=/dev/null;
}
-if(strcmp(outfile, 2) != 0) {
+
+if (strcmp(outfile, SYSLOG) == 0) {
+ /* Send stdout to syslog through a logger process */
+ if (pipe(stdoutdes)) {
+fprintf(stderr, Unable to create stdout pipe for syslog: %s\n,
+strerror(errno));
+ } else {
+forkoutlogger=1;
+ }
+} else if(strcmp(outfile, 2) != 0) {
loc_freopen(outfile, a, stdout);
}
-if(strcmp(errfile,1) != 0) {
+if (strcmp(errfile, SYSLOG) == 0) {
+ /* Send stderr to syslog through a logger process */
+ if (pipe(stderrdes)) {
+fprintf(stderr, Unable to create stderr pipe for syslog: %s\n,
+strerror(errno));
+ } else {
+forkerrlogger=1;
+ }
+} else if(strcmp(errfile,1) != 0) {
loc_freopen(errfile, a, stderr);
} else {
close(2);
@@ -591,6 +654,33 @@
close(1);
dup(2);
}
+
+if (forkoutlogger || forkerrlogger) {
+ int pid;
+ if ((pid=fork())!=-1) {
+if (pid) {
+ if (stdoutdes[0] != 0) {
+close(stdoutdes[0]);
+if (dup2(stdoutdes[1],1) == -1) {
+ fprintf(stderr,Unable to redirect stdout to pipe for syslog:
%s\n,
+strerror(errno));
+}
+ }
+ if (stderrdes[0] != 0) {
+close(stderrdes[0]);
+if (dup2(stderrdes[1],2) == -1) {
+ fprintf(stderr,Unable to redirect stderr to pipe for syslog:
%s\n,
+strerror(errno));
+}
+ }
+} else {
+ exit
[nightly build] configuration failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070424/configuration.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DAEMON-24) [daemon] jsvc assumes posix capabilities loaded
[ https://issues.apache.org/jira/browse/DAEMON-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491224 ] Marcus Better commented on DAEMON-24: - That patch is for DAEMON-93. I propose something like this instead: http://svn.debian.org/wsvn/pkg-java?op=comp[EMAIL PROTECTED][EMAIL PROTECTED]manualorder=1 [daemon] jsvc assumes posix capabilities loaded --- Key: DAEMON-24 URL: https://issues.apache.org/jira/browse/DAEMON-24 Project: Commons Daemon Issue Type: Bug Environment: Operating System: Linux Platform: PC Reporter: Michael Thome Attachments: 1.0.1-capabilities.patch later versions of linux (e.g. 2.6.x) may have capability management configured as a module rather than compiled in. A LKML discussion is ongoing as to if this is a good idea or not, but the upshot is that jsvc will fail on capset if the kernel doesn't have the module loaded. I'd suggest a note in the release notes and/or linux faq section discussing the issue. I'd be happy to propose a doc patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (DAEMON-80) [daemon] Syslog support for jsvc
[
https://issues.apache.org/jira/browse/DAEMON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell reopened DAEMON-80:
-
Reporter requested this be reopened.
[daemon] Syslog support for jsvc
Key: DAEMON-80
URL: https://issues.apache.org/jira/browse/DAEMON-80
Project: Commons Daemon
Issue Type: Improvement
Affects Versions: 1.0.1
Environment: Operating System: Linux
Platform: PC
Reporter: Mike Polek
Priority: Minor
Currently, the only way to rotate the logs produced via jsvc
is to restart the tomcat server. I've coded up support for
using syslog through the local0.* channels. It probably needs
a little work, but hopefully it can be incorporated into a
future release.
--- jsvc-unix.c 2005-05-17 06:13:39.0 -0700
+++ /tmp/jsvc-unix.c2005-11-08 14:18:18.0 -0800
@@ -25,6 +25,8 @@
#include stdio.h
#include pwd.h
#include grp.h
+#include syslog.h
+#include errno.h
#ifdef OS_LINUX
#include sys/prctl.h
#include sys/syscall.h
@@ -35,6 +37,7 @@
extern char **environ;
pid_t controlled=0; /* the son process pid */
+pid_t logger=0; /* the logger process pid */
static bool stopping=false;
static bool doreload=false;
static void (*handler_int)(int)=NULL;
@@ -562,10 +565,53 @@
return(freopen(outfile,mode,stream));
}
+static int logger_child (int outpipe, int errpipe, char *procname) {
+ /* Read from file descriptors. Log to syslog. */
+ fd_set rfds;
+ struct timeval tv;
+ int retval, n;
+ int bufsz = 1024;
+ char buf[bufsz];
+
+ if (outpipe errpipe) {
+n = outpipe + 1;
+ } else {
+n = errpipe + 1;
+ }
+
+ openlog(procname, LOG_PID, LOG_LOCAL0);
+
+ while (1) {
+/* Watch two pipes for input */
+FD_ZERO(rfds);
+FD_SET(outpipe, rfds);
+FD_SET(errpipe, rfds);
+/* Wait for a minute */
+tv.tv_sec = 60;
+tv.tv_usec = 0;
+
+retval = select (n, rfds, NULL, NULL, tv);
+if (retval == -1)
+ perror(select());
+else if (retval) {
+ if (FD_ISSET(outpipe, rfds)) {
+read(outpipe, buf, bufsz);
+syslog(LOG_INFO, %s, buf);
+ }
+ if (FD_ISSET(errpipe, rfds)) {
+read(errpipe, buf, bufsz);
+syslog(LOG_ERR, %s, buf);
+ }
+}
+ }
+}
+
/**
* Redirect stdin, stdout, stderr.
*/
-static void set_output(char *outfile, char *errfile) {
+static void set_output(char *outfile, char *errfile, char *procname) {
+int stdoutdes[2] = {0,0}, stderrdes[2] = {0,0},
+forkoutlogger=0, forkerrlogger=0;
freopen(/dev/null, r, stdin);
log_debug(redirecting stdout to %s and stderr to %s,outfile,errfile);
@@ -577,11 +623,28 @@
if(strcmp(outfile, 2) == 0 strcmp(errfile,1) == 0) {
outfile=/dev/null;
}
-if(strcmp(outfile, 2) != 0) {
+
+if (strcmp(outfile, SYSLOG) == 0) {
+ /* Send stdout to syslog through a logger process */
+ if (pipe(stdoutdes)) {
+fprintf(stderr, Unable to create stdout pipe for syslog: %s\n,
+strerror(errno));
+ } else {
+forkoutlogger=1;
+ }
+} else if(strcmp(outfile, 2) != 0) {
loc_freopen(outfile, a, stdout);
}
-if(strcmp(errfile,1) != 0) {
+if (strcmp(errfile, SYSLOG) == 0) {
+ /* Send stderr to syslog through a logger process */
+ if (pipe(stderrdes)) {
+fprintf(stderr, Unable to create stderr pipe for syslog: %s\n,
+strerror(errno));
+ } else {
+forkerrlogger=1;
+ }
+} else if(strcmp(errfile,1) != 0) {
loc_freopen(errfile, a, stderr);
} else {
close(2);
@@ -591,6 +654,33 @@
close(1);
dup(2);
}
+
+if (forkoutlogger || forkerrlogger) {
+ int pid;
+ if ((pid=fork())!=-1) {
+if (pid) {
+ if (stdoutdes[0] != 0) {
+close(stdoutdes[0]);
+if (dup2(stdoutdes[1],1) == -1) {
+ fprintf(stderr,Unable to redirect stdout to pipe for syslog:
%s\n,
+strerror(errno));
+}
+ }
+ if (stderrdes[0] != 0) {
+close(stderrdes[0]);
+if (dup2(stderrdes[1],2) == -1) {
+ fprintf(stderr,Unable to redirect stderr to pipe for syslog:
%s\n,
+strerror(errno));
+}
+ }
+} else {
+ exit (logger_child(stdoutdes[1],stderrdes[1],procname));
+}
+ } else {
+fprintf(stderr, Unable to create logger child process: %s\n,
+ strerror(errno));
+ }
+}
}
int main(int argc, char *argv[]) {
@@ -678,7 +768,7 @@
#endif
}
-set_output(args-outfile, args-errfile);
+set_output(args-outfile, args-errfile, args-procname);
[jira] Created: (CHAIN-35) PathInfoMapper command can not obtain the current catalog instance
PathInfoMapper command can not obtain the current catalog instance
--
Key: CHAIN-35
URL: https://issues.apache.org/jira/browse/CHAIN-35
Project: Commons Chain
Issue Type: Bug
Affects Versions: 1.1
Environment: Simple web application using the
org.apache.commons.chain.web.servlet.ChainProcessor servlet with the
PathInfoMapper. No configuration parameters differ from defaults.
Reporter: Alonso Dominguez
Priority: Minor
I found a NPE in your implementation of the PathInfoMapper command.
The exception is thrown when the PathInfoMapper tries to invoke the command he
received from the request's pathInfo. This happens at following code:
// Map to the Command specified by the extra path info
Catalog catalog = (Catalog) context.get(getCatalogKey());
Command command = catalog.getCommand(pathInfo);
As you can see, the command tries to obtain the catalog using the get method
from the context. The 'catalogKey' is defined to be the same as the one used by
the ChainProcessor servlet:
private String catalogKey = ChainProcessor.CATALOG_DEFAULT;
The problem is that the catalog instance is set in the request scope, not
inside the context instance. This is the piece of code from ChainProcessor that
does that:
if (attribute == null) {
request.setAttribute(CATALOG_DEFAULT, theCatalog);
}
So, the PathInfoMapper always obtains a null reference from the command's
context when it tries to obtain a catalog instance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JELLY-276) Parameter name is not taken into account on log tags
Parameter name is not taken into account on log tags
Key: JELLY-276
URL: https://issues.apache.org/jira/browse/JELLY-276
Project: Commons Jelly
Issue Type: Bug
Affects Versions: 1.1
Reporter: Felipe Leme
I wrote the following Jelly script:
?xml version=1.0?
j:jelly xmlns:log=jelly:log xmlns:j=jelly:core
log:info name=test.jellyretVal: ${retVal}/log:info
/j:jelly
And the output was:
Apr 24, 2007 1:43:02 PM org.apache.commons.jelly.tags.log.InfoTag doTag
INFO: retVal: SUCCESS
My understanding is that it should print the log name instead of the class name:
Apr 24, 2007 1:43:02 PM test.jelly doTag
INFO: retVal: SUCCESS
But I might be wrong (it might be a commons-logging setup issue).
-- Felipe
PS: it's necessary to add a new component for tag-log ,and also update the
releases (I didn't have access to do so)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (SANDBOX-185) [exec] setWatchDog method in DefaultExecutor has no affect
[ https://issues.apache.org/jira/browse/SANDBOX-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rahul Akolkar resolved SANDBOX-185. --- Resolution: Fixed Fixed by sgoeschl in r518598 [1]. [1] http://svn.apache.org/viewvc?view=revrevision=518598 [exec] setWatchDog method in DefaultExecutor has no affect -- Key: SANDBOX-185 URL: https://issues.apache.org/jira/browse/SANDBOX-185 Project: Commons Sandbox Issue Type: Bug Components: Exec 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 158 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jsl-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 158 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jsl-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on ant exists, no need to add for property maven.jar.ant-optional. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - [junit] at org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64) [junit] at org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66) [junit] at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187) [junit] at org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161) [junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59) [junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80) [junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171) [junit]
[jira] Commented: (CONFIGURATION-253) FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent
[ https://issues.apache.org/jira/browse/CONFIGURATION-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491438 ] Oliver Heger commented on CONFIGURATION-253: After having a deeper look into this issue I am no longer sure that this is a bug. You loaded the configuration with the load(String) method, and the Javadocs for this method state This does not change the source of the configuration (i.e. the internally maintained file name). Use one of the setter methods for this purpose. However I tend to agree that the current behavior is confusing. Why can you obtain a URL and a path name from a configuration loaded this way, but no File? I have written a test case and implemented a (simple) fix, which would cause getFile() to return a valid file name in this case. What do others think? Should we change the current behavior? FileConfiguration getFile(), getFileName(), getBasePath() are not always consistent --- Key: CONFIGURATION-253 URL: https://issues.apache.org/jira/browse/CONFIGURATION-253 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.3 Reporter: Thomas Wabner Fix For: 1.5 Taken from the maillinglist: I have a properties configuration which is loaded without a problem. Later in my application I will access the file which is aligned to this configuration. final IFileConfiguration _productConf = _conf.getProductConfigurations().get(_productId); log.debug(product conf file + _productConf.getFile()); log.debug(product conf filename + _productConf.getFileName()); log.debug(product conf base path + _productConf.getBasePath()); The methods _productConf.getFile() and _productConf.getFileName() returning null but the getBasePath() returns a path which is correct (like file:/C:/Projects/workspace/myProject/project.properties). Seems for me like a bug because the PropertiesConfiguration is loaded correct and works. By side: I have also set a file reloading strategy for this configuration. Any ideas what's happen in this case or where I can find the problem? It would be nicer to get the File() instead the BasePath which has to be converted into a URL before I can access the whole properties file. Thanks in advance, - Thomas Wabner Thomas, you are right, the conversions between a base path, a file name, and a File are not always consistent. How did you load the configuration (this determines, which internal fields are set)? I would recommend to work with URLs, i.e. the method getURL(). A file-based configuration's URL is always defined. If you like, you can open a Jira ticket for this problem. Thanks. Oliver The file is loaded in this way: _productConf = new ProductConfiguration(); _productConf.load(FileTools.getPathForList(_propductPathList).getPath()); means the load method gets an String and not an File. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 158 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-24042007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 158 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-24042007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24042007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-24042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-24042007.jar - [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)
