cvs commit: jakarta-commons/daemon/src/native/nt/procrun/bin procrun.dll procrun.exe procrunw.exe
mturk 2003/09/27 23:39:46 Removed: daemon/src/native/nt/procrun/bin procrun.dll procrun.exe procrunw.exe Log: Remove the procrun* binaries. They aren't used anywhere. Only the tomcat.exe and tomcatw.exe will be preserved and maintained. - 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/09/27 23:50:01
Modified:daemon/src/native/nt/procrun procgui.c
Log:
Change the display name from Apache Proces Runner to
Tomcat Service Manager.
Revision ChangesPath
1.3 +4 -4 jakarta-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.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- procgui.c 27 Sep 2003 18:07:55 - 1.2
+++ procgui.c 28 Sep 2003 06:50:01 - 1.3
@@ -57,7 +57,7 @@
*/
/*
- * procrun.
+ * procrun (Tomcat Service Manager)
*
* Contributed by Mladen Turk [EMAIL PROTECTED]
*
@@ -271,7 +271,7 @@
/* set the status to 'green' when received Jk running
* and close the spash window if present
*/
-if (!strncmp(str, INFO: Jk running, 16)) {
+if (STRN_COMPARE(str, INFO: Jk running)) {
ac_show_try_icon(ac_main_hwnd, NIM_MODIFY, ac_cmdname, 0);
/* kill the splash window if present */
if (ac_splash_hwnd)
@@ -670,9 +670,9 @@
memset(bi, 0, sizeof(BROWSEINFO));
SHGetSpecialFolderLocation(hwnd, CSIDL_DRIVES, il);
if (files)
-bi.lpszTitle = Apache Process Runner :\nSelect Folder!;
+bi.lpszTitle = Tomcat Service Manager :\nSelect Folder!;
else
-bi.lpszTitle = Apache Process Runner :\nSelect File!;
+bi.lpszTitle = Tomcat Service Manager :\nSelect File!;
bi.pszDisplayName = str;
bi.hwndOwner = hwnd;
bi.ulFlags =BIF_EDITBOX;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.h
mturk 2003/09/27 23:51:04 Modified:daemon/src/native/nt/procrun procrun.h Log: Bump the version and change the Regitry Key from Process Runner 1.0 to something meaningfull like Tomcat Service Manager. Revision ChangesPath 1.2 +4 -4 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.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- procrun.h 4 Sep 2003 23:28:20 - 1.1 +++ procrun.h 28 Sep 2003 06:51:04 - 1.2 @@ -57,7 +57,7 @@ */ /* - * procrun. + * procrun (Tomcat Service Manager) * * Contributed by Mladen Turk [EMAIL PROTECTED] * @@ -156,7 +156,7 @@ #define PROC_ARG_COUNT 128 #define PROC_BUFSIZE4096 #define PROC_POOL_SIZE 128 -#define PROC_VERSION1.0.1\0 +#define PROC_VERSION1.1.0\0 #define SERVICE_DEPENDENCIESTcpip\0Afd\0\0 #define PROC_ARG_ENVPREFIX //EP// @@ -172,8 +172,8 @@ #define PROC_ARG_UPDATE_SERVICE //US// #define PROC_ARG_EDIT_SERVICE //ES// -#define PROCRUN_VERSION_STR 1.0 -#define PROCRUN_REGKEY_ROOT SOFTWARE\\Apache Software Foundation\\Process Runner PROCRUN_VERSION_STR +#define PROCRUN_VERSION_STR 1.1 +#define PROCRUN_REGKEY_ROOT SOFTWARE\\Apache Software Foundation\\Tomcat Service Manager #define PROCRUN_REGKEY_SERVICES System\\CurrentControlSet\\Services\\%s #define PROCRUN_REGKEY_PARAMS System\\CurrentControlSet\\Services\\%s\\Parameters #define PROCRUN_REGKEY_RSERVICESPROCRUN_REGKEY_ROOT \\%s - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.rc
mturk 2003/09/27 23:51:37 Modified:daemon/src/native/nt/procrun procrun.rc Log: Update the resources to match the exe names. Revision ChangesPath 1.2 +6 -6 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.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- procrun.rc4 Sep 2003 23:28:20 - 1.1 +++ procrun.rc28 Sep 2003 06:51:36 - 1.2 @@ -217,8 +217,8 @@ 1 VERSIONINFO - FILEVERSION 2,1,0,1 - PRODUCTVERSION 2,1,0,1 + FILEVERSION 2,1,1,0 + PRODUCTVERSION 2,1,1,0 FILEFLAGSMASK 0x3fL #if defined(_DEBUG) FILEFLAGS 0x03L @@ -235,12 +235,12 @@ BEGIN VALUE Comments, All rights reserved. The license is available at http://www.apache.org/LICENSE.txt. The Apache HTTP Server project pages are at http://httpd.apache.org/.\0 VALUE CompanyName, Apache Software Foundation\0 - VALUE FileDescription, Apache Process Runner\0 + VALUE FileDescription, Tomcat Service Manager\0 VALUE FileVersion, PROC_VERSION - VALUE InternalName, procrun.exe\0 + VALUE InternalName, tomcatw.exe\0 VALUE LegalCopyright, Copyright © 2000-2003 The Apache Software Foundation.\0 - VALUE OriginalFilename, procrun.exe\0 - VALUE ProductName, Apache Process Runner\0 + VALUE OriginalFilename, tomcatw.exe\0 + VALUE ProductName, Tomcat Service Manager\0 VALUE ProductVersion, PROC_VERSION END END - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.c
mturk 2003/09/27 23:53:10
Modified:daemon/src/native/nt/procrun procrun.c
Log:
Remove the unused dll functions.
The DLL mode will became the Control Panel Applet.
Revision ChangesPath
1.2 +20 -100 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.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- procrun.c 4 Sep 2003 23:28:20 - 1.1
+++ procrun.c 28 Sep 2003 06:53:10 - 1.2
@@ -57,7 +57,7 @@
*/
/*
- * procrun.
+ * procrun (Tomcat Service Manager)
*
* Contributed by Mladen Turk [EMAIL PROTECTED]
*
@@ -2987,106 +2987,26 @@
free_environment(env);
}
#elif defined(PROCRUN_WINDLL)
-#pragma message(Compiling DLL Application mode)
-
-
-BOOL WINAPI DllMain(HINSTANCE hInst,
-ULONG ulReason,
-LPVOID lpReserved)
-{
-
-switch (ulReason) {
-case DLL_PROCESS_ATTACH:
-g_env = NULL;
-break;
-case DLL_PROCESS_DETACH:
-free_environment(g_env);
-break;
-default:
-break;
-}
-return TRUE;
-}
-
-__declspec(dllexport) void InstallService(const char *service_name,
- const char *install,
- const char *image_path,
- const char *display_name,
- const char *description)
-{
-int argc = 0;
-char *argv[12];
-char b[MAX_PATH];
-
-procrun_t *env = alloc_environment();
-g_proc_mode = PROCRUN_MODE_WINDLL;
-g_env = env;
-
-argv[argc++] = PROCRUN.DLL;
-strcpy(b, PROC_ARG_INSTALL_SERVICE);
-strcat(b, service_name);
-argv[argc++] = b;
-argv[argc++] = -- PROCRUN_PARAMS_IMAGE;
-argv[argc++] = (char *)image_path;
-argv[argc++] = -- PROCRUN_PARAMS_INSTALL;
-argv[argc++] = (char *)install;
-argv[argc++] = -- PROCRUN_PARAMS_DISPLAY;
-argv[argc++] = (char *)display_name;
-argv[argc++] = -- PROCRUN_PARAMS_DESCRIPTION;
-argv[argc++] = (char *)description;
-
-procrun_main(argc, argv, _environ, env);
-
-free_environment(env);
-g_env = NULL;
-}
-
-__declspec(dllexport) void UpdateService(const char *service_name,
- const char *param,
- const char *value)
-{
-int argc = 0;
-char *argv[4];
-char b[MAX_PATH], p[MAX_PATH];
-
-procrun_t *env = alloc_environment();
-g_proc_mode = PROCRUN_MODE_WINDLL;
-g_env = env;
-
-argv[argc++] = PROCRUN.DLL;
-strcpy(b, PROC_ARG_UPDATE_SERVICE);
-strcat(b, service_name);
-strcpy(p, --);
-strcat(p, param);
-argv[argc++] = b;
-argv[argc++] = p;
-argv[argc++] = (char *)value;
-
-procrun_main(argc, argv, _environ, env);
-
-free_environment(env);
-g_env = NULL;
-}
-
-__declspec(dllexport) void RemoveService(const char *service_name)
-{
-int argc = 0;
-char *argv[4];
-char b[MAX_PATH];
-
-procrun_t *env = alloc_environment();
-g_proc_mode = PROCRUN_MODE_WINDLL;
-g_env = env;
-
-argv[argc++] = PROCRUN.DLL;
-strcpy(b, PROC_ARG_DELETE_SERVICE);
-strcat(b, service_name);
-argv[argc++] = b;
-procrun_main(argc, argv, _environ, env);
+#pragma message(Compiling Control Panel Application mode)
+
+/* XXX: Work in progress */
+/*
+ * Allows that all the installed TC services
+ * can be managed from Windows Control Panel
+ */
+
+LONG APIENTRY CPlApplet(HWND hwndCPL,
+UINT uMsg,
+LONG lParam1,
+LONG lParam2)
+{
+
+
+
+
+return 1;
+}
-free_environment(env);
-g_env = NULL;
-}
#else
#error Unknown application mode
#endif
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.dsp
mturk 2003/09/27 23:55:13 Modified:daemon/src/native/nt/procrun procrun.dsp Log: Update the build environment to produce the tomcat.exe and tomcatw.exe instead procrun. Revision ChangesPath 1.2 +11 -6 jakarta-commons/daemon/src/native/nt/procrun/procrun.dsp Index: procrun.dsp === RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.dsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- procrun.dsp 4 Sep 2003 23:28:20 - 1.1 +++ procrun.dsp 28 Sep 2003 06:55:13 - 1.2 @@ -44,6 +44,7 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir Debug # PROP Intermediate_Dir Debug +# PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D _WIN32 /D WIN32 /D _DEBUG /D _DEBUG_TRACE /D _WINDOWS /D STRICT /D _WIN32_WINNT=0x0400 /D PROCRUN_WINAPP /D _MBCS /GZ PRECOMP_VC7_TOBEREMOVED /c # ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D _WIN32 /D WIN32 /D _DEBUG /D _DEBUG_TRACE /D _WINDOWS /D STRICT /D _WIN32_WINNT=0x0400 /D PROCRUN_WINAPP /D _MBCS /GZ /c @@ -57,7 +58,7 @@ LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:windows /debug /machine:IX86 /out:Debug\procrunw.exe /pdbtype:sept # SUBTRACT BASE LINK32 /pdb:none -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:windows /debug /machine:IX86 /out:Debug\procrunw.exe /pdbtype:sept +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:windows /debug /machine:IX86 /out:Debug\tomcatw.exe /pdbtype:sept # SUBTRACT LINK32 /pdb:none !ELSEIF $(CFG) == procrun - Win32 Release @@ -84,7 +85,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:windows /debug /machine:IX86 /out:bin\procrunw.exe /pdbtype:sept /opt:ref /opt:icf -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:windows /debug /machine:IX86 /out:bin\procrunw.exe /pdbtype:sept /opt:ref /opt:icf +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:windows /debug /machine:IX86 /out:bin\tomcatw.exe /pdbtype:sept /opt:ref /opt:icf !ELSEIF $(CFG) == procrun - Win32 Debug CONSOLE @@ -97,6 +98,7 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir DebugCONSOLE # PROP Intermediate_Dir DebugCONSOLE +# PROP Ignore_Export_Lib 0 # PROP Target_Dir # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D _WIN32 /D WIN32 /D _DEBUG /D _DEBUG_TRACE /D _CONSOLE /D STRICT /D _WIN32_WINNT=0x0400 /D PROCRUN_CONSOLE /D _MBCS /GZ PRECOMP_VC7_TOBEREMOVED /c # ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I $(JAVA_HOME)\include /I $(JAVA_HOME)\include\win32 /D _WIN32 /D WIN32 /D _DEBUG /D _DEBUG_TRACE /D _CONSOLE /D STRICT /D _WIN32_WINNT=0x0400 /D PROCRUN_CONSOLE /D _MBCS /GZ /c @@ -110,7 +112,7 @@ LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:console /debug /machine:IX86 /pdbtype:sept # SUBTRACT BASE LINK32 /pdb:none -# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:console /debug /machine:IX86 /pdbtype:sept +# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib shlwapi.lib /nologo /subsystem:console /debug /machine:IX86 /out:DebugCONSOLE/tomcat.exe /pdbtype:sept # SUBTRACT LINK32 /pdb:none !ELSEIF $(CFG) == procrun - Win32 Release CONSOLE @@ -124,6 +126,7 @@ # PROP Use_Debug_Libraries 0 # PROP Output_Dir ReleaseCONSOLE # PROP Intermediate_Dir
cvs commit: jakarta-commons/daemon/src/native/nt/procrun/bin tomcat.exe tomcatw.exe
mturk 2003/09/27 23:59:08 Modified:daemon/src/native/nt/procrun/bin tomcat.exe tomcatw.exe Log: Builds that use the new Registry Key, so the old installed services will not be recognized. You may rename the registry to Tomcat Service Manager Revision ChangesPath 1.2 +18 -20jakarta-commons/daemon/src/native/nt/procrun/bin/tomcat.exe Binary file 1.3 +27 -27jakarta-commons/daemon/src/native/nt/procrun/bin/tomcatw.exe Binary file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.c
mturk 2003/09/28 00:04:35
Modified:daemon/src/native/nt/procrun procrun.c
Log:
Bljax...
Remove those CRLF's.
Revision ChangesPath
1.3 +19 -19jakarta-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.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- procrun.c 28 Sep 2003 06:53:10 - 1.2
+++ procrun.c 28 Sep 2003 07:04:35 - 1.3
@@ -2409,7 +2409,7 @@
static LRESULT CALLBACK ttyConsoleCtrlWndProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
-
+
if (msg == WM_CREATE) {
DBPRINTF0(ttyConsoleCtrlWndProc WM_CREATE\n);
return 0;
@@ -2988,24 +2988,24 @@
}
#elif defined(PROCRUN_WINDLL)
#pragma message(Compiling Control Panel Application mode)
-
-/* XXX: Work in progress */
-/*
- * Allows that all the installed TC services
- * can be managed from Windows Control Panel
- */
-
-LONG APIENTRY CPlApplet(HWND hwndCPL,
-UINT uMsg,
-LONG lParam1,
-LONG lParam2)
-{
-
-
-
-
-return 1;
-}
+
+/* XXX: Work in progress */
+/*
+ * Allows that all the installed TC services
+ * can be managed from Windows Control Panel
+ */
+
+LONG APIENTRY CPlApplet(HWND hwndCPL,
+UINT uMsg,
+LONG lParam1,
+LONG lParam2)
+{
+
+
+
+
+return 1;
+}
#else
#error Unknown application mode
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procrun.sln procrun.vcproj
mturk 2003/09/28 00:15:43
Modified:daemon/src/native/nt/procrun procrun.sln procrun.vcproj
Log:
Update the .NET build files.
Revision ChangesPath
1.2 +11 -9 jakarta-commons/daemon/src/native/nt/procrun/procrun.sln
Index: procrun.sln
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.sln,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- procrun.sln 4 Sep 2003 23:28:20 - 1.1
+++ procrun.sln 28 Sep 2003 07:15:43 - 1.2
@@ -1,16 +1,18 @@
-Microsoft Visual Studio Solution File, Format Version 7.00
+Microsoft Visual Studio Solution File, Format Version 8.00
Project({8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}) = procrun, procrun.vcproj,
{A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}
+ ProjectSection(ProjectDependencies) = postProject
+ EndProjectSection
EndProject
Project({8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}) = testchild,
testchild\testchild.vcproj, {C815B005-1292-47F7-9052-F46676CE2879}
+ ProjectSection(ProjectDependencies) = postProject
+ EndProjectSection
EndProject
Global
GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug
- ConfigName.1 = Debug CONSOLE
- ConfigName.2 = Release
- ConfigName.3 = Release CONSOLE
- EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
+ Debug = Debug
+ Debug CONSOLE = Debug CONSOLE
+ Release = Release
+ Release CONSOLE = Release CONSOLE
EndGlobalSection
GlobalSection(ProjectConfiguration) = postSolution
{A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Debug.ActiveCfg = Debug|Win32
@@ -19,8 +21,8 @@
{A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Debug CONSOLE.Build.0 = Debug
CONSOLE|Win32
{A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Release.ActiveCfg =
Release|Win32
{A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Release.Build.0 = Release|Win32
- {A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Release CONSOLE.ActiveCfg =
Release CONSOLE|Win32
- {A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Release CONSOLE.Build.0 =
Release CONSOLE|Win32
+ {A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Release CONSOLE.ActiveCfg =
ReleaseDLL|Win32
+ {A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}.Release CONSOLE.Build.0 =
ReleaseDLL|Win32
{C815B005-1292-47F7-9052-F46676CE2879}.Debug.ActiveCfg = Debug|Win32
{C815B005-1292-47F7-9052-F46676CE2879}.Debug.Build.0 = Debug|Win32
{C815B005-1292-47F7-9052-F46676CE2879}.Debug CONSOLE.ActiveCfg =
Debug|Win32
1.2 +46 -8 jakarta-commons/daemon/src/native/nt/procrun/procrun.vcproj
Index: procrun.vcproj
===
RCS file: /home/cvs/jakarta-commons/daemon/src/native/nt/procrun/procrun.vcproj,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- procrun.vcproj4 Sep 2003 23:28:20 - 1.1
+++ procrun.vcproj28 Sep 2003 07:15:43 - 1.2
@@ -1,7 +1,7 @@
-?xml version=1.0 encoding = windows-1250?
+?xml version=1.0 encoding=windows-1250?
VisualStudioProject
ProjectType=Visual C++
- Version=7.00
+ Version=7.10
Name=procrun
ProjectGUID={A90DF83B-1E82-4610-AFA2-3AC7010BF5D9}
Keyword=Win32Proj
@@ -34,7 +34,7 @@
Tool
Name=VCLinkerTool
AdditionalDependencies=comctl32.lib shlwapi.lib
- OutputFile=$(OutDir)/procrunw.exe
+ OutputFile=Debug/tomcatw.exe
LinkIncremental=2
GenerateDebugInformation=TRUE
ProgramDatabaseFile=$(OutDir)/procrun.pdb
@@ -54,7 +54,13 @@
Tool
Name=VCWebServiceProxyGeneratorTool/
Tool
+ Name=VCXMLDataGeneratorTool/
+ Tool
Name=VCWebDeploymentTool/
+ Tool
+ Name=VCManagedWrapperGeneratorTool/
+ Tool
+ Name=VCAuxiliaryManagedWrapperGeneratorTool/
/Configuration
Configuration
Name=Release|Win32
@@ -81,7 +87,7 @@
Tool
Name=VCLinkerTool
AdditionalDependencies=comctl32.lib shlwapi.lib
- OutputFile=bin/procrunw.exe
+ OutputFile=bin/tomcatw.exe
cvs commit: jakarta-commons/daemon/xdocs procrun.xml
mturk 2003/09/28 00:19:38 Modified:daemon/xdocs procrun.xml Log: Apply the Bill's patches with some minor adjustments. Thanks Bill. Revision ChangesPath 1.4 +64 -7 jakarta-commons/daemon/xdocs/procrun.xml Index: procrun.xml === RCS file: /home/cvs/jakarta-commons/daemon/xdocs/procrun.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- procrun.xml 26 Sep 2003 19:30:52 - 1.3 +++ procrun.xml 28 Sep 2003 07:19:38 - 1.4 @@ -5,6 +5,8 @@ properties titleDaemon : Procrun/title author email=[EMAIL PROTECTED]Jean-Frederic Clere/author + author email=[EMAIL PROTECTED]Bill Barker/author + author email=[EMAIL PROTECTED]Mladen Turk/author /properties body @@ -23,7 +25,7 @@ open the corresponding build project file. ul liFor MSVC 6.x, use codeprocrun.dsw/code/li - liFor MSVC.NET, use codeprocrun.vcproj/code/li + liFor MSVC.NET, use codeprocrun.sln/code/li /ul At this point, you need to select from the build menu which version you want to build (select either the release or debug build, depending on @@ -31,11 +33,12 @@ ul licodeprocrun/code if you want the GUI interface/li licodeprocrun CONSOLE/code if you don't want the GUI interface/li - licodeprocrun DLL/code if you want to launch via coderundll/code/li + licodeprocrun DLL/code if you want the Control Panel application/code/li /ul /p /section section name=Using procrun +subsection name=Installing the service p The first thing that you must do is to install your service. As a special case, if you haved installed Tomcat 5 via the installer, then it @@ -43,15 +46,16 @@ /p p To install the service, you need to use the code//IS///code parameter. - For example: - pre - procrun //IS//Tomcat5 --DisplayName Tomcat 5.0.11 \ ---Description Tomcat 5.0.11 JDK 1.4 http://jakarta.apache.org; \ + Use codetomcatw.exe/code if you want to run the Graphical version, + or codetomcat.exe/code for the non-Graphical version. For example: + source + tomcat //IS//Tomcat5 --DisplayName Tomcat 5.0.12 \ +--Description Tomcat 5.0.12 JDK 1.4 http://jakarta.apache.org; \ --ImagePath c:\devtools\tomcat\5.0\bin\bootstrap.jar \ --StartupClass org.apache.catalina.startup.Bootstrap;main;start \ --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop \ --Java auto -/pre +/source table captionThe options available for installation are/caption trth--DisplayName/th @@ -124,6 +128,59 @@ service from installation program using procrunw./td/tr /table /p +/subsection +subsection name=Running the service +p +You can use the Windows Service Manager to stop and start the +service, as you would for any other service. This is the recommended way +to manage the service./p +p +To test the service, or to simply run the process manually, use the //GT// +option for the Graphical version. For example: +source + tomcatw //GT//Tomcat5 +/source +To test the non-Graphical version, use the //TS// option. For example: +source + tomcat //TS//Tomcat5 +/source +Either of these will start your service as a normal program running under +the identity of the currently logged in user. It is +strongImportant/strong that the Service is stopped before testing, or +these commands will fail./p +/subsection +subsection name=Changing the Service Parameters from the GUI +p +To change the Service settings using the GUI interface, use the //ES// option with +codetomcatw.exe/code. You can then change the settings by entering +the new values in the correct boxes. For example: +source + tomcatw //ES//Tomcat5 +/source +/p +/subsection +subsection name=Changing the Service Parameters from the Command Line +p + To change the Service settings from the command line, use the //US// option. + The parameters are the same as for a href=#Installing%20the%20service + Installing the service/a. For example: + source + tomcat //US//Tomcat5 --Java c:\jsdk1.4.1_02\jre\bin\client\jvm.dll \ + --StdOutputFile c:\Tomcat5\logs\stdout.txt \ + --StdErrorFile c:\Tomcat5\logs\stderr.txt + /source +/p +/subsection +subsection name=Removing the Service +p + To remove the service, use the //DS// option. For example: + source + tomcat //DS//Tomcat5 + /source + This command will remove the service from the Windows Service Manager,
DO NOT REPLY [Bug 23207] - [Daemon][Doc Patch] Filling out the procrun docs
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=23207. 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=23207 [Daemon][Doc Patch] Filling out the procrun docs --- Additional Comments From [EMAIL PROTECTED] 2003-09-28 07:49 --- Sorry if you felt right now that the procrun is the extension to Tomcat. After all it allways was. The GUI is Tomcat related for a long time with the spash screens, log parsing, etc... So you had to tweak that anyhow. OTOH no one expressed the desire to use the procrun in some other ASF project. The rest of the code wasn't changed at all (except the registry key), which is a single point header #define. Registry was changed to allow to enumerate the group of services, cause Control Panel application cannot receive the command line parameters. I'm using the procrun on a daily basis to run the PHP scripts and Java applications as services, just changing some #defines and bitmaps. With some effort all that can be defined at compile time. If you'll stay with your GPL to the latest docs, I'll revert that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23207] - [Daemon][Doc Patch] Filling out the procrun docs
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=23207. 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=23207 [Daemon][Doc Patch] Filling out the procrun docs --- Additional Comments From [EMAIL PROTECTED] 2003-09-28 08:01 --- Created an attachment (id=8375) Apache licenced version of patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23207] - [Daemon][Doc Patch] Filling out the procrun docs
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=23207. 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=23207 [Daemon][Doc Patch] Filling out the procrun docs --- Additional Comments From [EMAIL PROTECTED] 2003-09-28 08:12 --- I've attached a patch without an author tag. This one is Apache Licenced. My opinion hasn't changed, and I still don't want to be associated with the project. As long as I am not attributed in any way, you may use the remaining content as you see fit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/examples/api .cvsignore
rdonkin 2003/09/28 02:38:33 Added: digester/src/examples/api .cvsignore Log: Added ignore file since we're going to be building examples in the source directory. yes, i know that this sounds a little unwise but i can't think of any real issues and it does make things easier for users. Revision ChangesPath 1.1 jakarta-commons/digester/src/examples/api/.cvsignore Index: .cvsignore === *.class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/examples/api/addressbook .cvsignore
rdonkin 2003/09/28 02:38:45 Added: digester/src/examples/api/addressbook .cvsignore Log: Added ignore file since we're going to be building examples in the source directory. yes, i know that this sounds a little unwise but i can't think of any real issues and it does make things easier for users. Revision ChangesPath 1.1 jakarta-commons/digester/src/examples/api/addressbook/.cvsignore Index: .cvsignore === *.class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/examples/api/catalog .cvsignore
rdonkin 2003/09/28 02:38:57 Added: digester/src/examples/api/catalog .cvsignore Log: Added ignore file since we're going to be building examples in the source directory. yes, i know that this sounds a little unwise but i can't think of any real issues and it does make things easier for users. Revision ChangesPath 1.1 jakarta-commons/digester/src/examples/api/catalog/.cvsignore Index: .cvsignore === *.class - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/examples/api/catalog build.xml readme.txt
rdonkin 2003/09/28 02:39:59
Modified:digester/src/examples/api/catalog readme.txt
Added: digester/src/examples/api/catalog build.xml
Log:
Added build for the examples. Submitted by Simon Kitching.
Revision ChangesPath
1.2 +19 -0 jakarta-commons/digester/src/examples/api/catalog/readme.txt
Index: readme.txt
===
RCS file: /home/cvs/jakarta-commons/digester/src/examples/api/catalog/readme.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- readme.txt25 Sep 2003 20:06:23 - 1.1
+++ readme.txt28 Sep 2003 09:39:59 - 1.2
@@ -1,3 +1,5 @@
+== overview
+
The files in this directory are intended as an example of how to use
the Apache Digester's basic functionality via its java interface.
@@ -18,3 +20,20 @@
If you haven't read the addressbook example, it is recommended that
you start there first. This example demonstrates more advanced features
of the digester.
+
+== compiling and running
+
+
+First rename the build.properties.sample file in the parent directory
+to build.properties and edit it to suit your environment. Then in this
+directory:
+
+* to compile:
+ ant compile
+
+* to run:
+ ant run
+
+Alternatively, you can set up your CLASSPATH appropriately, and
+run the example directly. See the build.properties and build.xml
+files for details.
1.1 jakarta-commons/digester/src/examples/api/catalog/build.xml
Index: build.xml
===
project name=Example-Catalog default=compile basedir=.
!-- == Initialize Properties = --
property file=build.properties/!-- Component local --
property file=../build.properties/ !-- examples/api local--
property file=../../../../build.properties/!-- Digetser local --
property file=../../../../../build.properties/ !-- Commons local --
property file=${user.home}/build.properties/ !-- User local--
!-- == External Dependencies = --
!-- The directories corresponding to your necessary dependencies --
property name=jaxp.home value=/usr/local/jaxp1.1/
property name=commons.homevalue=../../../../../
property name=beanutils.home value=${commons.home}/beanutils/
property name=collections.homevalue=${commons.home}/collections/
property name=logging.homevalue=${commons.home}/logging/
property name=digester.homevalue=${commons.home}/digester/
!-- == Derived Values --
!-- The locations of necessary jar files --
property name=jaxp.jaxp.jar value=${jaxp.home}/jaxp.jar/
property name=jaxp.parser.jar value=${jaxp.home}/crimson.jar/
property name=commons-beanutils.jar
value=${beanutils.home}/dist/commons-beanutils.jar/
property name=commons-collections.jar
value=${collections.home}/dist/commons-collections.jar/
property name=commons-logging.jar
value=${logging.home}/dist/commons-logging.jar/
property name=commons-digester.jar
value=${digester.home}/dist/commons-digester.jar/
!-- == Component Declarations --
!-- The name of this component --
property name=component.name value=addressbook/
!-- == Compiler Defaults = --
!-- Should Java compilations set the 'debug' compiler option? --
property name=compile.debug value=true/
!-- Should Java compilations set the 'deprecation' compiler option? --
property name=compile.deprecation value=false/
!-- Should Java compilations set the 'optimize' compiler option? --
property name=compile.optimizevalue=true/
!-- Construct compile classpath --
path id=compile.classpath
pathelement location=./
pathelement location=${jaxp.jaxp.jar}/
pathelement location=${jaxp.parser.jar}/
pathelement location=${commons-beanutils.jar}/
pathelement location=${commons-collections.jar}/
pathelement location=${commons-logging.jar}/
pathelement location=${commons-digester.jar}/
/path
!-- == Executable Targets --
target name=compile
javac srcdir=.
destdir=.
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
classpath refid=compile.classpath/
/javac
/target
target name=clean
delete
fileset dir=. includes=*.class/
cvs commit: jakarta-commons/digester/src/examples/api/addressbook build.xml readme.txt
rdonkin 2003/09/28 02:40:26
Modified:digester/src/examples/api/addressbook readme.txt
Added: digester/src/examples/api/addressbook build.xml
Log:
Added build for the examples. Submitted by Simon Kitching.
Revision ChangesPath
1.2 +18 -0 jakarta-commons/digester/src/examples/api/addressbook/readme.txt
Index: readme.txt
===
RCS file:
/home/cvs/jakarta-commons/digester/src/examples/api/addressbook/readme.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- readme.txt14 Aug 2003 18:25:34 - 1.1
+++ readme.txt28 Sep 2003 09:40:26 - 1.2
@@ -1,3 +1,5 @@
+== overview
+
The files in this directory are intended as an example of how to use
the Apache Digester's basic functionality via its java interface.
@@ -13,3 +15,19 @@
in a tag's body
* how to use the call parameter rule to process the contents of an
xml attribute.
+
+== compiling and running
+
+First rename the build.properties.sample file in the parent directory
+to build.properties and edit it to suit your environment. Then in this
+directory:
+
+* to compile:
+ ant compile
+
+* to run:
+ ant run
+
+Alternatively, you can set up your CLASSPATH appropriately, and
+run the example directly. See the build.properties and build.xml
+files for details.
1.1 jakarta-commons/digester/src/examples/api/addressbook/build.xml
Index: build.xml
===
project name=Example-AddressBook default=compile basedir=.
!-- == Initialize Properties = --
property file=build.properties/!-- Component local --
property file=../build.properties/ !-- examples/api local--
property file=../../../../build.properties/!-- Digester local --
property file=../../../../../build.properties/ !-- Commons local --
property file=${user.home}/build.properties/ !-- User local--
!-- == External Dependencies = --
!-- The directories corresponding to your necessary dependencies --
property name=jaxp.home value=/usr/local/jaxp1.1/
property name=commons.homevalue=../../../../../
property name=beanutils.home value=${commons.home}/beanutils/
property name=collections.homevalue=${commons.home}/collections/
property name=logging.homevalue=${commons.home}/logging/
property name=digester.homevalue=${commons.home}/digester/
!-- == Derived Values --
!-- The locations of necessary jar files --
property name=jaxp.jaxp.jar value=${jaxp.home}/jaxp.jar/
property name=jaxp.parser.jar value=${jaxp.home}/crimson.jar/
property name=commons-beanutils.jar
value=${beanutils.home}/dist/commons-beanutils.jar/
property name=commons-collections.jar
value=${collections.home}/dist/commons-collections.jar/
property name=commons-logging.jar
value=${logging.home}/dist/commons-logging.jar/
property name=commons-digester.jar
value=${digester.home}/dist/commons-digester.jar/
!-- == Component Declarations --
!-- The name of this component --
property name=component.name value=addressbook/
!-- == Compiler Defaults = --
!-- Should Java compilations set the 'debug' compiler option? --
property name=compile.debug value=true/
!-- Should Java compilations set the 'deprecation' compiler option? --
property name=compile.deprecation value=false/
!-- Should Java compilations set the 'optimize' compiler option? --
property name=compile.optimizevalue=true/
!-- Construct compile classpath --
path id=compile.classpath
pathelement location=./
pathelement location=${jaxp.jaxp.jar}/
pathelement location=${jaxp.parser.jar}/
pathelement location=${commons-beanutils.jar}/
pathelement location=${commons-collections.jar}/
pathelement location=${commons-logging.jar}/
pathelement location=${commons-digester.jar}/
/path
!-- == Executable Targets --
target name=compile
javac srcdir=.
destdir=.
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
classpath refid=compile.classpath/
/javac
/target
target name=clean
delete
fileset dir=. includes=*.class/
/delete
delete dir=docs/
cvs commit: jakarta-commons/digester/src/examples/api build.properties.sample build.xml
rdonkin 2003/09/28 02:40:51
Added: digester/src/examples/api build.properties.sample build.xml
Log:
Added build for the examples. Submitted by Simon Kitching.
Revision ChangesPath
1.1
jakarta-commons/digester/src/examples/api/build.properties.sample
Index: build.properties.sample
===
#
# Example build properties
#
# Copy this to build.properties and then edit the properties to
# provide local references.
#
myjars=/home/me/jakarta-commons-jars
commons-beanutils.jar=${myjars}/commons-beanutils.jar
commons-collections.jar=${myjars}/commons-collections.jar
commons-logging.jar=${myjars}/commons-logging.jar
commons-digester.jar=${myjars}/commons-digester.jar
1.1 jakarta-commons/digester/src/examples/api/build.xml
Index: build.xml
===
!--
***
API Examples Script
===
Provides helpful services to get folks up and running
the examples quickly.
* Compile - compiles all the examples to the directories
in which the their source files reside.
* Run - runs each example in turn.
Note:
These examples will only build and run if the
rights jars are in the classpath. The classpath
can be set by copying the build.properties.sample file
in this directory to build.properties and then setting
the properties appropriately. Or by editing the
build.properties file (based on the build.properties.sample
file in CVS) so that it contains absolute paths.
Note:
build.xml files are provided in each subdirectory. This
provide similar fuctionality for each example individually.
Note:
The examples are graduated. It is best to look at them
in order. Please consult the documentation for more details.
***
--
project name=Examples default=about basedir=.
target name='about'
echo
***
API Examples Script
===
Provides helpful services to get folks up and running
the examples quickly.
* Compile - compiles all the examples to the directories
in which the their source files reside.
* Run - runs each example in turn.
Note:
These examples will only build and run if the
rights jars are in the classpath. The classpath
can be set by copying the build.properties.sample file
in this directory to build.properties and then setting
the properties appropriately. Or by editing the
build.properties file (based on the build.properties.sample
file in CVS) so that it contains absolute paths.
Note:
build.xml files are provided in each subdirectory. This
provide similar fuctionality for each example individually.
Note:
The examples are graduated. It is best to look at them
in order. Please consult the documentation for more details.
***
/echo
/target
target name=compile
ant dir=addressbook target=compile/
ant dir=catalog target=compile/
/target
target name=run depends=compile
ant dir=addressbook target=compile/
ant dir=catalog target=compile/
/target
target name=clean
ant dir=addressbook target=clean/
ant dir=catalog target=clean/
/target
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester package.html
rdonkin 2003/09/28 02:41:29
Modified:digester build.xml
digester/src/java/org/apache/commons/digester package.html
Log:
Added build for the examples. Submitted by Simon Kitching.
Revision ChangesPath
1.46 +7 -1 jakarta-commons/digester/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/digester/build.xml,v
retrieving revision 1.45
retrieving revision 1.46
diff -u -r1.45 -r1.46
--- build.xml 28 Apr 2003 17:51:31 - 1.45
+++ build.xml 28 Sep 2003 09:41:29 - 1.46
@@ -190,6 +190,12 @@
/target
+ target name=compile.examples depends=compile
+ description=Compile example code
+ant dir=src/examples/api target=compile/
+ /target
+
+
target name=clean
description=Clean build and distribution directories
deletedir=${build.home}/
1.23 +18 -6
jakarta-commons/digester/src/java/org/apache/commons/digester/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/package.html,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- package.html 30 Aug 2003 18:31:52 - 1.22
+++ package.html 28 Sep 2003 09:41:29 - 1.23
@@ -85,6 +85,9 @@
the processing rules./li
/ul
+pFor example code, see a href=#doc.Usage the usage
+examples/a, and a href=#doc.FAQ.Examples the FAQ /a. /p
+
a name=doc.Properties/a
h3Digester Configuration Properties/h3
@@ -815,6 +818,11 @@
Rule Sets/a if you wish to reuse a particular set of rules, associated
with a particular namespace, in more than one application context./p
+pNote that Digester does not provide general xpath-compliant matching;
+only the namespace attached to the ilast/i element in the match path
+is involved in the matching process. Namespaces attached to parent
+elements are ignored for matching purposes./p
+
h4Using Namespace Prefixes In Pattern Matching/h4
pUsing rules with namespaces is very useful when you have orthogonal rulesets.
@@ -995,13 +1003,17 @@
/pre/code
This property is needed for JAXP 1.2 (XML Schema support) as required
for the Servlet Spec. 2.4 but is not recognized by JAXP 1.1 parsers.
-This warning is harmless.
-/p/li
-listrongWhere Can I Find Example Code?/strong
+This warning is harmless./p
p
-Digester ships with a sample application: a mapping for the emRich Site
Summary/em format used
-by many newsfeeds. Download the source distribution to see how it works.
-/p
+/li
+li/astrongWhere Can I Find Example Code?/strong
+a name=doc.FAQ.Examples
+pDigester ships with a sample application: a mapping for the emRich Site
+Summary/em format used by many newsfeeds. Download the source distribution
+to see how it works./p
+pDigester also ships with a set of examples demonstrating most of the
+features described in this document. See the src/examples subdirectory
+of the source distribution./p
/li
listrongWhen Are You Going To Support emRich Site Summary/em Version
x.y.z?/strong
p
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] further usage examples
committed. many thanks. it should be possible to use maven (thanks dion!) to generate some documentation for the examples. will probably need some jelly to tie everything together. i don't have the time to do this right now so if anyone wants to volunteer to get this working, please post something to the list and i'll hold off. - robert On Saturday, September 27, 2003, at 08:01 AM, Simon Kitching wrote: On Fri, 2003-09-26 at 08:11, robert burrell donkin wrote: hi simon committed. many thanks and keep up the good work. i'll look forward to the next installment :) (i still want to find a way to get maven to generate html from the source but that'll probably need to wait a little while.) Well, the attached are not more examples, but instead a build infrastructure for the examples. With this you can (among other things) type ant compile.examples in the main digester dir to check all the examples build (before a new release for example). Includes: new build.xml for each example new build.xml in src/examples/api, which builds all examples new build.properties.sample in src/examples/api patch to readme.txt files in example directories patch to main build.xml adding target compile.examples patch to package.html to note that examples are available. This should finish up the examples stuff as far as I am concerned. It would indeed be cool to have the examples available as HTML on the maven-generated website or similar! Some day perhaps... Now back to Plugins Cheers, Simon - 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]
[digester] add examples build to tests...?
i'm in favour of adding compiling the examples as part of the tests. (it'd be even better to have some unit tests for them, maybe as example unit tests for newbie developers) rationale: there's nothing worse when trying to learn a new library than mistakes in the examples. the only downside (that i can think of) is that people may need to convert relative to absolute paths in their build.properties file (or we come up with something clever...). comments? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] add examples build to tests...?
On Sun, 2003-09-28 at 21:57, robert burrell donkin wrote: i'm in favour of adding compiling the examples as part of the tests. (it'd be even better to have some unit tests for them, maybe as example unit tests for newbie developers) rationale: there's nothing worse when trying to learn a new library than mistakes in the examples. the only downside (that i can think of) is that people may need to convert relative to absolute paths in their build.properties file (or we come up with something clever...). comments? +1 to compiling the examples as part of the tests. I think there needs to be a way to compile the examples without compiling the tests, though, because many users of Digester won't have junit.jar installed, and won't know what all the test output means. It would be great to have the tests actually verify that the examples work. Not sure how that could be done, though. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons incl_nav.xml
tobrien 2003/09/28 05:05:57 Modified:.incl_nav.xml Log: Added the Japanese translations link to the commons maven nav Revision ChangesPath 1.3 +5 -2 jakarta-commons/incl_nav.xml Index: incl_nav.xml === RCS file: /home/cvs/jakarta-commons/incl_nav.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- incl_nav.xml 26 Sep 2003 14:21:19 - 1.2 +++ incl_nav.xml 28 Sep 2003 12:05:57 - 1.3 @@ -136,8 +136,6 @@ href=http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow// /menu - - menu name=Related Projects item name=DB Commons href=http://db.apache.org/commons// @@ -145,4 +143,9 @@ href=http://xml.apache.org/commons// item name=Apache Commons href=http://commons.apache.org/ +/menu + +menu name=Translations + item name=Japanese +href=http://jakarta.terra-intl.com/commons// /menu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/xdocs procrun.xml
tobrien 2003/09/28 05:12:44 Modified:daemon/xdocs procrun.xml Log: There was an extra closing code tag in this procrun documentation and it was breaking the Maven site generation. This extra closing tag has been removed. Revision ChangesPath 1.5 +1 -1 jakarta-commons/daemon/xdocs/procrun.xml Index: procrun.xml === RCS file: /home/cvs/jakarta-commons/daemon/xdocs/procrun.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- procrun.xml 28 Sep 2003 07:19:38 - 1.4 +++ procrun.xml 28 Sep 2003 12:12:44 - 1.5 @@ -33,7 +33,7 @@ ul licodeprocrun/code if you want the GUI interface/li licodeprocrun CONSOLE/code if you don't want the GUI interface/li - licodeprocrun DLL/code if you want the Control Panel application/code/li + licodeprocrun DLL/code if you want the Control Panel application/li /ul /p /section - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/xdocs navigation.xml
tobrien 2003/09/28 05:21:57 Added: collections/xdocs navigation.xml Log: Added common commons nav to the collections Maven site Revision ChangesPath 1.1 jakarta-commons/collections/xdocs/navigation.xml Index: navigation.xml === ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE project [ !ENTITY commons-nav SYSTEM ../incl_nav.xml ] project name=Collections titleCollections/title organizationLogo href=/images/jakarta-logo-blue.gif Jakarta /organizationLogo body menu name=Commons Collections item name=Overview href=/index.html/ /menu commons-nav; /body /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/xdocs navigation.xml
tobrien 2003/09/28 05:24:59 Modified:digester/xdocs navigation.xml Log: Added common commons nav to the digetser maven site Revision ChangesPath 1.3 +10 -16jakarta-commons/digester/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/digester/xdocs/navigation.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- navigation.xml26 Feb 2003 23:05:53 - 1.2 +++ navigation.xml28 Sep 2003 12:24:59 - 1.3 @@ -1,4 +1,9 @@ ?xml version=1.0 encoding=ISO-8859-1? + +!DOCTYPE project [ +!ENTITY commons-nav SYSTEM ../incl_nav.xml +] + project name=Digester titleDigester/title @@ -7,25 +12,14 @@ /organizationLogo body -menu name=Digester - item name=Overview +menu name=Commons Digester + item name=Overview href=/index.html/ - item name=Developer Guide - href=/apidocs/org/apache/commons/digester/package-summary.html#package_description/ /menu -menu name=Jakarta Community - item name=Get Involved - href=http://jakarta.apache.org/site/getinvolved.html/ - item name=License - href=http://jakarta.apache.org/commons/license.html/ - item name=Mailing Lists - href=http://jakarta.apache.org/site/mail.html/ - item name=CVS Repositories - href=http://jakarta.apache.org/site/cvsindex.html/ - item name=Who We Are - href=http://jakarta.apache.org/site/whoweare.html/ -/menu +commons-nav; + /body /project + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/discovery/xdocs navigation.xml
tobrien 2003/09/28 05:27:12 Added: discovery/xdocs navigation.xml Log: Added the common commons nav to the discovery maven site Revision ChangesPath 1.1 jakarta-commons/discovery/xdocs/navigation.xml Index: navigation.xml === ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE project [ !ENTITY commons-nav SYSTEM ../incl_nav.xml ] project name=Discovery titleDiscovery/title organizationLogo href=/images/jakarta-logo-blue.gif Jakarta /organizationLogo body menu name=Commons Discovery item name=Overview href=/index.html/ /menu commons-nav; /body /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBC AbandonedObjectPool and PoolableConnectionFactory
This should be fixed in CVS now. Glenn John McNally wrote: yes that looks like a correct observation. The synchronization scope could be reduced. john mcnally On Wed, 2003-09-24 at 14:47, Brad Johnson wrote: Hello, I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app. I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track? Thread-43 daemon prio=1 tid=0x0x85215f8 nid=0x29be waiting for monitor entry [5b80b000..5b80c840] at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:316) - waiting to lock 0x45b85a98 (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833) --- several threads like the above wait on the following to complete: Thread-98 daemon prio=1 tid=0x0x8691b10 nid=0x2a1d runnable [5c4ff000..5c501840] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at oracle.net.ns.Packet.receive(Unknown Source) at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:931) at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893) at oracle.jdbc.ttc7.v8Odscrarr.receive(v8Odscrarr.java:178) at oracle.jdbc.ttc7.TTC7Protocol.describe(TTC7Protocol.java:754) - locked 0x4dda5560 (a oracle.jdbc.ttc7.TTC7Protocol) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:860) - locked 0x4dda5560 (a oracle.jdbc.ttc7.TTC7Protocol) at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2391) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2672) at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:572) - locked 0x44f61438 (a oracle.jdbc.driver.OracleStatement) - locked 0x4e07b950 (a oracle.jdbc.driver.OracleConnection) at org.apache.commons.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:188) at org.apache.commons.dbcp.PoolableConnectionFactory.validateConnection(PoolableConnectionFactory.java:338) - locked 0x45b85a98 (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.dbcp.PoolableConnectionFactory.validateObject(PoolableConnectionFactory.java:318) - locked 0x45b85a98 (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:833) Thanks, Brad Johnson Texas Tech University - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Commons [2003/09/28]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 599|Opn|Enh|2001-02-13|Add ability to set parameter with CallParam that i| | 3893|Opn|Enh|2001-10-01|Multiple element body parts problem | | 6508|Ass|Enh|2002-02-17|HttpClient now supports proxyHost and proxyPort - | | 6826|Ass|Enh|2002-03-04|Need to have xml files validated against DTDs as p| | 6829|Ass|Enh|2002-03-04|Allow easier way of user specified tests | | 7069|Ass|Enh|2002-03-13|DTD and DOM Validators| | 7135|Opn|Enh|2002-03-14|Misleading error message when beaninfo class confl| | 7226|Opn|Enh|2002-03-19|Nested Bean Collection| | 7367|New|Nor|2002-03-22|[unspecified] ServiceManager not actually serializ| | 7465|New|Nor|2002-03-25|Need better 'dist' build | | 7981|Ver|Nor|2002-04-11|[codec][PATCH] add 2 new methods for encoding stri| | 8140|Ver|Nor|2002-04-16|Incorrect credentials loop infinitely | |10319|New|Enh|2002-06-28|Instantiate property if null in form bean | |10543|Ass|Enh|2002-07-08|generate ant task automatically from CLI | |10790|New|Enh|2002-07-15|Non-standards configuration and tracking | |10792|New|Enh|2002-07-15|Plug-in authentication modules| |10793|New|Enh|2002-07-15|User definable default headers support| |10794|New|Enh|2002-07-15|User interaction for authentication | |10810|New|Enh|2002-07-15|Response handlers | |10813|New|Enh|2002-07-15|RFC 2965 Support (Port sensitive cookies) | |10815|New|Enh|2002-07-15|Instrumentation for Timings | |10818|Opn|Enh|2002-07-15|Add method enter() and exit() methods to public Lo| |10930|New|Enh|2002-07-18|J2EE FORM authentication (also affects pluggable a| |10957|New|Nor|2002-07-18|Change Header/HeaderElement to handle a list as th| |12807|New|Nor|2002-09-19|[PATCH] x 2 Update build.xml to use commons-loggin| |12858|Ass|Nor|2002-09-20|Style variation in CVS $Header$ tag in embedded LI| |12997|Opn|Nor|2002-09-25|Call the method as soon as the last parameter is e| |13031|New|Enh|2002-09-26|Use regular expression (regex) pattern matching fo| |13370|New|Nor|2002-10-07|[sql] DDL for INTEGER data type incorrect | |13381|New|Enh|2002-10-07|[sql] commons-sql database.xml - OJB repository.x| |13390|New|Nor|2002-10-07|ResponseHeaderHandler and ResponseHeaderValidator | |13426|New|Enh|2002-10-08|[PATCH] xml-reference.xml responseHeader addition | |13743|Opn|Enh|2002-10-17|Need getPropertyType(Class theClass, String propNa| |14036|New|Enh|2002-10-29|MultipartPostMethod does not check for error messa| |14262|Opn|Maj|2002-11-05|SAXBeanWriter produces invalid XML| |14394|Ver|Nor|2002-11-08|Excessive exceptions log under security manager | |14409|New|Nor|2002-11-09|Add support for stuff like [target [target2 [targe| |14667|Ver|Maj|2002-11-19|PropertyUtils.copyProperties does not copy to Dyna| |15046|Opn|Nor|2002-12-04|MissingArgumentException: no argument for option| |15082|Ass|Enh|2002-12-04|[lang] elapsed time formatting utility method | |15297|New|Enh|2002-12-12|[HttpClient] Authenticator() - ability to perform | |15435|New|Enh|2002-12-17|New Preferences Architecture | |15451|Opn|Enh|2002-12-17|Multiple mapped properties not possible / Direct m| |15519|Ver|Maj|2002-12-19|PropertyUtils.getPropertyType() for java.util.Coll| |15534|New|Nor|2002-12-19|Inadequate HTTP proxy server support in HttpClient| |15744|New|Nor|2002-12-31|[unspecified] Scaffold ResultSet used after statem| |15895|Unc|Nor|2003-01-08|In BeanMap all properties are writable (some with | |16038|Opn|Enh|2003-01-13|[beanutils] LocaleBeanUtils.copyProperties() does | |16124|New|Nor|2003-01-15|isHttp11 should have HttpClient scope | |16132|New|Maj|2003-01-15|[Jelly] core:file convert html to lt;htmlgt; | |16394|New|Enh|2003-01-24|Enhance the IndexedListProperty to handle nested l|
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt DoubleLinkedChildBean.java
rdonkin 2003/09/28 07:17:24
Added: betwixt/src/test/org/apache/commons/betwixt
DoubleLinkedChildBean.java
Log:
Added some tests for a bug in the double linked collection reading stuff. Commented
the failures out for now but will retry once the reader refactoring has been completed.
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/DoubleLinkedChildBean.java
Index: DoubleLinkedChildBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/DoubleLinkedChildBean.java,v
1.1 2003/09/28 14:17:24 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2003/09/28 14:17:24 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 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/.
*
* $Id: DoubleLinkedChildBean.java,v 1.1 2003/09/28 14:17:24 rdonkin Exp $
*/
package org.apache.commons.betwixt;
/** This is a child that has a property containing it's parent.
*
* @author Robert Burrell Donkin
* @version $Revision: 1.1 $
*/
public class DoubleLinkedChildBean {
private DoubleLinkedParentBean parent;
private String name;
public DoubleLinkedChildBean () {}
public DoubleLinkedChildBean(DoubleLinkedParentBean parent, String name) {
setParent(parent);
setName(name);
}
public DoubleLinkedParentBean getParent() {
return parent;
}
public void setParent(DoubleLinkedParentBean parent) {
this.parent = parent;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt DoubleLinkedParentBean.java
rdonkin 2003/09/28 07:17:41
Added: betwixt/src/test/org/apache/commons/betwixt
DoubleLinkedParentBean.java
Log:
Added some tests for a bug in the double linked collection reading stuff. Commented
the failures out for now but will retry once the reader refactoring has been completed.
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/DoubleLinkedParentBean.java
Index: DoubleLinkedParentBean.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/DoubleLinkedParentBean.java,v
1.1 2003/09/28 14:17:41 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2003/09/28 14:17:41 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 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/.
*
* $Id: DoubleLinkedParentBean.java,v 1.1 2003/09/28 14:17:41 rdonkin Exp $
*/
package org.apache.commons.betwixt;
import java.util.Iterator;
import java.util.ArrayList;
/** This is a child that has a property containing it's parent.
*
* @author Robert Burrell Donkin
* @version $Revision: 1.1 $
*/
public class DoubleLinkedParentBean {
private ArrayList children = new ArrayList();
private String name;
public DoubleLinkedParentBean () {}
public DoubleLinkedParentBean(String name) {
setName(name);
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Iterator getChildren() {
return children.iterator();
}
public int getSize() {
return children.size();
}
public void addChild(DoubleLinkedChildBean child) {
children.add(child);
child.setParent(this);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt Tweedledee.java
rdonkin 2003/09/28 07:18:03
Added: betwixt/src/test/org/apache/commons/betwixt Tweedledee.java
Log:
Added some tests for a bug in the double linked collection reading stuff. Commented
the failures out for now but will retry once the reader refactoring has been completed.
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/Tweedledee.java
Index: Tweedledee.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/Tweedledee.java,v
1.1 2003/09/28 14:18:03 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2003/09/28 14:18:03 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 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/.
*
* $Id: Tweedledee.java,v 1.1 2003/09/28 14:18:03 rdonkin Exp $
*/
package org.apache.commons.betwixt;
/** Simple bean that with a (brotherly) cycle class graph reference
*
* @author Robert Burrell Donkin
* @version $Revision: 1.1 $
*/
public class Tweedledee {
private Tweedledum tweedledum;
public Tweedledee () {}
public Tweedledee(Tweedledum tweedledum) {
setBrother(tweedledum);
}
public Tweedledum getBrother() {
return tweedledum;
}
public void setBrother(Tweedledum tweedledum) {
this.tweedledum = tweedledum;
}
public String getName() {
return Tweedledee;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt Tweedledum.java
rdonkin 2003/09/28 07:18:17
Added: betwixt/src/test/org/apache/commons/betwixt Tweedledum.java
Log:
Added some tests for a bug in the double linked collection reading stuff. Commented
the failures out for now but will retry once the reader refactoring has been completed.
Revision ChangesPath
1.1
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/Tweedledum.java
Index: Tweedledum.java
===
/*
* $Header:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/Tweedledum.java,v
1.1 2003/09/28 14:18:17 rdonkin Exp $
* $Revision: 1.1 $
* $Date: 2003/09/28 14:18:17 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2002 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/.
*
* $Id: Tweedledum.java,v 1.1 2003/09/28 14:18:17 rdonkin Exp $
*/
package org.apache.commons.betwixt;
/** Simple bean that with a (brotherly) cycle class graph reference
*
* @author Robert Burrell Donkin
* @version $Revision: 1.1 $
*/
public class Tweedledum {
private Tweedledee tweedledee;
public Tweedledum () {}
public Tweedledum(Tweedledee tweedledee) {
setBrother(tweedledee);
}
public Tweedledee getBrother() {
return tweedledee;
}
public void setBrother(Tweedledee tweedledee) {
this.tweedledee = tweedledee;
}
public String getName() {
return Tweedledum;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/betwixt/src/test/org/apache/commons/betwixt TestBeanReader.java
rdonkin 2003/09/28 07:18:31
Modified:betwixt/src/test/org/apache/commons/betwixt
TestBeanReader.java
Log:
Added some tests for a bug in the double linked collection reading stuff. Commented
the failures out for now but will retry once the reader refactoring has been completed.
Revision ChangesPath
1.18 +65 -0
jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestBeanReader.java
Index: TestBeanReader.java
===
RCS file:
/home/cvs/jakarta-commons/betwixt/src/test/org/apache/commons/betwixt/TestBeanReader.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- TestBeanReader.java 14 Aug 2003 20:18:39 - 1.17
+++ TestBeanReader.java 28 Sep 2003 14:18:31 - 1.18
@@ -75,6 +75,7 @@
import java.util.Calendar;
import java.util.Locale;
import java.util.TimeZone;
+import java.util.ArrayList;
import java.text.ParseException;
import java.text.SimpleDateFormat;
@@ -97,6 +98,8 @@
import org.apache.commons.betwixt.strategy.HyphenatedNameMapper;
import org.apache.commons.betwixt.strategy.ConvertUtilsObjectStringConverter;
+import org.apache.commons.collections.CollectionUtils;
+
import org.apache.commons.digester.Rule;
import org.apache.commons.digester.ExtendedBaseRules;
@@ -693,6 +696,68 @@
assertEquals(Bad address (10), Shipley, address.getCity());
assertEquals(Bad address (11), United Kingdom, address.getCountry());
assertEquals(Bad address (12), BD18 2BJ, address.getCode());
+}
+
+public void testIndirectReference() throws Exception
+{
+Tweedledum dum = new Tweedledum();
+Tweedledee dee = new Tweedledee(dum);
+StringWriter out = new StringWriter();
+out.write(?xml version='1.0'?);
+BeanWriter writer = new BeanWriter(out);
+writer.setWriteIDs(false);
+writer.write(dee);
+String xml = ?xml version='1.0'?TweedledeenameTweedledee/name
++ brothernameTweedledum/name/brother/Tweedledee;
+xmlAssertIsomorphic(parseString(xml), parseString(out) , true);
+
+BeanReader reader = new BeanReader();
+
+reader.setMatchIDs(false);
+reader.registerBeanClass(Tweedledee.class);
+Tweedledee bean = (Tweedledee) reader.parse(new StringReader(xml));
+assertNotNull(bean.getBrother());
+}
+
+public void _testDoubleLinkedCollectionRead() throws Exception
+{
+String xml = ?xml version='1.0'?DOUBLE_LINKED_PARENT_BEAN
++ NAMECronus/NAME
++ CHILDREN
++ CHILDNAMEHades/NAME/CHILD
++ CHILDNAMEHera/NAME/CHILD
++ CHILDNAMEHestia/NAME/CHILD
++ CHILDNAMEDemeter/NAME/CHILD
++ CHILDNAMEPoseidon/NAME/CHILD
++ CHILDNAMEZeus/NAME/CHILD
++ /CHILDREN/DOUBLE_LINKED_PARENT_BEAN;
+
+BeanReader reader = new BeanReader();
+reader.getXMLIntrospector().setElementNameMapper(new
HyphenatedNameMapper(true, _));
+reader.registerBeanClass(DoubleLinkedParentBean.class);
+DoubleLinkedParentBean bean = (DoubleLinkedParentBean) reader.parse(new
StringReader(xml));
+
+assertNotNull(Bean read, bean);
+assertEquals(Cronus, Parent name, bean.getName());
+assertEquals(Number of children, 6, bean.getSize());
+
+ArrayList list = new ArrayList();
+CollectionUtils.addAll(list, bean.getChildren());
+
+DoubleLinkedChildBean childZero = (DoubleLinkedChildBean) list.get(0);
+DoubleLinkedChildBean childOne = (DoubleLinkedChildBean) list.get(1);
+DoubleLinkedChildBean childTwo = (DoubleLinkedChildBean) list.get(2);
+DoubleLinkedChildBean childThree = (DoubleLinkedChildBean) list.get(3);
+DoubleLinkedChildBean childFour = (DoubleLinkedChildBean) list.get(4);
+DoubleLinkedChildBean childFive = (DoubleLinkedChildBean) list.get(5);
+
+assertEquals(Child name zero, Hades, childZero.getName());
+assertEquals(Child name one, Hera, childZero.getName());
+assertEquals(Child name two, Hestia, childZero.getName());
+assertEquals(Child name three, Demeter, childZero.getName());
+assertEquals(Child name four, Poseidon, childZero.getName());
+assertEquals(Child name five, Zeus, childZero.getName());
+
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Proposal to change Rules interface to return ListIterator for matches
On Saturday, September 27, 2003, at 06:43 PM, Craig R. McClanahan wrote: Simon Kitching wrote: Hi, The current Rules interface defines public List match(String uri, String patern); This is giving me significant problems for the Plugins module I am working on. I also think it is simply the wrong type to be returning here; a List has many operations available on it which are not appropriate in this situation. I would like to suggest that the following method be added to the Rules interface, and the matches methods be deprecated: public ListIterator iterator(String uri, String pattern); This seems to me to encapsulate the goal of the existing matches method: to provide access to the set of Rule objects matching the criteria. [I'm flexible on the method name ;-] I'm OK with the concept of returning an iterator from a Rules implementation, but would suggest (if we do it) that the signature say Iterator instead of ListIterator (the implementation in RulesBase can, of course, return a ListIterator if it wants to). We'd certainly need to keep the existing match() signature around for backwards compatibility. Adding methods to interfaces is also a nasty thing to do, but I suspect most people will be extending RulesBase already. i'm not so sure about that. when i developed the RegexRules i discovered that when creating a very different implementation, RulesBase is unsuitable. (that's why i added AbstractRulesImpl.) if we are thinking about changing Rules yet again then it seems to me that we should consider whether making this class an interface was the correct design decision in the first place. if Rules had been an abstract class then it would have been very easy to make the change suggested by simon without breaking compatibility. maybe it should be an abstract class. we could think about deprecating Rules in favour of an abstract class (AbstractMatchingRules or something). getRules and setRules would be deprecated but would continue to be supported via wrappers. we could add getMatchingRules and setMatchingRules methods which take instances of the abstract class. i'd prefer to go down this route (if possible) since it would not only preserve backward compatibility but also allow more flexible modifications to be made in the future. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
At 22:39 -0400 9/27/03, Henri Yandell wrote: I'm interested in the convert stuff. Especially the Object-String stuff. First a question on Dates. Why not support for java.util.Date? It seems that there's not much point having SqlDateConverter, it should just be DateConverter based on util.Date. The trick is that there's no universal conventions for formatting regular dates as strings, while java.sql.Date has a valueOf(String) method which adheres to a well-defined format standard. It's easy enough to write a Converter implementation that is seeded with a SimpleDateFormat pattern-string, but it's also possible that you'd need to deal with dates in more than one format, especially if you are dealing with times as distinct from dates. I've worked around with a custom converter as described above, but I've never come up with a good solution for a general framework for it. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/daemon/src/native/nt/procrun procgui.c procrun.c procrun.dsp procrun.dsw procrun.h
mturk 2003/09/28 08:52:35
Modified:daemon/src/native/nt/procrun procgui.c procrun.c procrun.dsp
procrun.dsw procrun.h
Log:
Revert the latest 'lame Tomcat' patches.
Revision ChangesPath
1.4 +1 -1 jakarta-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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- procgui.c 28 Sep 2003 06:50:01 - 1.3
+++ procgui.c 28 Sep 2003 15:52:35 - 1.4
@@ -57,7 +57,7 @@
*/
/*
- * procrun (Tomcat Service Manager)
+ * procrun
*
* Contributed by Mladen Turk [EMAIL PROTECTED]
*
1.4 +93 -13jakarta-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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- procrun.c 28 Sep 2003 07:04:35 - 1.3
+++ procrun.c 28 Sep 2003 15:52:35 - 1.4
@@ -57,7 +57,7 @@
*/
/*
- * procrun (Tomcat Service Manager)
+ * procrun
*
* Contributed by Mladen Turk [EMAIL PROTECTED]
*
@@ -2989,23 +2989,103 @@
#elif defined(PROCRUN_WINDLL)
#pragma message(Compiling Control Panel Application mode)
-/* XXX: Work in progress */
-/*
- * Allows that all the installed TC services
- * can be managed from Windows Control Panel
- */
-
-LONG APIENTRY CPlApplet(HWND hwndCPL,
-UINT uMsg,
-LONG lParam1,
-LONG lParam2)
-{
+BOOL WINAPI DllMain(HINSTANCE hInst,
+ULONG ulReason,
+LPVOID lpReserved)
+{
+
+switch (ulReason) {
+case DLL_PROCESS_ATTACH:
+g_env = NULL;
+break;
+case DLL_PROCESS_DETACH:
+free_environment(g_env);
+break;
+default:
+break;
+}
+return TRUE;
+}
+__declspec(dllexport) void InstallService(const char *service_name,
+ const char *install,
+ const char *image_path,
+ const char *display_name,
+ const char *description)
+{
+int argc = 0;
+char *argv[12];
+char b[MAX_PATH];
+procrun_t *env = alloc_environment();
+g_proc_mode = PROCRUN_MODE_WINDLL;
+g_env = env;
+
+argv[argc++] = PROCRUN.DLL;
+strcpy(b, PROC_ARG_INSTALL_SERVICE);
+strcat(b, service_name);
+argv[argc++] = b;
+argv[argc++] = -- PROCRUN_PARAMS_IMAGE;
+argv[argc++] = (char *)image_path;
+argv[argc++] = -- PROCRUN_PARAMS_INSTALL;
+argv[argc++] = (char *)install;
+argv[argc++] = -- PROCRUN_PARAMS_DISPLAY;
+argv[argc++] = (char *)display_name;
+argv[argc++] = -- PROCRUN_PARAMS_DESCRIPTION;
+argv[argc++] = (char *)description;
+
+procrun_main(argc, argv, _environ, env);
+free_environment(env);
+g_env = NULL;
+}
+
+__declspec(dllexport) void UpdateService(const char *service_name,
+ const char *param,
+ const char *value)
+{
+int argc = 0;
+char *argv[4];
+char b[MAX_PATH], p[MAX_PATH];
-return 1;
+procrun_t *env = alloc_environment();
+g_proc_mode = PROCRUN_MODE_WINDLL;
+g_env = env;
+
+argv[argc++] = PROCRUN.DLL;
+strcpy(b, PROC_ARG_UPDATE_SERVICE);
+strcat(b, service_name);
+strcpy(p, --);
+strcat(p, param);
+argv[argc++] = b;
+argv[argc++] = p;
+argv[argc++] = (char *)value;
+
+procrun_main(argc, argv, _environ, env);
+
+free_environment(env);
+g_env = NULL;
}
+
+__declspec(dllexport) void RemoveService(const char *service_name)
+{
+int argc = 0;
+char *argv[4];
+char b[MAX_PATH];
+
+procrun_t *env = alloc_environment();
+g_proc_mode = PROCRUN_MODE_WINDLL;
+g_env = env;
+
+argv[argc++] = PROCRUN.DLL;
+strcpy(b, PROC_ARG_DELETE_SERVICE);
+strcat(b, service_name);
+argv[argc++] = b;
+procrun_main(argc, argv, _environ, env);
+
+free_environment(env);
+g_env = NULL;
+}
#else
#error Unknown application mode
1.3 +6 -6 jakarta-commons/daemon/src/native/nt/procrun/procrun.dsp
Index:
[PROCRUN] reorganization
Hi, Since the procrun is fairly generic application that might have it's usage beyond the Tomcat5 scope, after some consultations with remm, I propose the following reorganization: 1. All the TC specific code and resources will be moved to j-t-c/procrun. 2. There will be no build files in the bin neither they will be maintained. 3. The binaries will be in the j-t-c/procrun/bin so that we can use them in the installation build. 4. Make the needed callback mechanism to enable the separation. There is another approach; that we make the subfolder 'tomcat' in the procrun and keep all the tomcat specific code in there. It could have its purpose too, cause it will show how to customize the procrun to a specific application look and feel, without the need to download from j-t-c. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
On Sun, 28 Sep 2003, Sgarlata Matt wrote: From: Henri Yandell [EMAIL PROTECTED] Secondly...I think the Convert system needs improvement. The basic problem is highlighted by: ConvertUtils.register(Converter, Class). It ought to be: ConvertUtils.register(Converter, Class from, Class to). I agree this may be more intuitive and easier to program, but I think the current system does the job (see additional comments below). I want to register a Converter for Date-String and another for Date-sql.Timestamp. I believe this is already possible. The calls would be ConvertUtils.register(DateConverter, java.util.Date); ConvertUtils.register(DateConverter, java.sql.Date); So how would I register a Converter to handle sql.Date-Long converting? I want [hypothetically, please ignore inheritence here]: sql.Date-sql.Timestamp util.Date-sql.Timestamp util.Date-lang.Long The current register system means I have to write my own registry system in my converter. I believe the ConvertUtils registry wants to actually be a multi-registry [ie registry of registries], which can return either a value when given two keys, or a registry when given one key. Beanutils would usually ask for: ConvertRegistry.get(String.class, type) when pushing data in, and would ask for ConvertRegistry.get(type, Object.class) when outputting data. The Converter in charge of 'Long' to Object is effectively the default one. It could also save a little effort by asking for: ConvertRegistry.getLHS(String.class) and it would get a ConvertSubRegistry which always assumes the left hand side is a String. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp/xdocs configuration.xml
dirkv 2003/09/28 09:57:24 Modified:dbcp/xdocs configuration.xml Log: defaultCatalog configuration option Revision ChangesPath 1.2 +7 -1 jakarta-commons/dbcp/xdocs/configuration.xml Index: configuration.xml === RCS file: /home/cvs/jakarta-commons/dbcp/xdocs/configuration.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- configuration.xml 14 Sep 2003 20:22:22 - 1.1 +++ configuration.xml 28 Sep 2003 16:57:24 - 1.2 @@ -9,10 +9,11 @@ body +!-- section name=Introduction pTODO: add section about tomcat configuration and avoiding the resource leak when reloading tomcat webapps./p /section - +-- section name=Parameters @@ -70,6 +71,11 @@ liSERIALIZABLE/li /ul /td +/tr +tr + tddefaultCatalog/td + td/td + tdThe default catalog of connections created by this pool./td /tr /table - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
On Sun, 28 Sep 2003, Joe Germuska wrote: At 22:39 -0400 9/27/03, Henri Yandell wrote: I'm interested in the convert stuff. Especially the Object-String stuff. First a question on Dates. Why not support for java.util.Date? It seems that there's not much point having SqlDateConverter, it should just be DateConverter based on util.Date. The trick is that there's no universal conventions for formatting regular dates as strings, while java.sql.Date has a valueOf(String) method which adheres to a well-defined format standard. It's easy enough to write a Converter implementation that is seeded with a SimpleDateFormat pattern-string, but it's also possible that you'd need to deal with dates in more than one format, especially if you are dealing with times as distinct from dates. I've worked around with a custom converter as described above, but I've never come up with a good solution for a general framework for it. Not convinced by this argument. 1) Dates are just an example here. An especially gruesome example, so specific issues don't bother me too much. 2) Date.valueOf is as good as DateFormat.format. Both of them make massive assumptions about the format desired. This just means that people need to be able to set their own option [and that BeanUtils needs to supply more than just the default options]. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/dbcp/xdocs navigation.xml
dirkv 2003/09/28 09:59:36 Modified:dbcp/xdocs navigation.xml Log: defaultCatalog configuration option Revision ChangesPath 1.2 +1 -1 jakarta-commons/dbcp/xdocs/navigation.xml Index: navigation.xml === RCS file: /home/cvs/jakarta-commons/dbcp/xdocs/navigation.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- navigation.xml26 Sep 2003 16:08:14 - 1.1 +++ navigation.xml28 Sep 2003 16:59:36 - 1.2 @@ -1,7 +1,7 @@ ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE project [ -!ENTITY commons-nav SYSTEM ../incl_nav.xml +!ENTITY commons-nav SYSTEM ../../incl_nav.xml ] project name=Commons - DBCP href=http://jakarta.apache.org/commons/dbcp/; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/pool release_notes.txt RELEASE_PLAN_2_0.txt
dirkv 2003/09/28 10:02:43 Added: pool release_notes.txt RELEASE_PLAN_2_0.txt Log: prepare for release Revision ChangesPath 1.1 jakarta-commons/pool/release_notes.txt Index: release_notes.txt === Release notes for Commons-Pool 2.0 === There were a lot changes since the 1.0.1 release on 12 Aug 2002. * A lot of corner cases were fixed * Performance improvement by optimizing pool synchronization, the critical code paths were optimized by reducing pool synchronization but we also added more synchronization where needed * New minIdle feature: the minimum number of objects allowed in the pool before the evictor thread (if active) spawns new objects. (Note no objects are created when: numActive + numIdle = maxActive) * New maxTotal feature: a cap on the total number of instances controlled by a pool. Only for GenericKeyedObjectPool where maxActive is a cap on the number of active instances from the pool (per key). * UML Class sequence diagrams * The following issues were resolved: (see Bugzilla for complete description) 128402002-10-31EnhFIXEFactor out syncronized block Evictor code to method 128412002-10-30NorFIXEGenericObjectPool unused variable and unused synchronized block 131282002-10-30MajDUPLGenericKeyedObjectPool: _activeMap.get(key) increment is not balanced with decrements 136492002-10-29NorFIXEGenericObjectPool: Negative _maxActive doesn't allow growth 137052002-10-30NorFIXEAdd invalidateObject() method to ObjectPool 149702002-11-30NorFIXEPassing null for Stack[Keyed]ObjectPool factory causes NullPointerException 149812003-04-24NorFIXEgetNumActive() count is wrong when returnObject() is used to pre-populate StackObjectPool 149822003-03-05EnhFIXEGenericObjectPool does not work with null factory. 149832003-03-14EnhFIXEGenericObjectPool should allow for manual population of the pool 179312003-03-13MinFIXEPatch to update the javadocs for StackObjectPool 179622003-03-13NorFIXEMisc javadoc updates and clean up for GenericKeyedObjectPool 179632003-03-13EnhFIXEGeneral cleanup in GenericObjectPool 179682003-03-13EnhFIXEAllow zero idle objects in GenericObjectPool 179692003-03-13NorFIXEAdditional javadocs for StackKeyedObjectPool 179902003-04-18MajFIXELeaking DB connections - synch problem in GenericKeyedObject 180622003-04-18CriFIXEborrowObject/validation infinite loop and deadlock issue in 186172003-04-07MinFIXEDelegatingPreparedStatement throws misleading exception 191922003-04-22EnhFIXEover agressive synchronize causing performance problem 218382003-08-11EnhFIXEWeird HTML makes the pool example doc hard to read 225972003-08-21EnhFIXEminIdle Functionality 230602003-09-20CriFIXEPool not available for download 1.1 jakarta-commons/pool/RELEASE_PLAN_2_0.txt Index: RELEASE_PLAN_2_0.txt === Release Plan for Pool 2.0 -- Administrivia: This document describes a plan for a 2.0 release of the Jakarta-Commons Pool component (for the remainder of this document, simply Pool). Per the Jakarta/ASF guidelines (http://jakarta.apache.org/site/decisions.html), this document doesn't mean anything until accepted by the relevant committer community via a lazy majority vote (hereafter, simply lazy majority). Once accepted, it may be replaced by an alternative plan, again subject to lazy majority approval. Non-binding votes (votes cast by those outside the relevant committer community) are welcome, but only binding votes are significant for decision making purposes. Objective: The objective of the 2.0 release of Pool is to provide a stable and robust release with the intention of providing a stable foundation for the further evolution of the Pool component. Release Manager: Dirk Verbeeck (assuming no one else is really itching to do it) Release Process: The Jakarta Commons release process will be followed. http://jakarta.apache.org/commons/releases/index.html Timeline: (All days ending at 23:59:59 GMT in case of dispute.) * Preparation Period 28 September 2003 - 30 September 2003 During this period, all issues preventing building a release candidate should be a addressed. All other updates (documentation and website) are not blocking. * Review Period 1 October 2003 - 24 October
cvs commit: jakarta-commons/dbcp release_notes.txt RELEASE_PLAN_2_0.txt
dirkv 2003/09/28 10:03:43 Added: dbcp release_notes.txt RELEASE_PLAN_2_0.txt Log: prepare for release Revision ChangesPath 1.1 jakarta-commons/dbcp/release_notes.txt Index: release_notes.txt === Release notes for Commons-DBCP 2.0 === There were a lot changes since the 1.0 release on 12 Aug 2002. * All existing featueres can now be configured by JNDI Context providers (Tomcat) * The double close() of a pooled connection is more effectively blocked (you may experience more Already closed SQLExceptions) * Prepared statement pooling is now implemented in BasicDataSource (set poolPreparedStatements=true, maxOpenPreparedStatements=xxx) * Access to the undelying connection is blocked by default You can access the underlying connection by setting accessToUnderlyingConnectionAllowed=true and by using the following construct: Connection dconn = ((DelegatingConnection) conn).getInnermostDelegate(); * New minIdle parameter for a minimum number of idle connections ready for use * New connection default properties: defaultCatalog defaultTransactionIsolation * Missing driverClassName will now give the folowing error No suitable driver * Bad validationQuery will produce a meaningfull SQLException * UML Class sequence diagrams, configuration documentation * The following issues were resolved: (see Bugzilla for complete description) 69342003-09-20BloDUPLSQLTransformer.java - infinite loop in getConnection 70382002-03-18NorFIXEDBCP does not build under JDK 1.4 77272002-04-20MajFIXEInfinite loop (stack overflow) in BasicDataSource 77282002-04-20MajFIXEBasicDataSource cannot use many JDBC drivers 86202002-04-29NorINVAClosed Connection Exception on setAutoCommit 90732002-07-20NorFIXEBasicDataSource - invalid connections are not checked 98502002-07-20NorFIXENo way to get at SQLException if connection to database fail 105922002-07-20NorDUPLdataSource.getConnection never returns in Tomcat using DBCP 106142002-07-20NorFIXEDBCP connection pooling broken in Tomcat-4.1.7 (regression) 106882002-07-20MinFIXEVersion in the Manifest 109692002-07-20MajFIXEBasicDataSource defaults are unusable 115072002-08-06NorINVACleanup dead connections 120472002-11-01NorINVAvalidationQuery + MSSQL 124002002-11-07NorWORKsame connections 124092002-11-01BloFIXEConnection can be closed twice 127332003-02-06NorFIXE[DBCP][PATCH]Statement.getResultSet() doesn't return null if 128692002-11-01MajFIXEAbandoned Connections are never closed 130772002-11-07EnhFIXEJdbc2PoolDataSource issues 131292002-11-01NorFIXECPDSConnectionFactory prints invalid error messages 131552002-10-30NorDUPLunexpected exausted pool error 132352002-11-16BloFIXEreferenced UserPassKey instances get erroneously returned to 139302003-03-06EnhFIXEAdding connection parameters to BasicDataSourceFactory 139882003-03-17EnhDUPLpermission error makes connection loop 142672003-04-28MajINVADBCP doesn't work on Tomcat 4.1.12 and Oracle JDBC driver 145922002-11-15EnhINVADBCP must be robust against e.g. database shutdowns 146632003-05-14NorREMITomcat5 server hangs when trying to get the database connect 151232003-08-21MajFIXEIncorrect stack trace shown when abandoned connections are c 155392003-02-06MajDUPLStrange Result Set on output 162832003-02-01NorWONTInproper use of Exception 165812003-03-06MajFIXEDeadlock in AbandonedObjectPool when firewall closes connect 166292003-03-06NorFIXE org.apache.commons.dbcp.jdbc2pool.Jdbc2PoolDataSource: setti 169872003-08-11MajFIXErace condition in PoolableConnection.close() 170152003-03-06NorFIXEGenericObjectPool.invalidateObject() doesn't work with Aband 172002003-03-06MajFIXEDBCP: org.apache.commons.dbcp.cpdsadapter.PooledConnectionIm 173012003-04-08NorWONTNPE in Oracle driver when using DBCP PoolingDataSource 174562003-04-08EnhFIXEBasicDataSource should use commons-logging 176352003-03-06MinFIXEPoolableConnectionFactory-Construction declared to throw Exc 176772003-05-31MajINVAPooled connection architecture vulnerable to double use 176782003-04-01MajFIXEDBCP Fails silently in many cases 176802003-03-13MajINVA
[VOTE][Pool] Release Plan for Commons-Pool 2.0
I'd like to propose a vote on the following release plan for Pool 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/pool/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [ ] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I'll volunteer to be the release manager for this release, but if someone else wants to, feel free to volunteer. - Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][DBCP] Release Plan for Commons-DBCP 2.0
I'd like to propose a vote on the following release plan for DBCP 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [ ] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I'll volunteer to be the release manager for this release, but if someone else wants to, feel free to volunteer. - Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
On Sunday, September 28, 2003, at 08:43 AM, Sgarlata Matt wrote: - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, September 27, 2003 10:39 PM Subject: [beanutils] some ideas snip First a question on Dates. Why not support for java.util.Date? It seems that there's not much point having SqlDateConverter, it should just be DateConverter based on util.Date. Good question; I can't guess why java.sql.Date would be provided and java.util.Date would not (if anything, it seems like it should be the other way around). here how i see it. (maybe craig will give you the authorized version sometime.) converting java.util.Date's is can of worms. here's a couple of reasons to get you started: 1. not all java.util.Date's are equal (in symantic meaning). they can mean a time, a day, a date-time or a timestamp. the symantic meaning of each determines how it should be converted. 2. it's hard to come up with a good default conversions which are valid worldwide. the java.sql date-related types are much better defined symantically and good default conversions exist for each. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
On Sunday, September 28, 2003, at 08:43 AM, Sgarlata Matt wrote: - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, September 27, 2003 10:39 PM Subject: [beanutils] some ideas snip Solutions could be either: 1) Improve the system for the mapping converters so it is many-to-many. 2) Create a hierarchy structure. A ConvertUtilsBeansConverter could be plugged in to handle a class, and would contain its own batch of Converters. Any ideas? I think the Converter interface is fine, but could perhaps use some better documentation and examples (in the JavaDoc... the converters in the distribution seem more general-purpose than will be the converters a user needs to create). I do like the idea of adding a new ConvertUtils.register(Converter, Class from, Class to) method. this (and related issues) have come up before. i've thought about this quite a lot and i'm in favour of making the conversion pluggable strategy. this would allow both different and more sophisticated conversion algorithms to be created without breaking backwards compatibility. i don't realistically have the time to go about the creation of new implementations right now but i can certainly point people in the right direction if they want to go down this route. BTW stephen has talked before about creating a separate component that would provide sophisticated solutions to the issue posed by conversion. it might be a good idea to involve him in any design discussions. i now also that ted (of struts fame) is interested in the conversion problem so there may be enough momentum to at least think about creating a dedicated component. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0
Dirk Verbeeck wrote: I'd like to propose a vote on the following release plan for DBCP 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [X] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I will help test DBCP 2.0 with Tomcat 5. Speaking of the release schedule, it would be great if it could be included in the initial stable TC 5, given that critical issues are being addressed. Would it be possible to accelerate the schedule ? To be included with TC 5, it would mean it needs to be released before the end of October (and likely a bit earlier). Of course, I understand it's not a good idea to rush releases, so if it can't happen, so be it :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Plan for Commons-DBCP 2.0
Why are we changing the major release version number? Have backward incompatible changes occurred? If not, we should stick to incrementing the minor version number in the 1.x series. David --- Dirk Verbeeck [EMAIL PROTECTED] wrote: I'd like to propose a vote on the following release plan for DBCP 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [ ] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I'll volunteer to be the release manager for this release, but if someone else wants to, feel free to volunteer. - Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDBC AbandonedObjectPool and PoolableConnectionFactory
You can remove the synchronization of the validateObject method in PoolableConnectionFactory but be carefull. If the query is slow because the database is overloaded then allowing more validationQueries will increase the problem. For the next release I'm thinking about monitoring SQLExceptions thrown by the connection and invalidating the connection before it is returned to the pool. This will cover broken connections. Combined with a testOnBorrowOldConnection it can replace the current testOnBorrow. Dirk Brad Johnson wrote: Hello, I noticed the latest commit to AbandonedObjectPool.java in the Jakarta Commons DBCP project. The changes seem to fix some thread blocking that I have observed lately on our Tomcat uPortal app. I tried out the new nightly (9/24/03) today, and I think another point of thread contention has been exposed when using the validate connection features of DBCP. I'm worried that if the validation query takes too long/hangs then all the other threads that want a connection will be blocked until it times out. Do you think I'm on the right track? stacktrace removed Thanks, Brad Johnson Texas Tech University - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0
OK, I don't expect any problem. New proposal: Review: 1 October 2003 - 15 October 2003 Final vote 16 October 2003- 18 October 2003 Release: 19 October 2003 Dirk Remy Maucherat wrote: Dirk Verbeeck wrote: I'd like to propose a vote on the following release plan for DBCP 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [X] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I will help test DBCP 2.0 with Tomcat 5. Speaking of the release schedule, it would be great if it could be included in the initial stable TC 5, given that critical issues are being addressed. Would it be possible to accelerate the schedule ? To be included with TC 5, it would mean it needs to be released before the end of October (and likely a bit earlier). Of course, I understand it's not a good idea to rush releases, so if it can't happen, so be it :) Remy - 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/validator/src/share/org/apache/commons/validator Field.java
dgraham 2003/09/28 11:47:32
Modified:validator/src/share/org/apache/commons/validator Field.java
Log:
javadoc changes only.
Revision ChangesPath
1.25 +32 -25
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- Field.java26 Aug 2003 16:08:50 - 1.24
+++ Field.java28 Sep 2003 18:47:32 - 1.25
@@ -76,9 +76,10 @@
/**
* p
- * This contains the list of pluggable validators to run on a field and any message
- * information and variables to perform the validations and generate error
- * messages. Instances of this class are configured with a lt;fieldgt; xml
element.
+ * This contains the list of pluggable validators to run on a field and any
+ * message information and variables to perform the validations and generate
+ * error messages. Instances of this class are configured with a
+ * lt;fieldgt; xml element.
* /p
*
* @author David Winterfeldt
@@ -122,6 +123,7 @@
protected String depends = null;
protected int page = 0;
+
protected int fieldOrder = 0;
/**
@@ -130,19 +132,20 @@
protected FastHashMap hDependencies = new FastHashMap();
/**
- * Internal representation of this.depends String as a List. This List gets
updated
- * whenever setDepends() gets called. This List is synchronized so a call to
- * setDepends() (which clears the List) won't interfere with a call to
- * isDependency().
+ * Internal representation of this.depends String as a List. This List
+ * gets updated whenever setDepends() gets called. This List is
+ * synchronized so a call to setDepends() (which clears the List) won't
+ * interfere with a call to isDependency().
*/
private List dependencyList = Collections.synchronizedList(new ArrayList());
protected FastHashMap hVars = new FastHashMap();
+
protected FastHashMap hMsgs = new FastHashMap();
/**
- * Holds Maps of arguments. args[0] returns the Map for the first replacement
- * argument.
+ * Holds Maps of arguments. args[0] returns the Map for the first
+ * replacement argument.
* @since Validator 1.1
*/
protected Map[] args = new Map[10];
@@ -334,10 +337,11 @@
}
/**
- * Gets the default codeArg/code object at the given position. If the key
- * finds a codenull/code value then the default value will try to be
retrieved.
- * @param key The name the Arg is stored under. If not found, the default Arg
for
- * the given position (if any) will be retrieved.
+ * Gets the codeArg/code object at the given position. If the key
+ * finds a codenull/code value then the default value will be
+ * retrieved.
+ * @param key The name the Arg is stored under. If not found, the default
+ * Arg for the given position (if any) will be retrieved.
* @param position The Arg number to find.
* @return The Arg with the given name and position or null if not found.
* @since Validator 1.1
@@ -349,7 +353,8 @@
Arg arg = (Arg) args[position].get(key);
-// Didn't find default arg so exit, otherwise we would get into infinite
recursion
+// Didn't find default arg so exit, otherwise we would get into
+// infinite recursion
if ((arg == null) key.equals(DEFAULT_ARG)) {
return null;
}
@@ -375,8 +380,9 @@
}
/**
- * Gets the arg0 codeArg/code object based on the key passed in. If the key
- * finds a codenull/code value then the default value will try to be
retrieved.
+ * Gets the arg0 codeArg/code object based on the key passed in. If
+ * the key finds a codenull/code value then the default value will
+ * be retrieved.
* @deprecated Use getArg(String, 0) instead.
*/
public Arg getArg0(String key) {
@@ -542,7 +548,8 @@
/**
* If there is a value specified for the indexedProperty field then
- * codetrue/code will be returned. Otherwise it will be codefalse/code.
+ * codetrue/code will be returned. Otherwise it will be
+ * codefalse/code.
*/
public boolean isIndexed() {
return ((indexedListProperty != null indexedListProperty.length() 0));
@@ -653,8 +660,8 @@
}
/**
- * Replace the arg codeCollection/code key value with the key/value pairs
- * passed in.
+ * Replace the arg codeCollection/code key value with the key/value
+ *
Re: [VOTE][DBCP] Release Plan for Commons-DBCP 2.0
I felt there were too many changes to just release a 1.1and I didn't review if there were incompatible changes since 1.0. But I'm not opposed to a 1.1 release. Committers, indicate your preference please Release is a 1.1 or 2.0 Dirk David Graham wrote: Why are we changing the major release version number? Have backward incompatible changes occurred? If not, we should stick to incrementing the minor version number in the 1.x series. David --- Dirk Verbeeck [EMAIL PROTECTED] wrote: I'd like to propose a vote on the following release plan for DBCP 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [ ] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I'll volunteer to be the release manager for this release, but if someone else wants to, feel free to volunteer. - Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - 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: [VOTE][Pool] Release Plan for Commons-Pool 2.0
I have the same question here as I did for DBCP: are there any backwards incompatible changes that require a major release number change? I'd prefer to keep the major number the same if possible. FWIW, I haven't seen any incompatible changes in the DBCP or Pool commits that I've reviewed. David --- Dirk Verbeeck [EMAIL PROTECTED] wrote: I'd like to propose a vote on the following release plan for Pool 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/pool/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [ ] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I'll volunteer to be the release manager for this release, but if someone else wants to, feel free to volunteer. - Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0
Dirk Verbeeck wrote: OK, I don't expect any problem. New proposal: Review: 1 October 2003 - 15 October 2003 Do you plan to release an alpha or a beta at the start of the review period ? That would be really useful :) (I'd include the binary with a new TC 5 beta to get wide real world testing) Final vote 16 October 2003- 18 October 2003 Release: 19 October 2003 Great ! Since the schedule is compatible, I'll switch TC 5 to a 2.0 (or 1.1, whatever) preview build as soon as one is available. Thanks :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator TestCommon.java
dgraham 2003/09/28 12:26:17
Modified:validator/src/test/org/apache/commons/validator
TestCommon.java
Log:
Cleaned up exception handling.
Revision ChangesPath
1.3 +10 -5
jakarta-commons/validator/src/test/org/apache/commons/validator/TestCommon.java
Index: TestCommon.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/TestCommon.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestCommon.java 6 Sep 2003 05:22:47 - 1.2
+++ TestCommon.java 28 Sep 2003 19:26:17 - 1.3
@@ -70,13 +70,15 @@
import org.apache.commons.logging.LogFactory;
/**
- * Consolidates reading in xml config file into parent class.
+ * Consolidates reading in XML config file into parent class.
*/
abstract public class TestCommon extends TestCase {
+
/**
* Resources used for validation tests.
*/
protected ValidatorResources resources = null;
+
/**
* Commons Logging instance.
*/
@@ -97,14 +99,17 @@
try {
in = this.getClass().getResourceAsStream(file);
resources = new ValidatorResources(in);
+
} catch (IOException e) {
log.error(e.getMessage(), e);
throw e;
+
} finally {
if (in != null) {
try {
in.close();
-} catch (Exception e) {
+} catch (IOException e) {
+log.error(e.getMessage(), e);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0
I'll tag make a release candidate for both components. Expect an announcement in a day or two. (unless there are -1 votes) Dirk Remy Maucherat wrote: Dirk Verbeeck wrote: OK, I don't expect any problem. New proposal: Review: 1 October 2003 - 15 October 2003 Do you plan to release an alpha or a beta at the start of the review period ? That would be really useful :) (I'd include the binary with a new TC 5 beta to get wide real world testing) Final vote 16 October 2003- 18 October 2003 Release: 19 October 2003 Great ! Since the schedule is compatible, I'll switch TC 5 to a 2.0 (or 1.1, whatever) preview build as soon as one is available. Thanks :) Remy - 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: [VOTE][Pool] Release Plan for Commons-Pool 2.0
Same response, I don't really have a strong feeling about it, just wanted to keep in sync with DBCP (at least the mayor version). OK, no incompatible changes = keep major number. New proposal: Release both DBCP pool as 1.1 Dirk David Graham wrote: I have the same question here as I did for DBCP: are there any backwards incompatible changes that require a major release number change? I'd prefer to keep the major number the same if possible. FWIW, I haven't seen any incompatible changes in the DBCP or Pool commits that I've reviewed. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
Robert, thanks for pointing out that these issues have been discussed before. Here are the two threads I could find: http://www.mail-archive.com/[EMAIL PROTECTED]/msg17188.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg05085.html Hen, let me be honest and say I'm not quite sure I understand all your ideas regarding registries, but it sounds like a different approach to the same problems discussed in the first thread above, right? All, it sounds like there is interest in improving ConvertUtils. Before we discuss *how* we are going to improve it, let's discuss *what* we want to improve. From what I can tell these are the deficiencies that have been identified so far: - Converters must be registered for each type, and subtypes do not inherit converters. In one of the threads above someone mentioned this is particular a problem when dealing with Enumerations. - The current system of one converter per object leads to a monolithic converter and is not flexible enough. It would be nice to define converts for a pair of classes, such as Date - Long instead of Date - anything and everything. - (I'm not as sure about this) ConvertUtils only allows a single set of conversion rules to exist, since it is a static class. It would be good if different conversions could be defined for different circumstances. Can anyone think of any others? Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE][Pool] Release Plan for Commons-Pool 2.0
I'll tag make a release candidate for both components. Expect an announcement in a day or two. (unless there are -1 votes) Great. And I see that it will now be v1.1. +1 on the release plans. Will test with James. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java
dgraham 2003/09/28 13:39:58 Modified:validator/src/test/org/apache/commons/validator ValidatorTestSuite.java validator/src/share/org/apache/commons/validator Field.java Added: validator/src/test/org/apache/commons/validator FieldTest.java Log: Added Field.getArgs(String) to make it easier to retrieve all of the Args for a given validator. Without this method, you need to know how many Args to retrieve with the getArg(String, int) method. Also, the Field.args array was changed to start with a 0 length instead of 10. This way the array will only grow to the length of the largest argument position. This will make populating the array slower (because of the resizing) but will make it easier for clients to deal with the array returned from getArgs(). Revision ChangesPath 1.11 +5 -4 jakarta-commons/validator/src/test/org/apache/commons/validator/ValidatorTestSuite.java Index: ValidatorTestSuite.java === RCS file: /home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/ValidatorTestSuite.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- ValidatorTestSuite.java 8 Jun 2003 21:33:22 - 1.10 +++ ValidatorTestSuite.java 28 Sep 2003 20:39:57 - 1.11 @@ -100,6 +100,7 @@ suite.addTestSuite(CreditCardValidatorTest.class); suite.addTest(ValidatorTest.suite()); suite.addTest(LocaleTest.suite()); + suite.addTestSuite(FieldTest.class); suite.addTestSuite(FlagsTest.class); suite.addTest(UrlTest.suite()); 1.1 jakarta-commons/validator/src/test/org/apache/commons/validator/FieldTest.java Index: FieldTest.java === /* * $Header: /home/cvs/jakarta-commons/validator/src/test/org/apache/commons/validator/FieldTest.java,v 1.1 2003/09/28 20:39:57 dgraham Exp $ * $Revision: 1.1 $ * $Date: 2003/09/28 20:39:57 $ * * * * 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 acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names, Apache, 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 name, 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
Re: [beanutils] some ideas
On Sun, 28 Sep 2003, Sgarlata Matt wrote: Robert, thanks for pointing out that these issues have been discussed before. Here are the two threads I could find: http://www.mail-archive.com/[EMAIL PROTECTED]/msg17188.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg05085.html Hen, let me be honest and say I'm not quite sure I understand all your ideas regarding registries, but it sounds like a different approach to the same problems discussed in the first thread above, right? Yep. One of my options was to use the first one, where you have a specialised Converter class. However this is a bit of a hack and really the internals of ConvertUtils should just move from 1 dimensional to 2 dimensional. The idea I was tending towards would have ConvertUtils use 'ConverterSet's internally. For the second email, Stephen and I have remakred to each other before about the desire to get convert-utils more usable by other projects. All, it sounds like there is interest in improving ConvertUtils. Before we discuss *how* we are going to improve it, let's discuss *what* we want to improve. From what I can tell these are the deficiencies that have been identified so far: - Converters must be registered for each type, and subtypes do not inherit converters. In one of the threads above someone mentioned this is particular a problem when dealing with Enumerations. Yep. One of the problems here is how to define the inheritence lookup policy. Effectively we have the multiple inheritence problem. I've a ClassMap class that I use for these kinds of things, but it imposes a certain lookup policy and is not generic. - (I'm not as sure about this) ConvertUtils only allows a single set of conversion rules to exist, since it is a static class. It would be good if different conversions could be defined for different circumstances. Kind of. If you dig into the code enough, you can lug ConvertUtilsBeans and ConvertUtils around a bit I think, but it doesn't look like a simple, easy to do piece of code. It needs to be much easier. Can anyone think of any others? Need lots more in the way of standard converters. Not all standard converters need be defaults. Need a wrapper for convert utils that provides a configuration system so people are not always building their own structures. This should not be mandatory however. Needs to still fit BeanUtils' needs. Collection converters need to support internal Converters. ie) might want to turn an ArrayList of Person into an ArrayList of String. Perhaps? :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][Pool] Release Plan for Commons-Pool 2.0
--- Dirk Verbeeck [EMAIL PROTECTED] wrote: Same response, I don't really have a strong feeling about it, just wanted to keep in sync with DBCP (at least the mayor version). Pool is independent from DBCP and doesn't need to depend on DBCP's version numbers. Backwards incompatible changes trigger a major version change, not necessarily changes in other projects. David OK, no incompatible changes = keep major number. New proposal: Release both DBCP pool as 1.1 Dirk David Graham wrote: I have the same question here as I did for DBCP: are there any backwards incompatible changes that require a major release number change? I'd prefer to keep the major number the same if possible. FWIW, I haven't seen any incompatible changes in the DBCP or Pool commits that I've reviewed. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Bug in previousIndex() in ArrayListIterator, ObjectArrayListIterator?
I just noticed that ArrayListIterator is marked as @since 2.2. This
should be 3.0, right (i.e. 2.2 was never released)?
One way to fix the problem (assuming that others agree that it is a
problem ;-) involves changing the way that ArrayIterator (which is
@since 1.0) internally manages its protected index field. The changes
would result in no difference in behavior for ArrayIterator's public
methods, but since index is protected, users who have subclassed
ArrayIterator could conceivably be impacted. What is the policy on these
kinds of changes? Would this count as an incompatible change?
Phil
Phil Steitz wrote:
Sorry. Forgot the prefix...
Phil Steitz wrote:
If an ArrayListIterator or ObjectArrayListIterator is constructed from
an array with an offset, the internal index is initialized and
maintained relative to the array offset. For example, if we create a
ListIterator like so:
Object[] objArray = {a, b, c, d};
ListIterator iterator = IteratorUtils.arrayListIterator(objArray, 3);
iterator.previousIndex() returns 2 if called immediatly. On the other
hand, iterator.hasPrevious() returns false in this case. This seems
inconsistent with the ListIterator API.
I think that when the ListIterator is constructed, previousIndex
should return -1 and it should be maintained relative the the
visible portion of the underlying array, so that the ListIterator
acts just like a ListIterator formed using a copy of the subarray.
Any reason not to change this?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[resources] Messages.getMessage() methods
The Messages class carries over a bunch of getMessage() methods from Struts. These methods take a varying number of replacement args from 1-4 and then an Object[]. I'd like to remove these methods except for the versions that take an array and one single replacement argument. This will simplify the interface and implementation of the class. I'll take care of this if there are no objections. David __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
So why don't we create a [convert] in the sandbox to play with the ideas here? (Maybe its a lack of hours in the day) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] On Sun, 28 Sep 2003, Sgarlata Matt wrote: Robert, thanks for pointing out that these issues have been discussed before. Here are the two threads I could find: http://www.mail-archive.com/[EMAIL PROTECTED]/msg17188.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg05085.html Hen, let me be honest and say I'm not quite sure I understand all your ideas regarding registries, but it sounds like a different approach to the same problems discussed in the first thread above, right? Yep. One of my options was to use the first one, where you have a specialised Converter class. However this is a bit of a hack and really the internals of ConvertUtils should just move from 1 dimensional to 2 dimensional. The idea I was tending towards would have ConvertUtils use 'ConverterSet's internally. For the second email, Stephen and I have remakred to each other before about the desire to get convert-utils more usable by other projects. All, it sounds like there is interest in improving ConvertUtils. Before we discuss *how* we are going to improve it, let's discuss *what* we want to improve. From what I can tell these are the deficiencies that have been identified so far: - Converters must be registered for each type, and subtypes do not inherit converters. In one of the threads above someone mentioned this is particular a problem when dealing with Enumerations. Yep. One of the problems here is how to define the inheritence lookup policy. Effectively we have the multiple inheritence problem. I've a ClassMap class that I use for these kinds of things, but it imposes a certain lookup policy and is not generic. - (I'm not as sure about this) ConvertUtils only allows a single set of conversion rules to exist, since it is a static class. It would be good if different conversions could be defined for different circumstances. Kind of. If you dig into the code enough, you can lug ConvertUtilsBeans and ConvertUtils around a bit I think, but it doesn't look like a simple, easy to do piece of code. It needs to be much easier. Can anyone think of any others? Need lots more in the way of standard converters. Not all standard converters need be defaults. Need a wrapper for convert utils that provides a configuration system so people are not always building their own structures. This should not be mandatory however. Needs to still fit BeanUtils' needs. Collection converters need to support internal Converters. ie) might want to turn an ArrayList of Person into an ArrayList of String. Perhaps? :) 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: [Chain] ChainServlet first draft
Hmm, looks like the list doesn't like .java. Trying to attach as .zip... - Original Message - From: Sgarlata Matt [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, September 28, 2003 5:28 PM Subject: [Chain] ChainServlet first draft Attached is a first cut at creating a ChainServlet. Committers, please feel free to add this to CVS (you'll need to add the license, version #s, and change the package declaration), to modify it, or to tell me what to do to modify it (and I will do so). Craig, you mentioned something about merging or inheriting catalog definitions earlier. I think this is a property that automatically emerges from how you set up the ConfigRuleSet. I take advantage of this behavior in the ChainServlet. The ChainServlet reads an XML file and stores a Catalog in a servlet context attribute. If there is already a catalog there, the two catalogs are merged. If the two catalogs have commands with the same name, the command from the new catalog takes the place of the command that was in the old catalog. One note that is not in the javadoc is that you can set up multiple chain servlets if you have multiple catalogs. Perhaps this would be better in the package documentation for whatever package the ChainServlet ends up in? Finally, some code was copied from ConfigParser, so I put Craig in the @author list. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ChainServlet.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [digester] Proposal to change Rules interface to return ListIterator for matches
On Mon, 2003-09-29 at 03:40, robert burrell donkin wrote: On Saturday, September 27, 2003, at 06:43 PM, Craig R. McClanahan wrote: Simon Kitching wrote: Hi, The current Rules interface defines public List match(String uri, String patern); This is giving me significant problems for the Plugins module I am working on. I also think it is simply the wrong type to be returning here; a List has many operations available on it which are not appropriate in this situation. I would like to suggest that the following method be added to the Rules interface, and the matches methods be deprecated: public ListIterator iterator(String uri, String pattern); This seems to me to encapsulate the goal of the existing matches method: to provide access to the set of Rule objects matching the criteria. [I'm flexible on the method name ;-] I'm OK with the concept of returning an iterator from a Rules implementation, but would suggest (if we do it) that the signature say Iterator instead of ListIterator (the implementation in RulesBase can, of course, return a ListIterator if it wants to). We'd certainly need to keep the existing match() signature around for backwards compatibility. Adding methods to interfaces is also a nasty thing to do, but I suspect most people will be extending RulesBase already. i'm not so sure about that. when i developed the RegexRules i discovered that when creating a very different implementation, RulesBase is unsuitable. (that's why i added AbstractRulesImpl.) if we are thinking about changing Rules yet again then it seems to me that we should consider whether making this class an interface was the correct design decision in the first place. if Rules had been an abstract class then it would have been very easy to make the change suggested by simon without breaking compatibility. maybe it should be an abstract class. we could think about deprecating Rules in favour of an abstract class (AbstractMatchingRules or something). getRules and setRules would be deprecated but would continue to be supported via wrappers. we could add getMatchingRules and setMatchingRules methods which take instances of the abstract class. i'd prefer to go down this route (if possible) since it would not only preserve backward compatibility but also allow more flexible modifications to be made in the future. - robert Well, I just want to note that the original reason I raised the possibility of returning ListIterator for matches was to resolve a problem I had with implementing a Plugins module. I have since had an epiphany :-) and have found a promising solution to my problem that hopefully will not require any change to the way Digester works. So from my point of view, I hopefully don't *need* any change to Digester at the moment. FYI: the problem I am struggling with is being able to add rules to the set of matches for a particular element after Digester's startElement method has begun iterating over the set of matching rules. eg given that pattern foo/bar matches 2 rules: a PluginCreateRule, and a SetNextRule, when the PluginCreateRule fires, new rules such as a SetPropertiesRule may need to be added to the rules associated with that same foo/bar pattern. The possible solution I have come up with is to *not* add rules matching the current pattern to the Digester, but instead have the PluginCreateRule object record these rules, and fire them from its begin(), body() and end() methods. Regards, Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CollectionUtils.index() behavior
I can't think of a good alternate name. Maybe getIndex() on CollectionUtils? Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] Stephen Colebourne wrote: I don't have as strong reservations as you. I would suggest that the test should assume that the iterator order of a Collection/Map remains constant so long as no new elements are added. Sure its not in the interface, but its generally true. I see this method as being one we wouldn't allow into [collections] now, but as we have it we must keep it. So its about making it as good as possible. Not ideal, but thats history for you :-( OK, but do you still feel that the improved index(Object, int) belongs in IteratorUtils and not CollectionUtils? I guess the name would have to be changed if it is left in CollectionUtils... Phil Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: from:Phil Steitz [EMAIL PROTECTED] Certainly better than the current method. In the case of a Map, by the matching element, which do you mean a) the nth element of the keySet (like now) b) the nth Map.Entry of the entrySet (best, IMHO) or c) the value of the nth entry of the entrySet? (b) seems best. Stephen I started work on this, but I am hesitating for three reasons: 1) My initial reservations about the index method being applied to unordered maps/collections. The test cases can only check that index(obj, index) returns an element of obj. Strictly speaking, we cannot even guarantee that calling index(obj, index) in a loop will effectively iterate the map/collection, or that if i and j are distinct, index(obj, i) will be different from index(obj, j). Both of these require assumptions about consistency in iterator order that are not part of the Map or Collection interface contracts. All of this points to the inappropriateness of the API for these kinds of objects, IMO. 2) I am not sure that this method fits in IteratorUtils. 3) Essentially the same functionality is available by using the IteratorUtils getIterator and toList methods (with the exception that for a Map, getIterator returns an iterator over the values in the map, rather than the entrySet). I suggest therefore that we deprecate the index methods in CollectionUtils and that we do not replace them. Phil - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Chain] CommandAction
Looks like .zip is needed to attach things... - Original Message - From: Sgarlata Matt [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, September 28, 2003 5:30 PM Subject: [Chain] CommandAction To do testing for the ChainServlet I was using Struts and set up my own CommandAction which I think is rather nice. As you might have guessed, you use it like this: action path=/chainTest type=com.bah.krm.actions.CommandAction parameter=SaveAsset forward name=success path=/test.jsp/ /action where SaveAsset is the name of a command stored in the catalog initialized by the ChainServlet. If the command executes successfully, the user is sent to the success forward. Otherwise, Struts' error-handling mechanisms take over. Do you think this Action could find a home somewhere? I am attaching the Action in case you want to take a look. It will not compile outside my application framework. If you like it, I will clean it up, remove dependencies on my application framework, add documentation, and change the coding conventions. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] CommandAction.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23469] New: - [Chain] [PATCH] CatalogBase improvements
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=23469. 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=23469 [Chain] [PATCH] CatalogBase improvements Summary: [Chain] [PATCH] CatalogBase improvements Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Sandbox AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Added JavaDoc and a toString() method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/codegen/org/apache/commons/primitive/collection XXXCollection.vm
scolebourne2003/09/28 16:07:31
Modified:primitives/src/codegen/org/apache/commons/primitive/collection
XXXCollection.vm
Log:
Tighten contract from testing
Revision ChangesPath
1.3 +4 -4
jakarta-commons-sandbox/primitives/src/codegen/org/apache/commons/primitive/collection/XXXCollection.vm
Index: XXXCollection.vm
===
RCS file:
/home/cvs/jakarta-commons-sandbox/primitives/src/codegen/org/apache/commons/primitive/collection/XXXCollection.vm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- XXXCollection.vm 22 Sep 2003 23:54:09 - 1.2
+++ XXXCollection.vm 28 Sep 2003 23:07:31 - 1.3
@@ -58,13 +58,13 @@
* p
* If the array specified is null a new array is created.
* If the array specified is large enough, it will be modified.
- * If the array is not large enough, a new array will be created and all
- * elements copied before the copy begins.
+ * If the array is not large enough, a new array will be created containing the
+ * values from the specified array before the startIndex plus those from this
collection.
*
* @param array the array to add the elements to
* @param startIndex the position in the array to start setting elements
* @return the array with the populated collection
- * @throws IndexOutOfBoundsException if the index is invalid
+ * @throws IndexOutOfBoundsException if the index is negative
*/
${type}[] toValueArray(${type}[] array, int startIndex);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23469] - [Chain] [PATCH] CatalogBase improvements
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=23469. 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=23469 [Chain] [PATCH] CatalogBase improvements --- Additional Comments From [EMAIL PROTECTED] 2003-09-28 23:10 --- Created an attachment (id=8383) Patch for CatalogBase that adds JavaDoc and a toString method - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23469] - [Chain] [PATCH] CatalogBase improvements
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=23469. 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=23469 [Chain] [PATCH] CatalogBase improvements [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/codegen/org/apache/commons/primitive/collection/impl - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/codegen/org/apache/commons/primitive/collection/impl - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/collection/impl - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/collection/impl - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/test/org/apache - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/test/org/apache - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/test/org/apache/commons/primitive - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/test/org/apache/commons/primitive - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/test/org/apache/commons/primitive/collection/impl - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/test/org/apache/commons/primitive/collection/impl - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/test/org/apache/commons - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/test/org/apache/commons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/test/org/apache/commons/primitive/collection - New directory
scolebourne2003/09/28 16:09:40 jakarta-commons-sandbox/primitives/src/test/org/apache/commons/primitive/collection - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/primitives/src/codegen/org/apache/commons/primitive/collection/impl ArrayXXXCollection.vm AbstractXXXCollection.vm
scolebourne2003/09/28 16:09:55 Modified:primitives/src/java/org/apache/commons/primitive/list LongList.java CharList.java DoubleList.java ByteList.java BooleanList.java ShortList.java FloatList.java IntList.java primitives/src/java/org/apache/commons/primitive/collection LongCollection.java ShortCollection.java DoubleCollection.java FloatCollection.java BooleanCollection.java IntCollection.java ByteCollection.java CharCollection.java primitives/src/java/org/apache/commons/primitive/iterator ShortIterator.java ByteIterator.java FloatIterator.java LongIterator.java BooleanIterator.java DoubleIterator.java CharIterator.java IntIterator.java primitives/src/java/org/apache/commons/primitive/listiterator BooleanListIterator.java LongListIterator.java DoubleListIterator.java FloatListIterator.java ShortListIterator.java CharListIterator.java ByteListIterator.java IntListIterator.java primitives/src/java/org/apache/commons/primitive/iterator/impl ArrayDoubleIterator.java ArrayIntIterator.java ArrayFloatIterator.java ArrayCharIterator.java ArrayLongIterator.java ArrayBooleanIterator.java ArrayByteIterator.java ArrayShortIterator.java primitives/src/codegen/org/apache/commons/primitive CodeGenerator.java Added: primitives/src/java/org/apache/commons/primitive BooleanUtils.java FloatUtils.java IntUtils.java LongUtils.java CharUtils.java DoubleUtils.java ByteUtils.java ShortUtils.java primitives/src/java/org/apache/commons/primitive/collection/impl ArrayCharCollection.java AbstractPrimitiveCollectable.java AbstractFloatCollection.java ArrayByteCollection.java ArrayIntCollection.java AbstractShortCollection.java ArrayBooleanCollection.java AbstractByteCollection.java ArrayShortCollection.java AbstractCharCollection.java ArrayFloatCollection.java AbstractIntCollection.java ArrayDoubleCollection.java ArrayLongCollection.java AbstractDoubleCollection.java AbstractBooleanCollection.java AbstractLongCollection.java primitives/src/test/org/apache/commons/primitive/collection/impl TestIntCollection.java TestArrayIntCollection.java primitives/src/codegen/org/apache/commons/primitive/collection/impl ArrayXXXCollection.vm AbstractXXXCollection.vm Log: Add collection implementation Update generated code Revision ChangesPath 1.3 +0 -0 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/LongList.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/LongList.java.diff?r1=1.2r2=1.3 1.3 +0 -0 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/CharList.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/CharList.java.diff?r1=1.2r2=1.3 1.3 +0 -0 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/DoubleList.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/DoubleList.java.diff?r1=1.2r2=1.3 1.3 +0 -0 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/ByteList.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/ByteList.java.diff?r1=1.2r2=1.3 1.3 +0 -0 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/BooleanList.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/BooleanList.java.diff?r1=1.2r2=1.3 1.3 +0 -0 jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/ShortList.java http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/primitives/src/java/org/apache/commons/primitive/list/ShortList.java.diff?r1=1.2r2=1.3 1.3 +0 -0
Re: [beanutils] some ideas
Sgarlata Matt wrote: - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, September 28, 2003 4:43 PM Subject: Re: [beanutils] some ideas - Converters must be registered for each type, and subtypes do not inherit converters. In one of the threads above someone mentioned this is particular a problem when dealing with Enumerations. Yep. One of the problems here is how to define the inheritence lookup policy. Effectively we have the multiple inheritence problem. I suggest we adopt a simple solution: the match is determined by the order in which converters are registered. However, perhaps we should define a Go4 Strategy of which this is only one pluggable implementation. An alternative (and one we'll likely end up with for finding appropriate Converters in JavaServer Faces) is to first look for an exact match (i.e. a Converter registered for this exact class); if not found, then walk up the inheritance hierarchy until you find one. You have to decide how to order the lookup for parent classes versus interfaces implemented by those classes, but it probably doesn't matter much as long as the algorithm is well defined. I've a ClassMap class that I use for these kinds of things, but it imposes a certain lookup policy and is not generic. - (I'm not as sure about this) ConvertUtils only allows a single set of conversion rules to exist, since it is a static class. It would be good if different conversions could be defined for different circumstances. Kind of. If you dig into the code enough, you can lug ConvertUtilsBeans and ConvertUtils around a bit I think, but it doesn't look like a simple, easy to do piece of code. It needs to be much easier. I figured the indirection to a non-static Bean was done for some reason, I just hadn't finished thinking it through :) Can anyone think of any others? Need lots more in the way of standard converters. Not all standard converters need be defaults. FormatConverter is an obvious one to include, it taking a java.text.Format in its constructor. Need a wrapper for convert utils that provides a configuration system so people are not always building their own structures. This should not be mandatory however. What would such a system be used for? You mean something more sophisticated than the ConvertUtils.register method? What would it do? Needs to still fit BeanUtils' needs. Collection converters need to support internal Converters. ie) might want to turn an ArrayList of Person into an ArrayList of String. Perhaps? :) Very cool! I expect we could do this for any Collection and for Arrays as well. Hen Matt Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][DBCP] Release Plan for Commons-DBCP 2.0
Dirk, I thought I'd link to the change since it was useful for me to review: http://cvs.apache.org/viewcvs.cgi/jakarta-commons/dbcp/release_notes.txt My vote: +1 Version # preference: 1.1 Comment: I saw mention in STATUS.html of an integration document for DBCP and Avalon... I created a service in the James 2.2.x (not yet final release) that wraps DBCP into Avalon's datasource. I don't have much time to write up docs but would suggest at least pointing to that code. http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/util/dbcp/ -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Dirk Verbeeck wrote: I'd like to propose a vote on the following release plan for DBCP 2.0. This release plan can also be found at: http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/RELEASE_PLAN_2_0.txt Per the Jakarta/ASF guidelines (see http://jakarta.apache.org/site/decisions.html), this release plan must be approved via a lazy majority vote. The voting period will end at 23:59:59 GMT on 1 October 2003 or when a clear majority has been established, whichever comes first. Here's your ballot: Please return this portion with your vote [ ] +1I am in favor of this plan and I will help [ ] +0I am in favor of this plan, but I am unable to help [ ] -0I am not in favor of this plan [ ] -1I am opposed to this plan being executed, and my reason is: /Please return this portion with your vote I'll volunteer to be the release manager for this release, but if someone else wants to, feel free to volunteer. - Dirk Verbeeck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Chain] ChainServlet first draft
I can try this tomorrow, and look at the other patches as well. In the future, the thing to do in the future is to attach the file to a Bugzilla ticket as an enhancement request. It's also helpful to include the license http://apache.org/LICENSE so that your intentions are crystal clear and so that your contribution is as ready to commit as you can possibly make it. If you don't have a Contributor's License Agreement on file with the ASF, http://jakarta.apache.org/site/agreement.html you should do that, and let us know. -Ted. Sgarlata Matt wrote: Hmm, looks like the list doesn't like .java. Trying to attach as .zip... - Original Message - From: Sgarlata Matt [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, September 28, 2003 5:28 PM Subject: [Chain] ChainServlet first draft Attached is a first cut at creating a ChainServlet. Committers, please feel free to add this to CVS (you'll need to add the license, version #s, and change the package declaration), to modify it, or to tell me what to do to modify it (and I will do so). Craig, you mentioned something about merging or inheriting catalog definitions earlier. I think this is a property that automatically emerges from how you set up the ConfigRuleSet. I take advantage of this behavior in the ChainServlet. The ChainServlet reads an XML file and stores a Catalog in a servlet context attribute. If there is already a catalog there, the two catalogs are merged. If the two catalogs have commands with the same name, the command from the new catalog takes the place of the command that was in the old catalog. One note that is not in the javadoc is that you can set up multiple chain servlets if you have multiple catalogs. Perhaps this would be better in the package documentation for whatever package the ChainServlet ends up in? Finally, some code was copied from ConfigParser, so I put Craig in the @author list. Matt - 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] -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. Get Ready, We're Moving Out!! - http://www.clark04.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections IteratorUtils.java
psteitz 2003/09/28 20:38:44
Modified:collections/src/java/org/apache/commons/collections
IteratorUtils.java
Log:
javadoc
Revision ChangesPath
1.12 +8 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/IteratorUtils.java
Index: IteratorUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/IteratorUtils.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- IteratorUtils.java31 Aug 2003 17:26:43 - 1.11
+++ IteratorUtils.java29 Sep 2003 03:38:44 - 1.12
@@ -98,6 +98,7 @@
* @version $Revision$ $Date$
*
* @author Stephen Colebourne
+ * @author Phil Steitz
*/
public class IteratorUtils {
// validation is done in this class in certain cases because the
@@ -206,7 +207,8 @@
* @param array the array over which to iterate
* @param start the index to start iterating at
* @return an iterator over part of the array
- * @throws IndexOutOfBoundsException if start is less than zero
+ * @throws IndexOutOfBoundsException if start is less than zero or greater
+ * than the length of the array
* @throws NullPointerException if array is null
*/
public static ResetableIterator arrayIterator(Object[] array, int start) {
@@ -223,7 +225,8 @@
* @param start the index to start iterating at
* @return an iterator over part of the array
* @throws IllegalArgumentException if the array is not an array
- * @throws IndexOutOfBoundsException if start is less than zero
+ * @throws IndexOutOfBoundsException if start is less than zero or greater
+ * than the length of the array
* @throws NullPointerException if array is null
*/
public static ResetableIterator arrayIterator(Object array, int start) {
@@ -579,7 +582,7 @@
* that will remove elements from the specified collection.
*
* @param enumeration the enumeration to use
- * @param collection the collection to remove elements form
+ * @param removeCollection the collection to remove elements form
*/
public static Iterator asIterator(Enumeration enumeration, Collection
removeCollection) {
if (enumeration == null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections TestIteratorUtils.java
psteitz 2003/09/28 20:56:12
Modified:collections/src/java/org/apache/commons/collections/iterators
ObjectArrayIterator.java
ObjectArrayListIterator.java ArrayListIterator.java
collections/src/test/org/apache/commons/collections
TestIteratorUtils.java
Log:
Fixed previousIndex() and nextIndex() methods in ArrayListIterator and
ObjectArrayListIterator to conform to ListIterator interface specification.
Modified ObjectArrayIterator constructor to throw ArrayOutOfBoundsException when
start index is out of range (as advertised).
Added test cases to TestIteratorUtils.
Revision ChangesPath
1.7 +7 -3
jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ObjectArrayIterator.java
Index: ObjectArrayIterator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ObjectArrayIterator.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ObjectArrayIterator.java 31 Aug 2003 17:25:49 - 1.6
+++ ObjectArrayIterator.java 29 Sep 2003 03:56:12 - 1.7
@@ -60,7 +60,7 @@
import java.util.NoSuchElementException;
/**
- * An [EMAIL PROTECTED] Iterator Iterator} over an array of objects.
+ * An [EMAIL PROTECTED] Iterator} over an array of objects.
* p
* This iterator does not support [EMAIL PROTECTED] #remove}, as the object array
cannot be
* structurally modified.
@@ -76,6 +76,7 @@
* @author a href=mailto:[EMAIL PROTECTED]Michael A. Smith/a
* @author a href=mailto:[EMAIL PROTECTED]Neil O'Toole/a
* @author Stephen Colebourne
+ * @author Phil Steitz
*/
public class ObjectArrayIterator implements ResetableIterator {
@@ -140,6 +141,9 @@
}
if (end array.length) {
throw new ArrayIndexOutOfBoundsException(End index must not be greater
than the array length);
+}
+if (start array.length) {
+throw new ArrayIndexOutOfBoundsException(Start index must not be
greater than the array length);
}
if (end start) {
throw new IllegalArgumentException(End index must not be less than
start index);
1.7 +6 -5
jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ObjectArrayListIterator.java
Index: ObjectArrayListIterator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ObjectArrayListIterator.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ObjectArrayListIterator.java 31 Aug 2003 17:25:49 - 1.6
+++ ObjectArrayListIterator.java 29 Sep 2003 03:56:12 - 1.7
@@ -60,7 +60,7 @@
import java.util.NoSuchElementException;
/**
- * Implements a [EMAIL PROTECTED] ListIterator ListIterator} over an array of
objects.
+ * Implements a [EMAIL PROTECTED] ListIterator} over an array of objects.
* p
* This iterator does not support [EMAIL PROTECTED] #add} or [EMAIL PROTECTED]
#remove}, as the object array
* cannot be structurally modified. The [EMAIL PROTECTED] #set} method is supported
however.
@@ -77,6 +77,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Neil O'Toole/a
* @author Stephen Colebourne
+ * @author Phil Steitz
*/
public class ObjectArrayListIterator extends ObjectArrayIterator implements
ResetableListIterator {
@@ -183,7 +184,7 @@
* @return the index of the item to be retrieved next
*/
public int nextIndex() {
-return this.index;
+return this.index - this.startIndex;
}
/**
@@ -192,7 +193,7 @@
* @return the index of the item to be retrieved next
*/
public int previousIndex() {
-return this.index - 1;
+return this.index - this.startIndex - 1;
}
/**
1.5 +5 -4
jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ArrayListIterator.java
Index: ArrayListIterator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/iterators/ArrayListIterator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ArrayListIterator.java31 Aug 2003 17:25:49 - 1.4
+++ ArrayListIterator.java29 Sep 2003 03:56:12 - 1.5
@@ -81,6 +81,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED]Neil O'Toole/a
* @author Stephen Colebourne
+ * @author Phil Steitz
*/
public class ArrayListIterator extends ArrayIterator implements
Re: [collections] Bug in previousIndex() in ArrayListIterator, ObjectArrayListIterator?
Stephen Colebourne wrote:
Basically, anything that people might have relied on (public/protected) is a
backwards compatable issue. However, if it is a bug fix, then the change can
be justified.
I made the change without modifying ArrayIterator, so there should be no
compatability issue.
Your changes sound OK by description, but I haven't looked at the code. My
view is that if List.listIterator(3).previousIndex() == -1 then so should
we.
Stephen
- Original Message -
From: Phil Steitz [EMAIL PROTECTED]
I just noticed that ArrayListIterator is marked as @since 2.2. This
should be 3.0, right (i.e. 2.2 was never released)?
One way to fix the problem (assuming that others agree that it is a
problem ;-) involves changing the way that ArrayIterator (which is
@since 1.0) internally manages its protected index field. The changes
would result in no difference in behavior for ArrayIterator's public
methods, but since index is protected, users who have subclassed
ArrayIterator could conceivably be impacted. What is the policy on these
kinds of changes? Would this count as an incompatible change?
Phil
Phil Steitz wrote:
Sorry. Forgot the prefix...
Phil Steitz wrote:
If an ArrayListIterator or ObjectArrayListIterator is constructed from
an array with an offset, the internal index is initialized and
maintained relative to the array offset. For example, if we create a
ListIterator like so:
Object[] objArray = {a, b, c, d};
ListIterator iterator = IteratorUtils.arrayListIterator(objArray, 3);
iterator.previousIndex() returns 2 if called immediatly. On the other
hand, iterator.hasPrevious() returns false in this case. This seems
inconsistent with the ListIterator API.
I think that when the ListIterator is constructed, previousIndex
should return -1 and it should be maintained relative the the
visible portion of the underlying array, so that the ListIterator
acts just like a ListIterator formed using a copy of the subarray.
Any reason not to change this?
Phil
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] CollectionUtils.index() behavior
I don't understand why we are obligated to keep _any_ method. If we don't like it, why not deprecate it for 3.0 and remove in 4.0? I hear a lot of this in commons, that things can't be changed or removed due to backwards compatibility. I think it's unfortunate that methods and concepts defined in a 2.0 version of a component must live on for its entire life, no matter how outdated or inconsistent they are. Isn't this what major-numbered releases are for? To make revolutionary changes when needed? I think a more aggressive attitude toward change, when necessary, can be of great benefit to not only the component itself, but also the users, if we can get past the momentary annoyance of change. I may be naive, but I still think that change can be good. Stephen Colebourne wrote: I don't have as strong reservations as you. I would suggest that the test should assume that the iterator order of a Collection/Map remains constant so long as no new elements are added. Sure its not in the interface, but its generally true. I see this method as being one we wouldn't allow into [collections] now, but as we have it we must keep it. So its about making it as good as possible. Not ideal, but thats history for you :-( Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: from:Phil Steitz [EMAIL PROTECTED] Certainly better than the current method. In the case of a Map, by the matching element, which do you mean a) the nth element of the keySet (like now) b) the nth Map.Entry of the entrySet (best, IMHO) or c) the value of the nth entry of the entrySet? (b) seems best. Stephen I started work on this, but I am hesitating for three reasons: 1) My initial reservations about the index method being applied to unordered maps/collections. The test cases can only check that index(obj, index) returns an element of obj. Strictly speaking, we cannot even guarantee that calling index(obj, index) in a loop will effectively iterate the map/collection, or that if i and j are distinct, index(obj, i) will be different from index(obj, j). Both of these require assumptions about consistency in iterator order that are not part of the Map or Collection interface contracts. All of this points to the inappropriateness of the API for these kinds of objects, IMO. 2) I am not sure that this method fits in IteratorUtils. 3) Essentially the same functionality is available by using the IteratorUtils getIterator and toList methods (with the exception that for a Map, getIterator returns an iterator over the values in the map, rather than the entrySet). I suggest therefore that we deprecate the index methods in CollectionUtils and that we do not replace them. Phil - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils project.xml
bayard 2003/09/28 21:35:46 Modified:beanutils project.xml Log: fixed typo Revision ChangesPath 1.13 +1 -1 jakarta-commons/beanutils/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/beanutils/project.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- project.xml 25 Sep 2003 20:53:02 - 1.12 +++ project.xml 29 Sep 2003 04:35:46 - 1.13 @@ -8,7 +8,7 @@ currentVersion1.7-dev/currentVersion inceptionYear2000/inceptionYear shortDescriptionCommons Bean Utils/shortDescription - descriptionJava Bean Utililities/description + descriptionJava Bean Utilities/description urlhttp://jakarta.apache.org/commons/beanutils//url developers developer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] some ideas
On Sun, 28 Sep 2003, Sgarlata Matt wrote: From: Henri Yandell [EMAIL PROTECTED] Can anyone think of any others? Something that would need deciding is what to do when the 'from' and the 'to' classes are the same. Should a String-String converter be looked for, or should it optimise it away. I suspect that there just shouldn't be any identity converters pre-registered, but people can always put them in if they wish to. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[beanutils] ArrayConverter question
Looking at the converters, there is a batch of XxxArrayConverters. These extend AbstractArrayConverter which has the code necessary to parse a comma delimited array. My question being, why does CharacterArrayConverter et al even exist? It seems that there could easily be an ArrayConverter which is created with a Converter object and optionally another Object which is the default value. If no array default, then it would return a similar array based on the value returned from the passed in converter [which might be its default]. Am I missing something? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [beanutils] ArrayConverter question
I grokk why now. Xxx is primitives, so an utter pain to deal with generically. My 'easily' below is a massive over-statement :) Still would be nice if when I change the LongConverter in a system, the default is that the LongArrayConverter also changes its atomic behaviour. Hen On Mon, 29 Sep 2003, Henri Yandell wrote: Looking at the converters, there is a batch of XxxArrayConverters. These extend AbstractArrayConverter which has the code necessary to parse a comma delimited array. My question being, why does CharacterArrayConverter et al even exist? It seems that there could easily be an ArrayConverter which is created with a Converter object and optionally another Object which is the default value. If no array default, then it would return a similar array based on the value returned from the passed in converter [which might be its default]. Am I missing something? 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]
