Re: [Jelly] [GUMP] vanilla Ant build.xml has gone
dIon, the build file contains some hard-coded paths, that I can't override via Ant properties from the outside. Could you please have another look? Buildfile: build.xml init: [mkdir] Created dir: /javastuff/gump/jakarta-commons/jelly/target/lib get-deps: compile: [mkdir] Created dir: /javastuff/gump/jakarta-commons/jelly/target/classes BUILD FAILED /javastuff/gump/jakarta-commons/jelly/build.xml:34: srcdir /javastuff/gump/jakarta-commons/jelly/C:/source/jakarta/jakarta-commons/jelly/src/java does not exist! Total time: 1 second Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[attributes][GUMP] compilation error
Not-automated as Sam is having some trouble with his system setup ...
[javac]
/javastuff/gump/jakarta-commons-sandbox/attributes/api/src/java/org/apache/commons/attributes/EmptyCachedRepository.java:68:
org.apache.commons.attributes.EmptyCachedRepository should be declared abstract; it
does not define getParameterAttributes(java.lang.reflect.Constructor,int) in
org.apache.commons.attributes.EmptyCachedRepository
[javac] class EmptyCachedRepository implements CachedRepository {
[javac] ^
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procgui.c
mturk 2003/10/02 00:21:29
Modified:daemon/src/native/nt/procrun procgui.c
Log:
Improve listview parsing and display.
Make sure that the console window popups to foreground
on try dblclick
Revision ChangesPath
1.7 +70 -34jakarta-commons/daemon/src/native/nt/procrun/procgui.c
Index: procgui.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procgui.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- procgui.c 1 Oct 2003 18:06:20 - 1.6
+++ procgui.c 2 Oct 2003 07:21:29 - 1.7
@@ -100,7 +100,6 @@
#define CONWRAP_ENOARGS1
#define CONWRAP_EARG 2
#define CONWRAP_EFATAL 3
-#define TIMEOUT_TIME 2/* startup timeout (ms) */
#ifndef PSH_NOCONTEXTHELP
#define PSH_NOCONTEXTHELP 0x0200
@@ -116,34 +115,43 @@
intac_use_dlg = 0;
intac_use_show = 0;
intac_use_props = 0;
-intac_use_lview = 0;
-
+intac_use_lview = 1;
+/* default splash timeout 5 seconds */
+intac_splash_timeout = 5000;
+intac_lview_current = 0;
HINSTANCE ac_instance;
-static procrun_t *ac_env = NULL;
-static HICON ac_main_icon;
-static HICON ac_try_icon;
-static HICON ac_try_stop;
-static UINTac_taskbar_created;
HWND ac_main_hwnd;
HWND ac_list_hwnd;
-static HWNDac_console_hwnd = NULL;
-static char*ac_stdout_lines[MAX_LISTCOUNT + 1];
char *ac_cmdline;
char *ac_cmdname;
char *ac_splash_msg = NULL;
RECT ac_winpos = {-1, 0, 640, 480};
+
+static procrun_t *ac_env = NULL;
+static HICON ac_main_icon;
+static HICON ac_try_icon;
+static HICON ac_try_stop;
+static UINTac_taskbar_created;
+static HWNDac_console_hwnd = NULL;
+static char*ac_stdout_lines[MAX_LISTCOUNT + 1];
static HWNDac_splash_hwnd = NULL;
static HWNDac_splist_hwnd;
+static int ac_lv_iicon = 0;
-intac_lview_current = 0;
-prcrun_lview_t lv_columns[] = {
-{ Status, 60 },
-{ Message, 552 },
+static prcrun_lview_t lv_columns[] = {
+{ Type, 80 },
+{ Message, 532 },
{ NULL, 0 },
};
+static char *lv_infos[] = {
+Info,
+Warning,
+Error
+};
+
prcrun_lview_t *ac_columns = lv_columns[0];
INT_PTR ac_show_properties(HWND owner);
@@ -156,7 +164,7 @@
HICON hicon;
prcrun_lview_t *col = ac_columns;
-imlist = ImageList_Create(16, 16, ILC_COLORDDB | ILC_MASK, 3, 0);
+imlist = ImageList_Create(16, 16, ILC_COLORDDB | ILC_MASK, 4, 0);
hicon = LoadImage(ac_instance, MAKEINTRESOURCE(IDI_ICOI),
IMAGE_ICON, 16, 16, LR_DEFAULTCOLOR);
ImageList_AddIcon(imlist, hicon);
@@ -166,6 +174,7 @@
hicon = LoadImage(ac_instance, MAKEINTRESOURCE(IDI_ICOS),
IMAGE_ICON, 16, 16, LR_DEFAULTCOLOR);
ImageList_AddIcon(imlist, hicon);
+ImageList_AddIcon(imlist, hicon);
ac_list_hwnd = CreateWindowEx(0L, WC_LISTVIEW, ,
WS_VISIBLE | WS_CHILD |
@@ -194,35 +203,57 @@
}
-static int ac_lv_iicon = 0;
+/*
+ * Find the first occurrence of find in s.
+ */
+static char *
+stristr(register const char *s, register const char *find)
+{
+register char c, sc;
+register size_t len;
+if ((c = *find++) != 0) {
+len = strlen(find);
+do {
+do {
+if ((sc = *s++) == 0)
+return (NULL);
+} while (sc != toupper(c));
+} while (strnicmp(s, find, len) != 0);
+s--;
+}
+return ((char *)s);
+}
-void parse_list_string(const char *str)
+void parse_list_string(const char *str, int from)
{
int row = 0x7FFF;
LV_ITEM lvi;
-if (str) {
-if (STRN_COMPARE(str, INFO:)) {
+if (!from) {
+/* some general messages
+ * chnage to suit the particular app.
+ */
+if (stristr(str, INFO))
ac_lv_iicon = 0;
-}
-else if (STRN_COMPARE(str, WARNING:)) {
+else if (stristr(str, WARNING))
ac_lv_iicon = 1;
-}
-else if (STRN_COMPARE(str, ERROR:)) {
-ac_lv_iicon = 2;
-}
-else if (STRN_COMPARE(str, SEVERE:)) {
+else if
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.c procrun.h procrun.rc
mturk 2003/10/02 00:22:16
Modified:daemon/src/native/nt/procrun procrun.c procrun.h procrun.rc
Log:
Add the Registry key for selecting the console display type.
Revision ChangesPath
1.7 +11 -3 jakarta-commons/daemon/src/native/nt/procrun/procrun.c
Index: procrun.c
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- procrun.c 1 Oct 2003 18:06:20 - 1.6
+++ procrun.c 2 Oct 2003 07:22:16 - 1.7
@@ -111,7 +111,7 @@
static int g_is_windows_nt = 0;
#ifdef PROCRUN_WINAPP
-
+
#endif
@@ -998,7 +998,15 @@
sscanf(kval, %d %d %d %d, ac_winpos.left, ac_winpos.right,
ac_winpos.top, ac_winpos.bottom);
}
+
+klen = MAX_PATH;
+if ((err = RegQueryValueEx(key, PROCRUN_PARAMS_USELVIEW, NULL, NULL,
+ (unsigned char *)kval,
+ klen)) == ERROR_SUCCESS) {
+ac_use_lview = atoi(kval);
+}
#endif
+klen = MAX_PATH;
if ((err = RegQueryValueEx(key, PROCRUN_PARAMS_ENVIRONMENT, NULL, NULL,
NULL,
klen)) == ERROR_SUCCESS) {
@@ -1395,7 +1403,7 @@
if (ch == '\n' || n = MAX_PATH) {
buff[n] = '\0';
DBPRINTF1(RD %s, buff);
-ac_add_list_string(buff, n);
+ac_add_list_string(buff, n, 0);
n = 0;
}
else if (ch == '\t' n (MAX_PATH - 4)) {
@@ -1440,7 +1448,7 @@
if (ch == '\n' || n = MAX_PATH) {
buff[n] = '\0';
DBPRINTF1(RD %s, buff);
-ac_add_list_string(buff, n);
+ac_add_list_string(buff, n, 1);
n = 0;
}
else if (ch == '\t' n (MAX_PATH - 4)) {
1.6 +4 -3 jakarta-commons/daemon/src/native/nt/procrun/procrun.h
Index: procrun.h
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.h,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- procrun.h 1 Oct 2003 18:06:20 - 1.5
+++ procrun.h 2 Oct 2003 07:22:16 - 1.6
@@ -213,6 +213,7 @@
#define PROCRUN_PARAMS_WINPOS WindowPosition
#define PROCRUN_PARAMS_WINCLR WindowColor
#define PROCRUN_PARAMS_WINBACK WindowBackground
+#define PROCRUN_PARAMS_USELVIEW WindowListView
#define PROCRUN_DEFAULT_CLASS Main
@@ -359,13 +360,14 @@
extern DWORD WINAPI gui_thread(LPVOID param);
-extern void ac_add_list_string(const char *str, int len);
+extern void ac_add_list_string(const char *str, int len, int from);
extern int ac_use_try;
extern int ac_use_dlg;
extern int ac_use_show;
extern int ac_use_props;
extern int ac_use_lview;
extern int ac_lview_current;
+extern int ac_splash_timeout;
extern RECTac_winpos;
extern HINSTANCE ac_instance;
@@ -378,13 +380,12 @@
voidac_show_try_icon(HWND hwnd, DWORD message, const char *tip, int stop);
voidac_center_window(HWND hwnd);
-typedef void (*lv_parse_cb_t)(const char *data);
+typedef void (*lv_parse_cb_t)(const char *data, int from);
extern lv_parse_cb_tlv_parser;
#if defined(PROCRUN_EXTENDED)
-void acx_parse_list_string(const char *str);
void acx_init_extended();
1.5 +2 -2 jakarta-commons/daemon/src/native/nt/procrun/procrun.rc
Index: procrun.rc
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.rc,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- procrun.rc1 Oct 2003 18:06:20 - 1.4
+++ procrun.rc2 Oct 2003 07:22:16 - 1.5
@@ -139,7 +139,7 @@
CONTROL ,IDC_RICHEDIT21,RichEdit20A,ES_MULTILINE |
ES_READONLY | WS_BORDER | WS_VSCROLL,0,31,335,115
CONTROL 117,IDC_STATIC,Static,SS_BITMAP,0,0,337,30
-LTEXT Apache Process Runner ver. 1.0.0,IDC_STATIC,2,150,270,12
+LTEXT Apache Process Runner ver. 1.1.0,IDC_STATIC,2,150,270,12
END
#else
IDD_ABOUTBOX DIALOGEX 0, 0, 337, 167
@@ -150,7 +150,7 @@
DEFPUSHBUTTON OK,IDOK,285,150,50,14
CONTROL ,IDC_RICHEDIT21,RichEdit20A,ES_MULTILINE |
ES_READONLY | WS_BORDER | WS_VSCROLL,0,0,335,145
-
[HiveMind] Testing Interceptors ...
A general question: What do you all consider best practices for testing interceptors? Currently involves a lot of manual testing, but would like to move to junit testing for it. Johan -- you too? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Jelly] [GUMP] vanilla Ant build.xml has gone
Ok, will do later tonight (4 hours or so). -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Stefan Bodewig [EMAIL PROTECTED] wrote on 02/10/2003 04:41:24 PM: dIon, the build file contains some hard-coded paths, that I can't override via Ant properties from the outside. Could you please have another look? Buildfile: build.xml init: [mkdir] Created dir: /javastuff/gump/jakarta-commons/jelly/target/lib get-deps: compile: [mkdir] Created dir: /javastuff/gump/jakarta-commons/jelly/target/classes BUILD FAILED /javastuff/gump/jakarta-commons/jelly/build.xml:34: srcdir /javastuff/gump/jakarta-commons/jelly/C:/source/jakarta/jakarta- commons/jelly/src/java does not exist! Total time: 1 second Thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23557] New: - WordUtils.capitalizeFully(String str) should take a delimiter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23557. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23557 WordUtils.capitalizeFully(String str) should take a delimiter Summary: WordUtils.capitalizeFully(String str) should take a delimiter Product: Commons Version: 2.0 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We would like to use capitalizeFully(String str) from org.apache.commons.lang.WordUtils to capitalise names. Unfortunately we cannot capitalise the second part of a hyphenated name (cholmondley-warner becomes Cholmondley-warner not Cholmondley-Warner) as capitalizeFully only separates words with spaces. If capitalizeFully took a delimiter as an argument then we could pass in a hyphen and successfully capitalise our names. Thanks, Phil. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23558] New: - Problem with BeanUtils.setProperty when the name of property of Bean have on second caracter a uppercase
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23558 Problem with BeanUtils.setProperty when the name of property of Bean have on second caracter a uppercase Summary: Problem with BeanUtils.setProperty when the name of property of Bean have on second caracter a uppercase Product: Commons Version: Nightly Builds Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a bean with one property hEmail. I fact the Bean have these methods setHEmail(String hEmail) and getHEmail(). There is a problem with these instruction : BeanUtils.setProperty(bean, hEmail, new String(dupond)); or BeanUtils.copyProperty(bean, hEmail, new String(dupond)); The property hEmail does not contain dupond after this instruction. If I check my property name with the command : String name = new PropertyUtilsBean().getPropertyDescriptors(mainBean)[0].getName(); The result of name is HEmail (not hEmail) Info : if I change the property of bean hEmail by hemail there is also no problem. I fact I think there is a problem with the command PropertyUtilsBean().getPropertyDescriptors(mainBean), that don't return correctly the property of the bean when the name of property have on second character a uppercase. Version JVM : 1.4.2-b18 or 1.4.1_02-b06 Version BeanUtils (Nightly Builds) v1.6.1 2003-10-01 Best regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23560] New: - FTPClient.storeFile(...) should return status information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23560 FTPClient.storeFile(...) should return status information Summary: FTPClient.storeFile(...) should return status information Product: Commons Version: 1.0 Final Platform: All URL: http://jakarta.apache.org/commons/net/apidocs/org/apache /commons/net/ftp/FTPClient.html#storeFile(java.lang.Stri ng, java.io.InputStream) OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Net AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The storeFile method is defined as follows in the FTPClient class: boolean storeFile(String, InputStream) The return value is a simple yes/no indicating if the thing succeeded. This interface is too simple for real-world applications. If the upload fails, then the FTP server normally returns a status code and a description of the error. For example: 550 xins-0.126.tar.gz: Overwrite permission denied Suggestion: 1) Deprecated the current storeFile(String,InputStream) that returns a boolean 2) Add a method storeFile(InputStream local, String remote) that returns the status code and description returned by the server (exact return type to be determined) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
I have a project I'd like to contribute to Jakarta Commons.
A while back I wrote a generic comparator for Java objects and called it GComp. Weve been using it internally at the company where I work, but I was wondering if it might not be of value to the commons project. Typically Java programmers create a custom Comparator implementation for every comparison scenario they encounter. GComp on the other hand can compare objects according to complex criteria based on a simple expression that explains how the objects should be compared. Great time saver and prevents problem of many small comparator classes bloating the code base. Usage scenario: Lets say we have a class called Customer with methods to access the first name and last name. Lets also say we have a class called Order that holds a reference to an instance of Customer. To compare orders according to the customer surname (ascending) we could create the following comparator: new GComp(getLastName); To compare a collection of orders according to the customer last name (ascending) and then first name (descending) for those customers with the same last name we could create the following comparator: new GComp([EMAIL PROTECTED]|[EMAIL PROTECTED] ); To order null values last and ignore case we could create: new GComp([EMAIL PROTECTED],nulls=last|getCustomer. [EMAIL PROTECTED],nulls=last); The above code only orders on string objects, but all objects implementing the comparable interface is supported as is primitive types. Currently GComp uses commons-logging to output debugging information if commons logging is found on the classpath. I'm happy to donate the code for further study. Let me know. Keep well, Wickus Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTPClient listFiles command failing
Maybe related to being behind a firewall? Can you use regular ftp
tools and are you using a passive connection?
On Wed, 01 Oct 2003 12:26:34 -0600, Kris Nuttycombe [EMAIL PROTECTED] said:
Hello, all - any help is appreciated. I'm having difficulty using
the commons.net.ftp.FTPClient when attempting to get a file
list. The client connects correctly and I can issue CWD commands
without difficulty, but as soon as I issue listFiles() or nlst() it
fails with the reply string Unable to build data connection:
Connection timed out
Does anyone have an idea of where I should start looking to fix
this?
Thanks,
Kris Nuttycombe
Here is some debugging output:
0 [main] DEBUG gov.noaa.nosa.argo.ArgoReader - 220
zeus.aoml.noaa.gov FTP server ready 116 [main] DEBUG
gov.noaa.nosa.argo.ArgoReader - 230 Anonymous access granted,
restrictions apply. 167 [main] DEBUG gov.noaa.nosa.argo.ArgoReader
- 250 CWD command successful. 170 [main] DEBUG
gov.noaa.nosa.argo.ArgoReader - FTP connection successfully
established to ftp.aoml.noaa.gov/phod/pub/ARGO_FTP/argo/nc/aoml 170
[main] DEBUG gov.noaa.nosa.argo.ArgoReader - FTP Data connection
mode: 0 java.io.IOException: FTP client could not obtain file list :
425 Unable to build data connection: Connection timed out
Here is the code that generated it:
client.connect(host);
log.debug(client.getReplyString());
if(!FTPReply.isPositiveCompletion(client.getReplyCode())) { throw
new IOException(FTP server at host + host + refused
connection.);
}
client.login(user, password);
log.debug(client.getReplyString());
if(!FTPReply.isPositiveCompletion(client.getReplyCode())) { throw
new IOException(FTP login failed for user anonymous: +
client.getReplyString());
}
client.changeWorkingDirectory(path);
log.debug(client.getReplyString());
if(!FTPReply.isPositiveCompletion(client.getReplyCode())) { throw
new IOException(FTP client could not change to remote directory +
path + : + client.getReplyString());
}
log.debug(FTP connection successfully
established to + host + path); log.debug(FTP Data connection
mode: + client.getDataConnectionMode()); FTPFile[] files =
client.listFiles(path);
if(!FTPReply.isPositiveCompletion(client.getReplyCode())) { throw
new IOException(FTP client could not obtain file list : +
client.getReplyString());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
=
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HiveMind] extend BuildFactory to use static fields/methods
This looks pretty darn good. Just a few thoughts/observations: 1) Could we just merge ConstructorFactory into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties). 2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the framework). Method public static Object invokeConstructor(Class klass, Object[] args) seems to do the trick, and I will be changing other code to start using this. 3) The exception thrown on line 133 should be more descriptive, come from HiveMind.properties, and include the correct Location. 4) Need an update to framework/xdoc/BuilderFactory.xml to describe new features (once merged into BuilderFactory). 5) For the constructor arguments, would this look better: construct ... stringfoo/string serviceservice-id/service configurationconfig-id/configuration ?? Maybe, maybe not. 6) What if the constructor expects the Log, Messages or service id to be a parameter? Need log/ messages/ service-id/ elements. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 6:56 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard, I found it was easiest to develop the service as part of the HiveMind project itself. That way I have all the classpaths set up and could reuse the test harness, etc. Therefore I now attach the additions and changes as a patch. If this isn't convenient for you I will try to separate the code and send it in a different form. --knut Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do like the idea of mixing the two models; write some tests and we'll see about integrating it with hivemind.BuilderFactory. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods I have written a service implementing this strategy, with a minor difference: I didn't add a nested properties as you proposed, instead the set-... elements are immedeate child elements. This way the service can be used everywhere hivemind.BuilderFactory is used. E.g. construct class=... set-service service-id=.../ set-boolean .../ int value=42/ set-int .../ string value=foo/ /construct The constructor parameter elements and property elements can be mixed freely, as long as the constructor parameter elements are given in the same order as in the actual constructor. In this case: int, String. The service supports the following constructor parameter elements: string, int, long, boolean, service, configuration, and resource. If anyone's interested I can supply the source. I just thought I'd write some more unit tests first... --knut Christian Essl [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That would be realy helpful. Maybe we could add a properties tag which would include the current BuilderFactory tags and set the properties after the service is constructed. contruct class=... service service-id=.../ configuration configuration-id=.../ int value=.../ (etc.) properties set-boolean .../ (etc.) /properties /construct On Wed, 1 Oct 2003 10:22:52 -0400, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: Maybe ConstructorFactory? Something like: contruct class=... service service-id=.../ configuration configuration-id=.../ int value=.../ (etc.) /construct The elements inside the construct element are the parameters to the constructor. I'll be setting up a HiveMind:Contrib subproject shortly. We can start putting stuff in there and then migrate it up to library or framework if it proves to be popular and essential. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 10:18 AM
Re: [HiveMind] extend BuildFactory to use static fields/methods
Howard M. Lewis Ship wrote: This looks pretty darn good. Just a few thoughts/observations: 1) Could we just merge ConstructorFactory into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties). I really like the idea as long as we have both the options. 2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the framework). Method public static Object invokeConstructor(Class klass, Object[] args) seems to do the trick, and I will be changing other code to start using this. 3) The exception thrown on line 133 should be more descriptive, come from HiveMind.properties, and include the correct Location. 4) Need an update to framework/xdoc/BuilderFactory.xml to describe new features (once merged into BuilderFactory). 5) For the constructor arguments, would this look better: construct ... stringfoo/string serviceservice-id/service configurationconfig-id/configuration ?? Maybe, maybe not. Don't we need the primitives? I think we do. 6) What if the constructor expects the Log, Messages or service id to be a parameter? Need log/ messages/ service-id/ elements. How is service and service-id different? I think we will need a way to pass in everything that we can, so we may need log and messages too. Just my 2 cents. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 6:56 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard, I found it was easiest to develop the service as part of the HiveMind project itself. That way I have all the classpaths set up and could reuse the test harness, etc. Therefore I now attach the additions and changes as a patch. If this isn't convenient for you I will try to separate the code and send it in a different form. --knut Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do like the idea of mixing the two models; write some tests and we'll see about integrating it with hivemind.BuilderFactory. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods I have written a service implementing this strategy, with a minor difference: I didn't add a nested properties as you proposed, instead the set-... elements are immedeate child elements. This way the service can be used everywhere hivemind.BuilderFactory is used. E.g. construct class=... set-service service-id=.../ set-boolean .../ int value=42/ set-int .../ string value=foo/ /construct The constructor parameter elements and property elements can be mixed freely, as long as the constructor parameter elements are given in the same order as in the actual constructor. In this case: int, String. The service supports the following constructor parameter elements: string, int, long, boolean, service, configuration, and resource. If anyone's interested I can supply the source. I just thought I'd write some more unit tests first... --knut Christian Essl [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That would be realy helpful. Maybe we could add a properties tag which would include the current BuilderFactory tags and set the properties after the service is constructed. contruct class=... service service-id=.../ configuration configuration-id=.../ int value=.../ (etc.) properties set-boolean .../ (etc.) /properties /construct On Wed, 1 Oct 2003 10:22:52 -0400, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: Maybe ConstructorFactory? Something like: contruct class=... service service-id=.../ configuration configuration-id=.../ int value=.../ (etc.) /construct The elements inside the construct element are the parameters to the constructor. I'll be setting up a HiveMind:Contrib subproject shortly. We can start putting stuff in there and then migrate it up to library or framework if it proves to be popular and essential. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of
RE: [HiveMind] Testing Interceptors ...
The framework jar includes a base class for tests with many utility methods. You can read a module descriptor and convert it into a registry. Create a test service and extend the implemention with the interceptor. Invoke the methods of the service to see if the interceptor does its job. For example, imagine a transaction interceptor, that starts, commits and rollsback transactions around service methods. You should abstract out the transaction start, commit and rollback into a service and provide a mock implementation of the transaction service that simply logs what it would have done. You can then invoke service methods of the test interface to ensure that the interceptor invokes the supporting service (the transaction service) properly. You may not be able to get full coverage of the actual transaction service itself outside of integration testing, since it will likely require an actual application server to be running. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Johan Lindquist [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 3:36 AM To: Jakarta Commons Developers List Subject: [HiveMind] Testing Interceptors ... A general question: What do you all consider best practices for testing interceptors? Currently involves a lot of manual testing, but would like to move to junit testing for it. Johan -- you too? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [HiveMind] extend BuildFactory to use static fields/methods
I just didn't list out the other primitive types (boolean, long, double, etc.) service-id/ would be the constructed service's id, as a string, alternative to construct service-id-property=.../ service service-id=.../ would be a reference to some other service, analagous to set-service property=... service-id=.../ -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 10:04 AM To: Jakarta Commons Developers List Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard M. Lewis Ship wrote: This looks pretty darn good. Just a few thoughts/observations: 1) Could we just merge ConstructorFactory into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties). I really like the idea as long as we have both the options. 2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/co mmons/bean utils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the framework). Method public static Object invokeConstructor(Class klass, Object[] args) seems to do the trick, and I will be changing other code to start using this. 3) The exception thrown on line 133 should be more descriptive, come from HiveMind.properties, and include the correct Location. 4) Need an update to framework/xdoc/BuilderFactory.xml to describe new features (once merged into BuilderFactory). 5) For the constructor arguments, would this look better: construct ... stringfoo/string serviceservice-id/service configurationconfig-id/configuration ?? Maybe, maybe not. Don't we need the primitives? I think we do. 6) What if the constructor expects the Log, Messages or service id to be a parameter? Need log/ messages/ service-id/ elements. How is service and service-id different? I think we will need a way to pass in everything that we can, so we may need log and messages too. Just my 2 cents. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 6:56 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard, I found it was easiest to develop the service as part of the HiveMind project itself. That way I have all the classpaths set up and could reuse the test harness, etc. Therefore I now attach the additions and changes as a patch. If this isn't convenient for you I will try to separate the code and send it in a different form. --knut Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do like the idea of mixing the two models; write some tests and we'll see about integrating it with hivemind.BuilderFactory. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods I have written a service implementing this strategy, with a minor difference: I didn't add a nested properties as you proposed, instead the set-... elements are immedeate child elements. This way the service can be used everywhere hivemind.BuilderFactory is used. E.g. construct class=... set-service service-id=.../ set-boolean .../ int value=42/ set-int .../ string value=foo/ /construct The constructor parameter elements and property elements can be mixed freely, as long as the constructor parameter elements are given in the same order as in the actual constructor. In this case: int, String. The service supports the following constructor parameter elements: string, int, long, boolean, service, configuration, and resource. If anyone's interested I can supply the source. I just thought I'd write some more unit tests first... --knut Christian Essl [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That would be realy helpful. Maybe we could add a properties tag which would include the current BuilderFactory tags and set the properties after the service is constructed. contruct class=... service service-id=.../ configuration
Re: [HiveMind] extend BuildFactory to use static fields/methods
Ah, I see. Should we stick with our convention of passing values via attributes, may be? But if you are planning on allowing OGNL expressions, the other form may be convenient, but I am not sure if we need to allow expressions in the descriptor though. -Harish Howard M. Lewis Ship wrote: I just didn't list out the other primitive types (boolean, long, double, etc.) service-id/ would be the constructed service's id, as a string, alternative to construct service-id-property=.../ service service-id=.../ would be a reference to some other service, analagous to set-service property=... service-id=.../ -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 10:04 AM To: Jakarta Commons Developers List Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard M. Lewis Ship wrote: This looks pretty darn good. Just a few thoughts/observations: 1) Could we just merge ConstructorFactory into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties). I really like the idea as long as we have both the options. 2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/co mmons/bean utils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the framework). Method public static Object invokeConstructor(Class klass, Object[] args) seems to do the trick, and I will be changing other code to start using this. 3) The exception thrown on line 133 should be more descriptive, come from HiveMind.properties, and include the correct Location. 4) Need an update to framework/xdoc/BuilderFactory.xml to describe new features (once merged into BuilderFactory). 5) For the constructor arguments, would this look better: construct ... stringfoo/string serviceservice-id/service configurationconfig-id/configuration ?? Maybe, maybe not. Don't we need the primitives? I think we do. 6) What if the constructor expects the Log, Messages or service id to be a parameter? Need log/ messages/ service-id/ elements. How is service and service-id different? I think we will need a way to pass in everything that we can, so we may need log and messages too. Just my 2 cents. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 6:56 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard, I found it was easiest to develop the service as part of the HiveMind project itself. That way I have all the classpaths set up and could reuse the test harness, etc. Therefore I now attach the additions and changes as a patch. If this isn't convenient for you I will try to separate the code and send it in a different form. --knut Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do like the idea of mixing the two models; write some tests and we'll see about integrating it with hivemind.BuilderFactory. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods I have written a service implementing this strategy, with a minor difference: I didn't add a nested properties as you proposed, instead the set-... elements are immedeate child elements. This way the service can be used everywhere hivemind.BuilderFactory is used. E.g. construct class=... set-service service-id=.../ set-boolean .../ int value=42/ set-int .../ string value=foo/ /construct The constructor parameter elements and property elements can be mixed freely, as long as the constructor parameter elements are given in the same order as in the actual constructor. In this case: int, String. The service supports the following constructor parameter elements: string, int, long, boolean, service, configuration, and resource. If anyone's interested I can supply the source. I just thought I'd write some more unit tests first... --knut Christian Essl [EMAIL PROTECTED] wrote in message
Re: [HiveMind] extend BuildFactory to use static fields/methods
1) Could we just merge ConstructorFactory into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties). Certainly. I made some sacrifices to make this eventual step as painless as possible. 2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the framework). Method public static Object invokeConstructor(Class klass, Object[] args) seems to do the trick, and I will be changing other code to start using this. I figured that there must be some library doing exactly this, but I didn't know it was available in commons-beanutils. Thanks for the pointer! 3) The exception thrown on line 133 should be more descriptive, come from HiveMind.properties, and include the correct Location. Yes, I was hoping you would comment on this. I'm just learning how things are done in HiveMind, so I just figured I'd do the simplest thing. 4) Need an update to framework/xdoc/BuilderFactory.xml to describe new features (once merged into BuilderFactory). 5) For the constructor arguments, would this look better: construct ... stringfoo/string serviceservice-id/service configurationconfig-id/configuration ?? Maybe, maybe not. Looks nice! I was just reusing the SetPropertyValue class here... 6) What if the constructor expects the Log, Messages or service id to be a parameter? Need log/ messages/ service-id/ elements. Didn't think about that. I assume you would still keep the attributes so these can still be set as properties. The code has many quirks as it is now, but it works. Especially the test cases are coded in a very funky way. I just couldn't figure out how to best do that. Maybe you have a good idea here. If you think it would be helpful I could certainly do some of these changes. Just let me know. --knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging/impl Jdk13LumberjackLogger.java Jdk14Logger.java Log4JLogger.java LogKitLogger.java NoOpLog.java
craigmcc2003/10/02 09:17:57
Modified:logging/src/java/org/apache/commons/logging/impl
Jdk13LumberjackLogger.java Jdk14Logger.java
Log4JLogger.java LogKitLogger.java NoOpLog.java
Log:
Remove final declaration on the Log implementations that still have it
(SimpleLog was already non-final) so that developers can subclass to
specialize the existing behavior.
Revision ChangesPath
1.2 +2 -2
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java
Index: Jdk13LumberjackLogger.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk13LumberjackLogger.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Jdk13LumberjackLogger.java16 Aug 2003 22:35:16 - 1.1
+++ Jdk13LumberjackLogger.java2 Oct 2003 16:17:57 - 1.2
@@ -82,7 +82,7 @@
* @version $Revision$ $Date$
*/
-public final class Jdk13LumberjackLogger implements Log, Serializable {
+public class Jdk13LumberjackLogger implements Log, Serializable {
// - Instance Variables
1.8 +5 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java
Index: Jdk14Logger.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Jdk14Logger.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Jdk14Logger.java 16 Aug 2003 21:58:59 - 1.7
+++ Jdk14Logger.java 2 Oct 2003 16:17:57 - 1.8
@@ -81,7 +81,7 @@
* @version $Revision$ $Date$
*/
-public final class Jdk14Logger implements Log, Serializable {
+public class Jdk14Logger implements Log, Serializable {
// --- Constructors
1.6 +5 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java
Index: Log4JLogger.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/Log4JLogger.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Log4JLogger.java 16 Aug 2003 21:58:59 - 1.5
+++ Log4JLogger.java 2 Oct 2003 16:17:57 - 1.6
@@ -78,7 +78,7 @@
* @author Robert Burrell Donkin
* @version $Id$
*/
-public final class Log4JLogger implements Log, Serializable {
+public class Log4JLogger implements Log, Serializable {
// - Attributes
1.5 +5 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogKitLogger.java
Index: LogKitLogger.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/LogKitLogger.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- LogKitLogger.java 16 Aug 2003 21:58:59 - 1.4
+++ LogKitLogger.java 2 Oct 2003 16:17:57 - 1.5
@@ -82,7 +82,7 @@
* @version $Id$
*/
-public final class LogKitLogger implements Log, Serializable {
+public class LogKitLogger implements Log, Serializable {
// - Attributes
1.3 +5 -5
jakarta-commons/logging/src/java/org/apache/commons/logging/impl/NoOpLog.java
Index: NoOpLog.java
===
RCS file:
/home/cvs/jakarta-commons/logging/src/java/org/apache/commons/logging/impl/NoOpLog.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- NoOpLog.java 30 Mar 2003 23:42:36 - 1.2
+++ NoOpLog.java 2 Oct 2003 16:17:57 - 1.3
@@ -74,7 +74,7 @@
* @author Rod Waldhoff
* @version $Id$
*/
-public final class NoOpLog implements Log {
+public class NoOpLog implements Log {
/** Convenience constructor */
public NoOpLog() { }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] testing
On Thu, 2003-10-02 at 02:12, Henri Yandell wrote: I'm a bit confused with Collections atm. 'ant test' calls src/test/org/apache/commons/collections/TestAll.java. However this does not list tests in sub-packages that I can see [though I imagine things like the iterators package could be tested through TestIteratorUtils. Anyone know what the deal is? Have we switched to Maven for building/testing? Hen There was bug related to this: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23155 It's an oversight. project.xml was switched to use o.a.c.collections.TestAllPackages but build.xml still uses o.a.c.collections.TestAll. My preference would be to change o.a.c.collections.TestAll to do what o.a.c.collections.TestAllPackages does and then revert project.xml to use TestAll. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HiveMind] extend BuildFactory to use static fields/methods
Here's a patch adressing all your points, except 4 ;-). Also there is more testing required. I'll try to find out what the best way is to test this service. Of course this is a new patch not adding to the previous one. So to take a look at it patch it to a fresh grab from HEAD. --knut Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] This looks pretty darn good. Just a few thoughts/observations: 1) Could we just merge ConstructorFactory into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties). 2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the framework). Method public static Object invokeConstructor(Class klass, Object[] args) seems to do the trick, and I will be changing other code to start using this. 3) The exception thrown on line 133 should be more descriptive, come from HiveMind.properties, and include the correct Location. 4) Need an update to framework/xdoc/BuilderFactory.xml to describe new features (once merged into BuilderFactory). 5) For the constructor arguments, would this look better: construct ... stringfoo/string serviceservice-id/service configurationconfig-id/configuration ?? Maybe, maybe not. 6) What if the constructor expects the Log, Messages or service id to be a parameter? Need log/ messages/ service-id/ elements. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 6:56 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods Howard, I found it was easiest to develop the service as part of the HiveMind project itself. That way I have all the classpaths set up and could reuse the test harness, etc. Therefore I now attach the additions and changes as a patch. If this isn't convenient for you I will try to separate the code and send it in a different form. --knut Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I do like the idea of mixing the two models; write some tests and we'll see about integrating it with hivemind.BuilderFactory. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden Sent: Wednesday, October 01, 2003 4:57 PM To: [EMAIL PROTECTED] Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods I have written a service implementing this strategy, with a minor difference: I didn't add a nested properties as you proposed, instead the set-... elements are immedeate child elements. This way the service can be used everywhere hivemind.BuilderFactory is used. E.g. construct class=... set-service service-id=.../ set-boolean .../ int value=42/ set-int .../ string value=foo/ /construct The constructor parameter elements and property elements can be mixed freely, as long as the constructor parameter elements are given in the same order as in the actual constructor. In this case: int, String. The service supports the following constructor parameter elements: string, int, long, boolean, service, configuration, and resource. If anyone's interested I can supply the source. I just thought I'd write some more unit tests first... --knut Christian Essl [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That would be realy helpful. Maybe we could add a properties tag which would include the current BuilderFactory tags and set the properties after the service is constructed. contruct class=... service service-id=.../ configuration configuration-id=.../ int value=.../ (etc.) properties set-boolean .../ (etc.) /properties /construct On Wed, 1 Oct 2003 10:22:52 -0400, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: Maybe ConstructorFactory? Something like: contruct class=... service service-id=.../ configuration configuration-id=.../ int value=.../ (etc.) /construct The elements inside the construct element are the parameters to the constructor. I'll be setting up a HiveMind:Contrib subproject shortly. We can start putting stuff in there and then migrate
Re: [HiveMind] extend BuildFactory to use static fields/methods
Same patch with a quite obvious small tweak (how could I miss that?), which
should also make it more readable...
--knut
Knut Wannheden [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Here's a patch adressing all your points, except 4 ;-). Also there is more
testing required. I'll try to find out what the best way is to test this
service.
Of course this is a new patch not adding to the previous one. So to take a
look at it patch it to a fresh grab from HEAD.
begin 666 hivemind-builder-factory-patch.txt
[EMAIL PROTECTED]('-R8R]D97-CFEP=]R+TU%5$$M24Y+VAI=F5M;V1U;4NUL
M#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]#0I20U,@[EMAIL PROTECTED];64O8W9S
M'5B;EC+VIA:V%R=$M8V]M;6]NRUS86YD8F]X+VAI=F5M:6YD+V9R86UE
M=V]R:R]SF,O95S8W)I'1OB]-151!+4E.1B]H:79E;6]D=6QE+GAM;QV
M#0IR971R:65V:6YG(')E=FES:6]N(#$N,PT*9EF9B M=2 MC$N,R!H:79E
M;6]D=6QE+GAM; T*+2TM('-R8R]D97-CFEP=]R+TU%5$$M24Y+VAI=F5M
M;V1U;4NUL3(U(%-E R,# S(#(Q.C,X.C0P(TP,# P3$N,PT**RLK
M('-R8R]D97-CFEP=]R+TU%5$$M24Y+VAI=F5M;V1U;4NUL3(@3V-T
M(#(P,#,@,38Z-38Z,#,@+3 P,# -D! (TQ-#DL-R K,30Y+#@0$ -B )
M#0H@3QS97)V:6-E+7!O:6YT(ED/2)=6EL95R1F%C=]R2(@:6YT97)F
M86-E/2)OFN87!A8VAE+F-O;6UO;G,N:EV96UI;F0N4V5R=FEC94EMQE
M;65N=%T:6]N1F%C=]R2(@;6]D96P](G-I;F=L971O;B(^#0H@0D\95S
M8W)I'1I;VX^#0HM0E5V5D('1O(-O;G-TG5C=!A('-E[EMAIL PROTECTED])O
M;2!A(-L87-S(YA;[EMAIL PROTECTED]($@V5T(]F('!R;W!EG1I97,@86YD('9A
M;'5ER!T;R!B92!S970@:[EMAIL PROTECTED]AE(ENW1A;G1I871E9!C;%SRX)#0HK
M0E5V5D('1O(-O;G-TG5C=!A('-E[EMAIL PROTECTED])O;2!A(-L87-S(YA
M;[EMAIL PROTECTED](]P=EO;F%L(-O;G-TG5C=]R('!AF%M971EG,@86YD('!R
M;W!EG1I97,N0T*( D)/]D97-CFEP=EO;CX-B )3QP87)A;65T97)S
M+7-C:5M83X-B )2 @/5L96UE;G0@;F%M93TB8V]NW1R=6-T(CX-D!
M(TQ.#L. K,[EMAIL PROTECTED],! 0 T*( D)( )3QR96%D+6%T=')I8G5T92!A
M='1R:6)U=4](FQO9RUPF]P97)T2(@')O5R='D](FQO9U!R;W!EG1Y
M3F%M92(O/@T*( D)( )3QR96%D+6%T=')I8G5T92!A='1R:6)U=4](G-E
MG9I8V4M:60M')O5R='DB('!R;W!EG1Y/2)S97)V:6-E2610F]P97)T
M4YA;64B+SX-B )2 @0D\:6YV;VME+7!AF5N=!M971H;V0](F%D9$5L
M96UE;G0B+SX)#0HM0D@( D\+W)U;5S/@D-BL)2 @3POG5L97,^#0H@
M0D@( D-BL)2 @3QE;5M96YT(YA;64](G-TFEN9R(^#0HK0D@( D)
M/1EV-R:7!T:6]N/@T**PD)( )4$@W1R:6YG('9A;'5E(-O;G-TG5C
M=]R('!AF%M971EBX-BL)2 @0D\+V1EV-R:7!T:6]N/@T**PD)( )
M( -BL)2 @2 @/')U;5S/@T**PD)( )( )/-R96%T92UO8FIE8W0@
M8VQAW,](F]R9RYA%C:4N8V]M;6]NRYH:79E;6EN9YS97)V:6-E+FEM
MPN4V5T0V]NW1R=6-T;W)087)A;65T97(B+SX-BL)2 @2 @3QR96%D
M+6-O;G1E;G0@')O5R='D](G9A;'5E(B\^#0HK0D@( D@( D\:6YV;VME
M+7!AF5N=!M971H;V0](F%D9%!AF%M971EB(O/@D-BL)2 @2 @/]R
M=6QESX-BL)2 @3PO96QE;65N=#X-BL)2 @0T**PD)( )#0HK0D@
M( D\96QE;65N=!N86UE/2)I;G0B/@T**PD)( )3QD97-CFEP=EO;CX-
MBL)2 @0E!;B!I;G1E9V5R('9A;'5E(-O;G-TG5C=]R('!AF%M971E
MBX-BL)2 @0D\+V1EV-R:7!T:6]N/@T**PD)( )( -BL)2 @2 @
M/')U;5S/@T**PD)( )( )/[EMAIL PROTECTED]W,](F]R9RYA
M%C:4N8V]M;6]NRYH:79E;6EN9YS97)V:6-E+FEMPN4V5T0V]NW1R
M=6-T;W)087)A;65T97(B+SX-BL)2 @2 @3QR96%D+6-O;G1E;G0@')O
M5R='D](G9A;'5E(B!TF%NVQA=]R/2)I;G0B+SX-BL)2 @2 @3QI
M;G9O:V4M%R96YT(UE=AO9#TB861D4%R86UE=5R(B\^0T**PD)( )
M( \+W)U;5S/@T**PD)( )/]E;5M96YT/@T**PD)( )#0HK0D@( D\
M96QE;65N=!N86UE/2)L;VYG(CX-BL)2 @0D\95S8W)I'1I;VX^#0HK
M0D@( D)02!L;VYG(@V-UB:70I(EN=5G97(@[EMAIL PROTECTED]W1R=6-T
M;W(@%R86UE=[EMAIL PROTECTED])( )3PO95S8W)I'1I;VX^#0HK0D@( D@
M( T**PD)( )( \G5L97,^#0HK0D@( D@( D\8W)E871E+6]B:F5C=!C
M;%SSTB;W)G+F%P86-H92YC;VUM;VYS+FAI=F5M:6YD+G-EG9I8V4N:6UP
M;Y3971#;VYS=')U8W1OE!AF%M971EB(O/@T**PD)( )( )/')E860M
M8V]N=5N=!PF]P97)T3TB=F%L=64B('1R86YS;%T;W(](FQO;FB+SX-
MBL)2 @2 @3QI;G9O:V4M%R96YT(UE=AO9#TB861D4%R86UE=5R
M(B\^0T**PD)( )( \+W)U;5S/@T**PD)( )/]E;5M96YT/@T**PD)
M( )#0HK0D@( D\96QE;65N=!N86UE/2)B;V]L96%N(CX-BL)2 @0D\
M95S8W)I'1I;VX^#0HK0D@( D)02!B;V]L96%N('9A;'5E(-O;G-TG5C
M=]R('!AF%M971EBX-BL)2 @0D\+V1EV-R:7!T:6]N/@T**PD)( )
M( -BL)2 @2 @/')U;5S/@T**PD)( )( )/-R96%T92UO8FIE8W0@
M8VQAW,](F]R9RYA%C:4N8V]M;6]NRYH:79E;6EN9YS97)V:6-E+FEM
MPN4V5T0V]NW1R=6-T;W)087)A;65T97(B+SX-BL)2 @2 @3QR96%D
M+6-O;G1E;G0@')O5R='D](G9A;'5E(B!TF%NVQA=]R/2)E;G5M97)A
M=EO;BQJ879A+FQA;FN0F]O;5A;BQTG5E/512544L9F%LV4]1D%,4T4B
M+SX-BL)2 @2 @3QI;G9O:V4M%R96YT(UE=AO9#TB861D4%R86UE
M=5R(B\^0T**PD)( )( \+W)U;5S/@T**PD)( )/]E;5M96YT/@D)
M( )#0HK0D)( )#0HK0D@( D\96QE;65N=!N86UE/2)S97)V:6-E(CX-
MBL)2 @0D\95S8W)I'1I;VX^#0HK0D@( D)02!S97)V:6-E(-O;G-T
MG5C=]R('!AF%M971EBX-BL)2 @0D\+V1EV-R:7!T:6]N/@T**PD)
M( )0T**PD)( )3QR=6QESX-BL)2 @0D)/-R96%T92UO8FIE8W0@
M8VQAW,](F]R9RYA%C:4N8V]M;6]NRYH:79E;6EN9YS97)V:6-E+FEM
MPN4V5T0V]NW1R=6-T;W)087)A;65T97(B+SX-BL)2 @0D)/')E860M
M8V]N=5N=!PF]P97)T3TB=F%L=64B('1R86YS;%T;W(](G-EG9I8V4B
M+SX-BL)2 @0D)/EN=F]K92UP87)E;G0@;65T:]D/2)A91087)A;65T
M97(B+SX-BL)2 @0D\+W)U;5S/@T**PD)( )/]E;5M96YT/@T**PD)
M( )#0HK0D@( D\96QE;65N=!N86UE/2)C;VYF:6=UF%T:6]N(CX-BL)
M2 @0D\95S8W)I'1I;VX^#0HK0D@( D)06QL(5L96UE;G1S(-O;G1R
M:6)U=5D('1O([EMAIL PROTECTED])A=EO;B!P;VEN=!AR!A($QI[EMAIL PROTECTED]
MW1R=6-T;W(@%R86UE=[EMAIL PROTECTED])( )3PO95S8W)I'1I;VX^#0HK
M0D)#0HK0D)0D\G5L97,^#0HK0D@( D)3QCF5A=4M;V)J96-T(-L
M87-S/2)OFN87!A8VAE+F-O;6UO;G,N:EV96UI;F0NV5R=FEC92YI;7!L
Re: [collections] testing
On Thu, 2003-10-02 at 16:42, Henri Yandell wrote: On 2 Oct 2003, Janek Bogucki wrote: On Thu, 2003-10-02 at 02:12, Henri Yandell wrote: I'm a bit confused with Collections atm. 'ant test' calls src/test/org/apache/commons/collections/TestAll.java. However this does not list tests in sub-packages that I can see [though I imagine things like the iterators package could be tested through TestIteratorUtils. Anyone know what the deal is? Have we switched to Maven for building/testing? Hen There was bug related to this: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23155 It's an oversight. project.xml was switched to use o.a.c.collections.TestAllPackages but build.xml still uses o.a.c.collections.TestAll. My preference would be to change o.a.c.collections.TestAll to do what o.a.c.collections.TestAllPackages does and then revert project.xml to use TestAll. Why should both not do the same? When I type 'ant test' and 'maven test', they should be equivalent. Unless we decide to drop ant or maven support. Hen The outcome of my suggested changes was meant to be: build.xml uses TestAll project.xml uses TestAll ant test maven test both run all the tests Which is what you want as well. Maybe I worded it badly. -Janek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23491] - Can't configure PerUserPoolDataSource for use with tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23491. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23491 Can't configure PerUserPoolDataSource for use with tomcat --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 17:07 --- I was missing a jar in my common/lib directory as I was not testing with a stock tomcat installation. Unfortunately I was too tired to continue testing after crossing that barrier, I will test further tonight. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23560] - FTPClient.storeFile(...) should return status information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23560 FTPClient.storeFile(...) should return status information [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 17:54 --- This issue report is invalid and I'm closing it. The issue reporter has not read the documentation for getReplyCode() and is requesting a capability that has always existed: http://jakarta.apache.org/commons/net/apidocs/org/apache/commons/net/ftp/FTP.html#getReplyCode() Help on using Commons Net can be obtained from the commons-user mailing list (http://jakarta.apache.org/site/mail.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23560] - FTPClient.storeFile(...) should return status information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23560 FTPClient.storeFile(...) should return status information [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 17:55 --- Closing bug since it is invalid. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] testing
On 2 Oct 2003, Janek Bogucki wrote: On Thu, 2003-10-02 at 16:42, Henri Yandell wrote: Why should both not do the same? When I type 'ant test' and 'maven test', they should be equivalent. Unless we decide to drop ant or maven support. The outcome of my suggested changes was meant to be: build.xml uses TestAll project.xml uses TestAll ant test maven test both run all the tests Which is what you want as well. Maybe I worded it badly. Sorry, my fault. I read it wrong. Your suggestion definitely gets my vote. I'll go ahead and make the change and check it in when I get OrderedMap's values/entrySet/keySet stuff done. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] Maven-generated pages don't point to mailing list page
I just noticed that Maven-generated Commons (sub)project pages don't point to: http://jakarta.apache.org/site/mail.html for mailing lists and instead allow you to directly subscribe or unsubscribe without reading the mailing list guidelines. If I've accidentally dredged up an old topic, just ignore. If it's not been raised, then should we gradually change our Maven-generated mailing list pages to point to http://jakarta.apache.org/site/mail.html? daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/hivemind/xdocs services.xml
hlship 2003/10/02 11:42:06 Modified:hivemind/framework/src/test/hivemind/test/services/impl RunnableImpl.java hivemind/framework/src/test/hivemind/test/services TestThreadedModel.java hivemind/framework/src/java/org/apache/commons/hivemind/impl AbstractServiceModelImpl.java ThreadedServiceModel.java hivemind/framework/src/java/org/apache/commons/hivemind HiveMindMessages.properties hivemind/xdocs services.xml Added: hivemind/framework/src/test/hivemind/test/services/impl RegistryShutdownStringHolderImpl.java DiscardableStringHolderImpl.java hivemind/framework/src/test/hivemind/test/services ThreadedRegistryShutdown.xml ThreadedDiscardable.xml hivemind/framework/src/java/org/apache/commons/hivemind Discardable.java Log: Add Discardable interface, used by the threaded service model. Revision ChangesPath 1.2 +58 -1 jakarta-commons-sandbox/hivemind/framework/src/test/hivemind/test/services/impl/RunnableImpl.java Index: RunnableImpl.java === RCS file: /home/cvs/jakarta-commons-sandbox/hivemind/framework/src/test/hivemind/test/services/impl/RunnableImpl.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- RunnableImpl.java 1 Oct 2003 20:43:21 - 1.1 +++ RunnableImpl.java 2 Oct 2003 18:42:06 - 1.2 @@ -1,3 +1,60 @@ +/* + * + * + * The Apache Software License, Version 1.1 + * + * Copyright (c) 2003 The Apache Software Foundation. All rights + * reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * 3. The end-user documentation included with the redistribution, if + *any, must include the following acknowlegement: + * This product includes software developed by the + *Apache Software Foundation (http://www.apache.org/). + *Alternately, this acknowlegement may appear in the software itself, + *if and wherever such third-party acknowlegements normally appear. + * + * 4. The names The Jakarta Project, Commons, and Apache Software + *Foundation must not be used to endorse or promote products derived + *from this software without prior written permission. For written + *permission, please contact [EMAIL PROTECTED] + * + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their names without prior written + *permission of the Apache Group. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * + * This software consists of voluntary contributions made by many + * individuals on behalf of the Apache Software Foundation. For more + * information on the Apache Software Foundation, please see + * http://www.apache.org/. + * + */ + package hivemind.test.services.impl; import org.apache.commons.hivemind.RegistryShutdownListener; 1.1 jakarta-commons-sandbox/hivemind/framework/src/test/hivemind/test/services/impl/RegistryShutdownStringHolderImpl.java Index: RegistryShutdownStringHolderImpl.java === /* *
[digester][patch] xml schema support. removal
Hi,
the current XML schema supports doesn't work with Xerces 2.3/2.4/2.5
(only 2.1 finaly) (at least that's the case with Tomcat 5). The attached
patch remove the current implementation. People interested to use the
digester with schema/dtd should use instead:
digester.setFeature(
http://apache.org/xml/features/validation/dynamic;,
true);
digester.setFeature(
http://apache.org/xml/features/validation/schema;,
true);
when using Xerces. Other schema parser should have their own way to turn
on validation. Those properties will be standardized in the next jaxp
spec.
A solution may also be the addition of a method called
digester.turnOnSchemaValidation() that contains the above feature, but
has the limitation to only works with Xerces (anybody aware of a schema
parser other that Xerces?)
Thanks,
-- Jeanfrancois
Index: Digester.java
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/Digester.java,v
retrieving revision 1.81
diff -u -r1.81 Digester.java
--- Digester.java 13 Aug 2003 22:05:31 - 1.81
+++ Digester.java 2 Oct 2003 17:46:15 -
@@ -113,12 +113,11 @@
* even from the same thread./p
*
* pstrongIMPLEMENTATION NOTE/strong - A bug in Xerces 2.0.2 prevents
- * the support of XML schema. You need Xerces 2.1 or JAXP 1.2.1 to make
- * that class working with XML schema/p
+ * the support of XML schema. You need Xerces 2.1-2.3 and higher or
+ * JAXP 1.2.1 to make that class working with XML schema/p
*
* @author Craig McClanahan
* @author Scott Sanders
- * @author Jean-Francois Arcand
* @version $Revision: 1.81 $ $Date: 2003/08/13 22:05:31 $
*/
@@ -224,20 +223,6 @@
*/
protected SAXParserFactory factory = null;
-
-/**
- * The JAXP 1.2 property required to set up the schema location.
- */
-private static final String JAXP_SCHEMA_SOURCE =
-http://java.sun.com/xml/jaxp/properties/schemaSource;;
-
-/**
- * The JAXP 1.2 property to set up the schemaLanguage used.
- */
-protected String JAXP_SCHEMA_LANGUAGE =
-http://java.sun.com/xml/jaxp/properties/schemaLanguage;;
-
-
/**
* The Locator associated with our parser.
*/
@@ -308,19 +293,6 @@
*/
protected Rules rules = null;
- /**
- * The XML schema language to use for validating an XML instance. By
- * default this value is set to codeW3C_XML_SCHEMA/code
- */
-protected String schemaLanguage = W3C_XML_SCHEMA;
-
-
-/**
- * The XML schema to use for validating an XML instance.
- */
-protected String schemaLocation = null;
-
-
/**
* The object stack being constructed.
*/
@@ -354,14 +326,6 @@
LogFactory.getLog(org.apache.commons.digester.Digester.sax);
-/**
- * The schema language supported. By default, we use this one.
- */
-protected static final String W3C_XML_SCHEMA =
-http://www.w3.org/2001/XMLSchema;;
-
-
-
// - Properties
/**
@@ -689,15 +653,6 @@
return (null);
}
-// Configure standard properties and return the new instance
-try {
-if (schemaLocation != null) {
-setProperty(JAXP_SCHEMA_LANGUAGE, schemaLanguage);
-setProperty(JAXP_SCHEMA_SOURCE, schemaLocation);
-}
-} catch (Exception e) {
-log.warn( + e);
-}
return (parser);
}
@@ -798,50 +753,6 @@
/**
- * Return the XML Schema URI used for validating an XML instance.
- */
-public String getSchema() {
-
-return (this.schemaLocation);
-
-}
-
-
-/**
- * Set the XML Schema URI used for validating a XML Instance.
- *
- * @param schemaLocation a URI to the schema.
- */
-public void setSchema(String schemaLocation){
-
-this.schemaLocation = schemaLocation;
-
-}
-
-
-/**
- * Return the XML Schema language used when parsing.
- */
-public String getSchemaLanguage() {
-
-return (this.schemaLanguage);
-
-}
-
-
-/**
- * Set the XML Schema language used when parsing. By default, we use W3C.
- *
- * @param schemaLanguage a URI to the schema language.
- */
-public void setSchemaLanguage(String schemaLanguage){
-
-this.schemaLanguage = schemaLanguage;
-
-}
-
-
-/**
* Return the boolean as to whether the context classloader should be used.
*/
public boolean getUseContextClassLoader() {
@@ -1399,8 +1310,8 @@
entityURL = (String) entityValidator.get(publicId);
}
-// Redirect the schema location to a local destination
-if
Re: [beanutils] GenericComparator -I have a project I'd like to contribute to Jakarta Commons.
Tagged to the right commons project. You might want to look at how beanutils accesses bean properties - its slightly different to how you do it. Stephen - Original Message - From: Wickus Martin [EMAIL PROTECTED] A while back I wrote a generic comparator for Java objects and called it GComp. We've been using it internally at the company where I work, but I was wondering if it might not be of value to the commons project. Typically Java programmers create a custom Comparator implementation for every comparison scenario they encounter. GComp on the other hand can compare objects according to complex criteria based on a simple expression that explains how the objects should be compared. Great time saver and prevents problem of many small comparator classes bloating the code base. Usage scenario: Lets say we have a class called Customer with methods to access the first name and last name. Lets also say we have a class called Order that holds a reference to an instance of Customer. To compare orders according to the customer surname (ascending) we could create the following comparator: new GComp(getLastName); To compare a collection of orders according to the customer last name (ascending) and then first name (descending) for those customers with the same last name we could create the following comparator: new GComp([EMAIL PROTECTED]|[EMAIL PROTECTED] ); To order null values last and ignore case we could create: new GComp([EMAIL PROTECTED],nulls=last|getCustomer. [EMAIL PROTECTED],nulls=last); The above code only orders on string objects, but all objects implementing the comparable interface is supported as is primitive types. Currently GComp uses commons-logging to output debugging information if commons logging is found on the classpath. I'm happy to donate the code for further study. Let me know. Keep well, Wickus Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/decorators TestSetList.java TestAll.java
matth 2003/10/02 15:34:44 Modified:collections/src/test/org/apache/commons/collections/decorators TestAll.java Added: collections/src/java/org/apache/commons/collections/decorators SetList.java collections/src/test/org/apache/commons/collections/decorators TestSetList.java Log: Adding SetList decorator from bug #22826 Revision ChangesPath 1.1 jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/SetList.java Index: SetList.java === /* * $Header: /home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/SetList.java,v 1.1 2003/10/02 22:34:44 matth Exp $ * * * The Apache Software License, Version 1.1 * * Copyright (c) 2001-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. * */ package org.apache.commons.collections.decorators; import java.util.AbstractList; import java.util.ArrayList; import java.util.Collection; import java.util.HashSet; import java.util.Iterator; import java.util.List; import java.util.Set; /** * SetList combines the codeList/code and codeSet/code interfaces * in one implementation. * p * The codeList/code interface makes certain assumptions/requirements. * This implementation breaks these in certain ways, but this is merely the * result of rejecting duplicates. * Each violation is explained in the method, but it should not affect you. * p * The [EMAIL PROTECTED] org.apache.commons.collections.decorators.OrderedSet OrderedSet} * class provides an alternative approach, by wrapping an existing Set and * retaining insertion order in the iterator. This class offers the codeList/code * interface implementation as well. * p * If the codeSet/code aspects are important to you (fast add/contains/remove) * then codeOrderedSet/code is a better choice. * This implementation is based solely on codeArrayList/code, and so has * slow add/contains/remove operations for all except small lists. * * @since Commons Collections 3.0 * @version $Revision: 1.1 $ $Date: 2003/10/02 22:34:44 $ * * @author Matthew Hawthorne * @author Stephen Colebourne */
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/observed TestObservableSortedBag.java TestObservableBag.java
scolebourne2003/10/02 15:35:31
Modified:collections/src/test/org/apache/commons/collections/decorators
TestTypedBag.java TestTransformedSortedBag.java
TestPredicatedSortedBag.java TestPredicatedBag.java
TestTypedSortedBag.java TestTransformedBag.java
collections/src/test/org/apache/commons/collections
TestHashBag.java TestTreeBag.java
collections/src/test/org/apache/commons/collections/observed
TestObservableSortedBag.java TestObservableBag.java
Added: collections/src/test/org/apache/commons/collections
AbstractTestBag.java AbstractTestSortedBag.java
Removed: collections/src/test/org/apache/commons/collections
TestBag.java TestSortedBag.java
Log:
Rename TestBag to AbstractTestBag
Rename TestSortedBag to AbstractTestSortedBag
Javadoc and tidy
Revision ChangesPath
1.3 +6 -6
jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestTypedBag.java
Index: TestTypedBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestTypedBag.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestTypedBag.java 20 Sep 2003 17:05:36 - 1.2
+++ TestTypedBag.java 2 Oct 2003 22:35:31 - 1.3
@@ -64,7 +64,7 @@
import org.apache.commons.collections.Bag;
import org.apache.commons.collections.HashBag;
-import org.apache.commons.collections.TestBag;
+import org.apache.commons.collections.AbstractTestBag;
/**
* Extension of [EMAIL PROTECTED] TestBag} for exercising the [EMAIL PROTECTED]
TypedBag}
@@ -75,7 +75,7 @@
*
* @author Phil Steitz
*/
-public class TestTypedBag extends TestBag {
+public class TestTypedBag extends AbstractTestBag {
public TestTypedBag(String testName) {
super(testName);
@@ -100,11 +100,11 @@
return TypedBag.decorate(bag, claz);
}
-public Bag makeBag() {
+protected Bag makeBag() {
return decorateBag(new HashBag(), objectClass);
}
-public Bag makeTestBag() {
+protected Bag makeTestBag() {
return decorateBag(new HashBag(), stringClass);
}
1.3 +5 -5
jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestTransformedSortedBag.java
Index: TestTransformedSortedBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestTransformedSortedBag.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestTransformedSortedBag.java 31 Aug 2003 17:28:42 - 1.2
+++ TestTransformedSortedBag.java 2 Oct 2003 22:35:31 - 1.3
@@ -61,7 +61,7 @@
import junit.framework.TestSuite;
import org.apache.commons.collections.Bag;
-import org.apache.commons.collections.TestBag;
+import org.apache.commons.collections.AbstractTestSortedBag;
import org.apache.commons.collections.TreeBag;
/**
@@ -73,7 +73,7 @@
*
* @author Stephen Colebourne
*/
-public class TestTransformedSortedBag extends TestBag {
+public class TestTransformedSortedBag extends AbstractTestSortedBag {
public TestTransformedSortedBag(String testName) {
super(testName);
@@ -88,7 +88,7 @@
junit.textui.TestRunner.main(testCaseName);
}
-public Bag makeBag() {
+protected Bag makeBag() {
return TransformedSortedBag.decorate(new TreeBag(),
TestTransformedCollection.NOOP_TRANSFORMER);
}
1.4 +6 -6
jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestPredicatedSortedBag.java
Index: TestPredicatedSortedBag.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/decorators/TestPredicatedSortedBag.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- TestPredicatedSortedBag.java 20 Sep 2003 17:05:36 - 1.3
+++ TestPredicatedSortedBag.java 2 Oct 2003 22:35:31 - 1.4
@@ -66,7 +66,7 @@
import org.apache.commons.collections.Predicate;
import org.apache.commons.collections.PredicateUtils;
import org.apache.commons.collections.SortedBag;
-import org.apache.commons.collections.TestBag;
+import org.apache.commons.collections.AbstractTestSortedBag;
import org.apache.commons.collections.TreeBag;
/**
@@ -78,7 +78,7 @@
*
* @author Phil Steitz
*/
-public
DO NOT REPLY [Bug 22826] - [collections] List/Set implementation.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22826. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22826 [collections] List/Set implementation. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 22:38 --- Classes are checked in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/decorators TestTransformedSortedSet.java TestOrderedSet.java TestPredicatedSet.java TestTransformedSet.java
scolebourne2003/10/02 15:48:41
Modified:collections/src/test/org/apache/commons/collections/observed
TestObservableSet.java TestObservableSortedSet.java
collections/src/test/org/apache/commons/collections
TestMap.java TestSetUtils.java
collections/src/test/org/apache/commons/collections/decorators
TestTransformedSortedSet.java TestOrderedSet.java
TestPredicatedSet.java TestTransformedSet.java
Added: collections/src/test/org/apache/commons/collections
AbstractTestSet.java AbstractTestSortedSet.java
Removed: collections/src/test/org/apache/commons/collections
TestSortedSet.java TestSet.java
Log:
Rename TestSet to AbstractTestSet
Rename TestSortedSet to AbstractTestSortedSet
Javadoc and tidy
Revision ChangesPath
1.2 +5 -5
jakarta-commons/collections/src/test/org/apache/commons/collections/observed/TestObservableSet.java
Index: TestObservableSet.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/observed/TestObservableSet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TestObservableSet.java21 Sep 2003 20:01:53 - 1.1
+++ TestObservableSet.java2 Oct 2003 22:48:40 - 1.2
@@ -64,7 +64,7 @@
import junit.framework.Test;
import junit.framework.TestSuite;
-import org.apache.commons.collections.TestSet;
+import org.apache.commons.collections.AbstractTestSet;
/**
* Extension of [EMAIL PROTECTED] TestSet} for exercising the
@@ -75,7 +75,7 @@
*
* @author Stephen Colebourne
*/
-public class TestObservableSet extends TestSet implements
ObservedTestHelper.ObservedFactory {
+public class TestObservableSet extends AbstractTestSet implements
ObservedTestHelper.ObservedFactory {
public TestObservableSet(String testName) {
super(testName);
@@ -91,7 +91,7 @@
}
//---
-public Set makeEmptySet() {
+protected Set makeEmptySet() {
return ObservableSet.decorate(new HashSet(), ObservedTestHelper.LISTENER);
}
1.3 +5 -5
jakarta-commons/collections/src/test/org/apache/commons/collections/observed/TestObservableSortedSet.java
Index: TestObservableSortedSet.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/observed/TestObservableSortedSet.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestObservableSortedSet.java 24 Sep 2003 08:23:56 - 1.2
+++ TestObservableSortedSet.java 2 Oct 2003 22:48:40 - 1.3
@@ -64,7 +64,7 @@
import junit.framework.Test;
import junit.framework.TestSuite;
-import org.apache.commons.collections.TestSortedSet;
+import org.apache.commons.collections.AbstractTestSortedSet;
/**
* Extension of [EMAIL PROTECTED] TestSortedSet} for exercising the
@@ -75,7 +75,7 @@
*
* @author Stephen Colebourne
*/
-public class TestObservableSortedSet extends TestSortedSet implements
ObservedTestHelper.ObservedFactory {
+public class TestObservableSortedSet extends AbstractTestSortedSet implements
ObservedTestHelper.ObservedFactory {
public TestObservableSortedSet(String testName) {
super(testName);
@@ -91,7 +91,7 @@
}
//---
-public Set makeEmptySet() {
+protected Set makeEmptySet() {
return ObservableSortedSet.decorate(new TreeSet(),
ObservedTestHelper.LISTENER);
}
1.30 +6 -6
jakarta-commons/collections/src/test/org/apache/commons/collections/TestMap.java
Index: TestMap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestMap.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- TestMap.java 2 Oct 2003 22:14:28 - 1.29
+++ TestMap.java 2 Oct 2003 22:48:40 - 1.30
@@ -874,7 +874,7 @@
return new TestMapEntrySet();
}
-class TestMapEntrySet extends TestSet {
+class TestMapEntrySet extends AbstractTestSet {
public TestMapEntrySet() {
super();
}
@@ -942,7 +942,7 @@
return new TestMapKeySet();
}
-class TestMapKeySet extends TestSet {
+class TestMapKeySet extends AbstractTestSet {
public TestMapKeySet() {
Re: [HiveMind] Re: Tapestry exception report incomplete?
That would work. I had another idea on my way home. What if the constructRegistry threw an exception if there was any problem in the construction, that is after the registry is built? That way the application can decide what to do. What do you think about that? -Harish Howard M. Lewis Ship wrote: Perhaps we should put a check in RegistryBuilder: if (!LOG.isErrorEnabled()) System.err.println(*** Logging not enabled for . Module parse and validation errors will not be visible. ***); In addition, an earlier version of the code had a brittle flag (that I used during testing). Turning the flag on would make some errors turn into thrown exceptions. I only used it for testing, and eventually discarded that and created a specialized Appended used to determine if certain messages had been logged. It could be ressurected and tied to a JVM system property. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com -Original Message- From: Bill Lear [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 5:11 PM To: Tapestry users Cc: [EMAIL PROTECTED] Subject: Re: [HiveMind] Re: Tapestry exception report incomplete? On Thursday, October 2, 2003 at 17:04:20 (-0400) Harish Krishnaswamy writes: ... Why not just toss the thing and let the app catch it? My understanding is, from a microkernel standpoint, it is not supposed to crash just because one module or service had a problem, you know like the containers, they just report the problem and move on. But the containers have a console or a designated log file that one can take a look at, but HiveMind does not have either, that will be a problem for the uninformed, I think. Hmm, not sure I agree with this --- if someone mis-configures a microkernel, I'd rather have it crash and tell me about it than sputter on and die later, pointing me elsewhere by a subsequently thrown exception. I'll have to think and bring pursue discussion on the hivemind list. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives PROPOSAL.html
scolebourne2003/10/02 16:43:22 Modified:primitives PROPOSAL.html Log: Fix typo Revision ChangesPath 1.2 +1 -1 jakarta-commons-sandbox/primitives/PROPOSAL.html Index: PROPOSAL.html === RCS file: /home/cvs/jakarta-commons-sandbox/primitives/PROPOSAL.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PROPOSAL.html 1 Sep 2003 22:00:54 - 1.1 +++ PROPOSAL.html 2 Oct 2003 23:43:22 - 1.2 @@ -53,7 +53,7 @@ h3(3) Required Jakarta-Commons Resources/h3 ul -liCVS Repository - New directory codepcollections/code in the +liCVS Repository - New directory codeprimitives/code in the codejakarta-commons-sandbox/code CVS repository./li liMailing List - Discussions will take place on the general em[EMAIL PROTECTED]/em mailing list. To help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections build.xml
scolebourne2003/10/02 16:46:54
Modified:collections build.xml
Log:
Add ability to create testframework jar
Revision ChangesPath
1.44 +40 -5 jakarta-commons/collections/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/collections/build.xml,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- build.xml 2 Oct 2003 20:36:11 - 1.43
+++ build.xml 2 Oct 2003 23:46:54 - 1.44
@@ -6,21 +6,33 @@
!-- patternset describing test classes --
patternset id=patternset-test-classes
+ include name=**/AbstractTest*.class/
+ include name=**/BulkTest*.class/
include name=**/Test*.class/
/patternset
!-- patternset describing non test classes --
patternset id=patternset-non-test-classes
include name=**/*.class/
+ exclude name=**/AbstractTest*.class/
+ exclude name=**/BulkTest*.class/
exclude name=**/Test*.class/
/patternset
!-- patternset describing non test source files (*.java, *html, etc.) --
patternset id=patternset-javadocable-sources
include name=**/*/
+ exclude name=**/AbstractTest*.java/
+ exclude name=**/BulkTest*.java/
exclude name=**/Test*.java/
/patternset
+ !-- patternset describing test framework classes --
+ patternset id=patternset-testframework-classes
+ include name=**/AbstractTest*.class/
+ include name=**/BulkTest*.class/
+ /patternset
+
!-- # --
target name=init
@@ -71,6 +83,7 @@
property name=dest.doc.api value=${dest.doc}/api/
property name=dest.jardir value=${dest}/
property name=dest.jardir.jar value=${dest.jardir}/${name}.jar/
+ property name=dest.jardir.testframework.jar
value=${dest.jardir}/${name}-testframework.jar/
property name=dest.jardir.object-jar
value=${dest.jardir}/${name}-object.jar/
property name=dest.jardir.primitive-jar
value=${dest.jardir}/${name}-primitive.jar/
@@ -253,15 +266,18 @@
target name=dist depends=test,dist-jar,doc,dist-tar,dist-zip
description=builds binary distribution/
- target name=dist-jar depends=build
+ target name=dist-jar depends=dist-jar-main/
+ !-- Add testframework to above if it is to be released --
+
+ target name=dist-jar-main depends=build
mkdir dir=${dest.jardir}/
+
mkdir dir=${workdir}/
copy todir=${workdir}
fileset dir=${dest.classes}
patternset refid=patternset-non-test-classes/
/fileset
/copy
-
mkdir dir=${workdir}/META-INF/
copy todir=${workdir}/META-INF file=./LICENSE.txt/
@@ -281,14 +297,32 @@
include name=org/apache/commons/collections/primitives/**/
/fileset
/jar
-
+
delete dir=${workdir}/
- delete dir=${dest.classes}/
+ /target
+
+ target name=dist-jar-testframework depends=build-test
+ mkdir dir=${dest.jardir}/
+
+ mkdir dir=${workdir}/
+ copy todir=${workdir}
+ fileset dir=${dest.classes}
+patternset refid=patternset-testframework-classes/
+ /fileset
+ /copy
+ mkdir dir=${workdir}/META-INF/
+ copy todir=${workdir}/META-INF file=./LICENSE.txt/
+ jar jarfile=${dest.jardir.testframework.jar}
manifest=${source.src}/conf/MANIFEST.MF
+ fileset dir=${workdir}/
+ /jar
+
+ delete dir=${workdir}/
/target
target name=dist-tar depends=dist-jar,doc
+ delete dir=${dest.classes}/
mkdir dir=${workdir}/${bin.name}/
copy todir=${workdir}/${bin.name}
fileset dir=${dest}
@@ -312,6 +346,7 @@
target name=dist-zip depends=dist-jar,doc
+ delete dir=${dest.classes}/
mkdir dir=${workdir}/${bin.name}/
copy todir=${workdir}/${bin.name}
fileset dir=${dest}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] general problem with decorators
This sounds OK, but what would the method be called? OrderedSet.decorate() OrderedSet.decorateHashSet() ? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Basically, the lack of empty constructors with default decoration decisions. Example I'm looking at: I want an OrderedSet. The only way to get this is: OrderedSet.decorate( new HashSet() ) [okay, could do TreeSet etc, also could use MapUtils]. I don't know about you, but this feels odd. :) Especially as the user knows that HashSet is unordered, so why provide it. This may be a unique example, but it seems that we could choose a default empty map for each one. Just a view.. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [HiveMind] Re: Tapestry exception report incomplete?
On Thursday, October 2, 2003 at 19:21:46 (-0400) Harish Krishnaswamy writes: That would work. I had another idea on my way home. What if the constructRegistry threw an exception if there was any problem in the construction, that is after the registry is built? That way the application can decide what to do. What do you think about that? Not to mention that throwing a checked exception is not the same as crashing. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] general problem with decorators
I would prefer something like: OrderedSet.defaultInstance() or OrderedSet.newInstance() It seems more standard... what do you think? Stephen Colebourne wrote: This sounds OK, but what would the method be called? OrderedSet.decorate() OrderedSet.decorateHashSet() ? Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] Basically, the lack of empty constructors with default decoration decisions. Example I'm looking at: I want an OrderedSet. The only way to get this is: OrderedSet.decorate( new HashSet() ) [okay, could do TreeSet etc, also could use MapUtils]. I don't know about you, but this feels odd. :) Especially as the user knows that HashSet is unordered, so why provide it. This may be a unique example, but it seems that we could choose a default empty map for each one. Just a view.. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Newsletter Draft] News as to Jakarta Commons Project from Aug. to Sep.
Dear Jakarta Commons Development Team, (http://jakarta.apache.org/commons/) Hello, Apache newsletter is in progress of preparing the second all-Apache newsletter, news from August to September 2003, which will be published in the middle of October 2003. === What is The Apache Newsletter? === http://www.apache.org/newsletter/ the 'Apache Newsletter Issue 2' will be appeared at http://www.apache.org/newsletter/200309.html and the editorial deadline will be 00:00 GMT-7000, 11th October. We lowered the barrier to entry - anyone will be able to easily contribute, as prepared the ApacheWiki (http://nagoya.apache.org/wiki/apachewiki.cgi). If you have anything to be added to the ApacheWiki, please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue2 and fill up what you want to append. (A few editors per (sub)project would be highly appreciated, indeed) Of course, if you do have a hesitation on writing article via Wiki, please send e-mails to me [EMAIL PROTECTED] directly. Probably, the former newsletter (Apache Newsletter Issue #1) might be able to give you some hints in writing the articles. cf. http://www.apache.org/newsletter/200307.html I am waiting your contributions. Please e-mail to me [EMAIL PROTECTED] whensoever you have a question about this newsletter. Hope to hear from you Sincerely, -- Tetsuya Kitahata ([EMAIL PROTECTED]) - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (The Apache Newsletter Issuer/Editor) http://www.apache.org/newsletter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] TestMap is sweet
I love coding against this class, in that it catches so many things. I hate just how painful Maps are to code fully :) I half think this should form part of some kind of JUnit-Collections-compliancy jar or application. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PR #22654. Any progress?
Odi, No worries. Take your time to polish it. I just wanted to know what was going on, as PR #22654 is the only thing that blocks 2.0rc2 release. Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 09:35 To: Commons HttpClient Project Subject: Re: PR #22654. Any progress? Oleg Kalnichevski wrote: Odi, Any progress on this one? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22654 Do you need a helping hand with it? Oleg I have something that works now, so that Maven site:generate works. However it needs still some work to reflect the settings in the old file. I can post the file to the bugreport if you want. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PR #22654. Any progress?
Kalnichevski, Oleg wrote: No worries. Take your time to polish it. I just wanted to know what was going on, as PR #22654 is the only thing that blocks 2.0rc2 release. Okay, I hope to have it ready until next week. It shouldn't be that hard to do as the documentation on Checkstyle is quite good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23431] - Add the ability to disable the content-type and transfer encoding headers for Parts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23431. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23431 Add the ability to disable the content-type and transfer encoding headers for Parts --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 08:36 --- Fine with me. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 13:58 --- Created an attachment (id=8429) Follow-up patch 2 (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22654] - [Maven] Migrate checkstyle.properties to XML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22654. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22654 [Maven] Migrate checkstyle.properties to XML --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 20:09 --- Created an attachment (id=8434) proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22654] - [Maven] Migrate checkstyle.properties to XML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22654. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22654 [Maven] Migrate checkstyle.properties to XML --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 20:13 --- I migrated the old properties file to the new XML format. Some of the properties in the old file are not available in XML. Also the new XML format provides a lot more options now. We should maybe have a closer look one day. After you apply the patch make sure to use a recent Maven version. This file has been tested with the site:generate target. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-03 02:18 --- Looks good to me. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Apache Newsletter Draft] News as to Jakarta Commons-HttpClient Project from Aug. to Sep.
Dear Jakarta Commons-HttpClient Development Team, (http://jakarta.apache.org/commons/httpclient/) Hello, Apache newsletter is in progress of preparing the second all-Apache newsletter, news from August to September 2003, which will be published in the middle of October 2003. === What is The Apache Newsletter? === http://www.apache.org/newsletter/ the 'Apache Newsletter Issue 2' will be appeared at http://www.apache.org/newsletter/200309.html and the editorial deadline will be 00:00 GMT-7000, 11th October. We lowered the barrier to entry - anyone will be able to easily contribute, as prepared the ApacheWiki (http://nagoya.apache.org/wiki/apachewiki.cgi). If you have anything to be added to the ApacheWiki, please go to http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue2 and fill up what you want to append. (A few editors per (sub)project would be highly appreciated, indeed) Of course, if you do have a hesitation on writing article via Wiki, please send e-mails to me [EMAIL PROTECTED] directly. Probably, the former newsletter (Apache Newsletter Issue #1) might be able to give you some hints in writing the articles. cf. http://www.apache.org/newsletter/200307.html I am waiting your contributions. Please e-mail to me [EMAIL PROTECTED] whensoever you have a question about this newsletter. Hope to hear from you Sincerely, -- Tetsuya Kitahata ([EMAIL PROTECTED]) - Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (The Apache Newsletter Issuer/Editor) http://www.apache.org/newsletter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
