[GUMP@brutus]: Project commons-collections (in module jakarta-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-collections has an issue affecting its community integration. This issue affects 49 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - apache-ldapber-provider : Apache Directory Project - asn1-ber : Apache ASN.1 Tools - authx-core : Apache Authentication and Authorization Framework - authx-jdbc : Apache Authentication and Authorization Framework - avalon-dbcp-impl : Avalon SVN - avalon-jms-api : Avalon SVN - avalon-jms-impl : Avalon SVN - avalon-jms-test : Avalon SVN - commons-beanutils-bean-collections : Bean Utilities (Bean Collections) - commons-betwixt : Commons Betwixt Package - commons-chain : GoF Chain of Responsibility pattern - commons-collections : Collections - commons-collections-testframework : Jakarta commons - commons-configuration : Jakarta commons - commons-configuration-10 : Jakarta Commons Configuration 1.0 release - commons-dbcp : Database Connection Pool - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-graph : Jakarta commons sandbox - commons-messenger : A web based JMS framework - commons-modeler : Modeler MBeans - commons-pool : Object Pooling - commons-primitives : Provides a collection of types and utilities optimized for w... - commons-services : Basic Services Architecture - commons-validator : Validation Framework - commons-vfs : Jakarta commons sandbox - invicta : Open-source build management tool. - jakarta-tomcat-coyote : Connectors to various web servers - jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers - jakarta-tomcat-dbcp : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-http11 : Connectors to various web servers - jakarta-tomcat-util-coyote_10 : Connectors to various web servers - ldap-snacc-provider : Apache Directory Project - logging-log4j-chainsaw : Chainsaw log viewer - naming-config : Apache Directory Naming Component - tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation - xdoclet-bea-module-prepare : Intermediate target that prepares xdoclet's bea module - xdoclet-compile-core : Intermediate target that compiles xdoclet's core classes - xdoclet-ejb-module-prepare : Intermediate target that prepares xdoclet's ejb module - xdoclet-hibernate-module-prepare : Intermediate target that prepares xdoclet's hibernate mo... - xdoclet-jdo-module-prepare : Intermediate target that prepares xdoclet's jdo module - xdoclet-libelis-module-prepare : Intermediate target that prepares xdoclet's libelis modu... - xdoclet-objectweb-module-prepare : Intermediate target that prepares xdoclet's objectweb mo... - xdoclet-oracle-module-prepare : Intermediate target that prepares xdoclet's oracle modul... - xdoclet-orion-module-prepare : Intermediate target that prepares xdoclet's orion module - xdoclet-tjdo-module-prepare : Intermediate target that prepares xdoclet's tjdo module - xdoclet-web-module-prepare : Intermediate target that prepares xdoclet's web module - xdoclet-xdoclet-module-prepare : Intermediate target that prepares xdoclet's xdoclet modu... - xjavadoc : Enhanced Doclet engine. Full details are available at: http://brutus.apache.org/gump/public/jakarta-commons/commons-collections/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-collections-24032005.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://brutus.apache.org/gump/public/jakarta-commons/commons-collections/gump_work/build_jakarta-commons_commons-collections.html Work Name: build_jakarta-commons_commons-collections (Type: Build) Work ended in a state of : Failed Elapsed: 41 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcomponent.version=24032005 dist [Working Directory: /usr/local/gump/public/workspace/jakarta-commons/collections] CLASSPATH:
Re: [Jelly] broken link in tutorial
http://issues.apache.org/jira/browse/JELLY as given in the website. paul Le 24 mars 05, à 06:22, A Leg a écrit : Hi Paul It can sound stupid but I don't know how to submit an issue. Can you guide me or point to a guide? Andre Paul Libbrecht wrote: Dear Andre, can you submit an issue for this and the other doc break you are experiencing ? thank you paul Le 23 mars 05, à 08:01, A Leg a écrit : Hi When reading the tutorial page : tutorial.html#jellyswing When you click on link to get the jelley-swing code demo http://cvs.apache.org/viewcvs.cgi/jakarta-commons/jelly/src/test/ org/ apache/commons/jelly/tags/swing/example.jelly?rev=HEADcontent- type=text/vnd.viewcvs-markup you get : An Exception Has Occurred jakarta-commons/jelly/src/test/org/apache/commons/jelly/tags/swing/ example.jelly: unknown location HTTP Response Status 404 Not Found - -- - Python Traceback Traceback (most recent call last): File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 3345, in main request.run_viewcvs() File /usr/local/viewcvs-1.0-dev/lib/viewcvs.py, line 292, in run_viewcvs % self.where, '404 Not Found') ViewCVSException: 404 Not Found: jakarta-commons/jelly/src/test/org/apache/commons/jelly/tags/swing/ example.jelly: unknown location Best regards Andre Legendre - 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: [net] FTP client date parsing: new format
SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Steve Cohen wrote: Wow! Thanks for showing us this. That's a format I've not seen before. Where did it come from? Is it by any chance a public site? In past experience, all unix ftp servers, which I presume this to be, have used abbreviations for the months. There IS a new system in the latest version of commons-net that would allow you to specify an alternate date format. I consider this a nice validation of the new design - it offers a way to work with a format we didn't even know existed. It's not hooked up to ant yet but that was always my intent. What say, other commons-net committers? Are we ready to build 1.4? Then I could add hooks for this new system in Ant. Steve Cohen Neeme Praks wrote: Hi all! Attached is a sample directory listing that breaks the 1.3.0 commons-net FTP client directory parsing, at least when used from Ant task. The basic difference is that the dates are specified as numbers (2005-03-21 14:26), not as month names. I saw on the mailing list that there is now a possibility to use custom date parsers, but I'm not sure how well that would mix with the Ant ftp task. Or maybe there is already a fix for this in CVS and I can just build from CVS? Thanks, Neeme ftp ls -l 200 PORT command successful. 150 Opening ASCII mode data connection for '/bin/ls'. total 356 -rw-r--r-- 1 inpoc inpoc 385 2005-03-21 14:26 about.vsp -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:26 animations.vsp -rw-r--r-- 1 inpoc inpoc 778 2005-03-21 14:27 animations.wap.vsp -rw-r- 1 inpoc inpoc 365 2005-03-21 14:27 animations.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 bite.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 biterus.inpoc.lt -rw-r--r-- 1 inpoc inpoc 198 2005-03-21 14:27 crossdomain.xml -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 dynamic_sms.vsp -rw-r--r-- 1 inpoc inpoc 1088 2005-03-21 14:27 dynamic_sms.wap.vsp -rw-r- 1 inpoc inpoc 355 2005-03-21 14:27 dynamic_sms.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgo.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgorus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-21 12:44 face.inpoc.lv drwxr-xr-x 4 inpoc inpoc 4096 2004-10-21 14:45 flash lrwxrwxrwx 1 inpoc inpoc28 2005-03-02 18:06 gfx - ../../www.inpoc.no/ROOT/gfx/ drwxr-xr-x 2 inpoc inpoc 4096 2004-10-27 14:11 gfx.wap lrwxrwxrwx 1 inpoc inpoc26 2005-03-02 18:06 globalgfx - ../../../global/globalgfx/ lrwxrwxrwx 1 inpoc inpoc31 2005-03-02 18:06 globalincludes - ../../../global/globalincludes/ drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.lt drwxr-xr-x 2 inpoc inpoc 4096 2004-09-08 23:09 hei.inpoc.ee -rw-r--r-- 1 inpoc inpoc 381 2005-03-21 14:27 help.vsp -rw-r--r-- 1 inpoc inpoc 2232 2005-03-21 14:27 help.wap.vsp drwxr-xr-x 2 inpoc inpoc 4096 2004-11-09 13:33 ieskok.inpoc.lt lrwxrwxrwx 1 inpoc inpoc33 2005-03-02 18:06 includes - ../../www.inpoc.no/ROOT/includes/ -rw-r--r-- 1 inpoc inpoc 412 2005-03-21 14:27 index.vsp -rw-r--r-- 1 inpoc inpoc 1027 2004-09-08 23:09 index.wap.vsp drwxrwxr-x 3 inpoc inpoc 4096 2004-12-21 16:07 inpoc.delfi.ee drwxr-xr-x 2 inpoc inpoc 4096 2004-09-24 13:45 kangazoo.inpoc.lv drwxr-x--- 11 inpoc inpoc 4096 2005-01-17 15:49 localgfx -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 logos.vsp -rw-r--r-- 1 inpoc inpoc 1081 2005-03-21 14:27 logos.wap.vsp -rw-r- 1 inpoc inpoc 351 2005-03-21 14:27 logos.web.vsp lrwxrwxrwx 1 inpoc inpoc23 2005-03-02 18:06 macros - ../../../global/macros/ -rw-r--r-- 1 inpoc inpoc38 2005-03-21 14:27 menu.vsp drwxr-xr-x 2 inpoc inpoc 4096 2004-10-20 09:56 mixfm.inpoc.lv drwxrwxr-x 2 inpoc inpoc 4096 2004-12-22 12:24 mobiil.delfi.ee -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 mobilegames.vsp -rw-r--r-- 1 inpoc inpoc 1292 2005-03-21 14:27 mobilegames.wap.vsp -rw-r- 1 inpoc inpoc 1356 2005-03-21 14:27 mobilegames.web.vsp
Re: [net] FTPclient: keeping track of dates of files on the server
Well, as I wrote in my previous email, timezone setting does help, but I would like to take it one step further. When just using plain timezone difference calculation, you are still comparing server time to the local time and those usually are out-of-sync. I would like to have it 100% precise: to compare server time to the server time and local time to local time. If you would read my original post again, maybe you would see the light :-) Rgds, Neeme P.S. It's a Mr, as usual in technology mailing lists. Nice try, though :-P Steve Cohen wrote: Spot on again, Mr. (Ms.?) Praks. And again, the latest version of CVS allows the specification of a server time zone, for precisely this reason. We need to get this released and then supported in Ant. Steve Cohen Neeme Praks wrote: Hi again! Another issue I've been thinking about. Correct me if I'm wrong but the current way that FTP client checks if the file locally is newer or not is the following: 1. it takes the time from the server 2. manipulates the time according to timezone settings 3. compares it to the time on the local file In the ideal case, when the local machine time and the server time are in sync, this scheme should work. However, we do not live in the ideal world. So usually the local time and the server time does not match. This results in four scenarios, and here is my ASCII art illustration: lf = local file |lf IS UPDATED |lf IS NOT UPDATED ---++--- timestamp shows lf | this is BAD, changes | this is OK, as there is as OLDER than the | stay on local disk | no update required file on the server | nothing is uploaded| anyway -- ++--- timestamp shows lf | this is OK, as the | this is not really bad but as NEWER than the | file has to be updated | NOT GOOD either. we will file on the server | anyway | constantly try to update || files that are already || up-to-date ---++--- Actually there is one more axis to this: if the file on the server is updated or not. But it is very similar to the case above, so I will not go into details of that issue now. Hopefully that made sense? I would like to avoid these undesirable scenarios. How to do that? By comparing apples to apples and oranges to oranges: by comparing the server timestamp to the timestamp from the same server and local timestamp to local time. In order to do this, we just need to keep a list of timestamps around somewhere, from session to session. My proposal: When FTP client does checks for timestamps, it stores the last known server and local timestamps of each file in some designated working directory. And after each upload, it updates those timestamps. Then, it can easily determine, if the file on the server has been overwritten or if the local file has been updated since the last synchronization. If the local file is unchanged and server file is unchanged - skip. If the local file is changed and server file is unchanged - upload. If the local file is unchanged and server file is changed - skip. Or, optional behaviour could be to download changes. If the local file is changed and server file is changed - upload and issue warning. Or, the default behaviour could be to just issue warning. And we could implement synchronizing file deletions also. The directory contents could look something like this: commons-net-ftp-timestamp-cache/my-ftpserver.cache - one file per unique server inside that file would be something like this: [file path] [server timestamp] [local timestamp] [file path] [server timestamp] [local timestamp] [file path] [server timestamp] [local timestamp] ... [file path] [server timestamp] [local timestamp] What do you make of all this? Does it make any sense? I would be willing to work on implementing this unless someone has some better ideas for achieving similar results. Should this actually go inside commons-net or maybe inside the Ant task instead? Rgds, Neeme - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: [net] FTPclient: keeping track of dates of files on the server
Sorry I didn't read far enough. This is more properly a discussion for the Ant list. All we handle here is the raw FTP. Ant's FTP task depends on commons-net, though, and until we release the timezone-using version of commons-net, ant will not have the tools to do what you need. I may be speaking out of turn here, but I doubt that that Ant developers will be receptive to your suggestion. The ant ftp task has been designed as a fairly simple wrapper around raw ftp. The newer attribute of the ftp task offers just a simple date-time comparison within the general dependency framework of ant. It sounds like what you are asking for is something much more, basically a version-control system. Ant supports several of these and my guess is that they will tell you to use cvs or one of the proprietary version control systems that ant supports in order to accomplish this logic. Have you considered using the cvs task of ant? I programmed one of the version-control systems that ant supports and your issues sound very familiar to me. But I could be wrong, also. If you outline your use case on the ant list, you may find more interest in supporting it than I expect. If you do, I suspect that would be implemented in a new task that perhaps sits on top of ftp, because there are still many use cases for using the ftp task as is. In any case, the timezone feature of commons-net-ftp will be part of any possible solution. Neeme Praks wrote: Well, as I wrote in my previous email, timezone setting does help, but I would like to take it one step further. When just using plain timezone difference calculation, you are still comparing server time to the local time and those usually are out-of-sync. I would like to have it 100% precise: to compare server time to the server time and local time to local time. If you would read my original post again, maybe you would see the light :-) Rgds, Neeme P.S. It's a Mr, as usual in technology mailing lists. Nice try, though :-P Steve Cohen wrote: Spot on again, Mr. (Ms.?) Praks. And again, the latest version of CVS allows the specification of a server time zone, for precisely this reason. We need to get this released and then supported in Ant. Steve Cohen Neeme Praks wrote: Hi again! Another issue I've been thinking about. Correct me if I'm wrong but the current way that FTP client checks if the file locally is newer or not is the following: 1. it takes the time from the server 2. manipulates the time according to timezone settings 3. compares it to the time on the local file In the ideal case, when the local machine time and the server time are in sync, this scheme should work. However, we do not live in the ideal world. So usually the local time and the server time does not match. This results in four scenarios, and here is my ASCII art illustration: lf = local file |lf IS UPDATED |lf IS NOT UPDATED ---++--- timestamp shows lf | this is BAD, changes | this is OK, as there is as OLDER than the | stay on local disk | no update required file on the server | nothing is uploaded| anyway -- ++--- timestamp shows lf | this is OK, as the | this is not really bad but as NEWER than the | file has to be updated | NOT GOOD either. we will file on the server | anyway | constantly try to update || files that are already || up-to-date ---++--- Actually there is one more axis to this: if the file on the server is updated or not. But it is very similar to the case above, so I will not go into details of that issue now. Hopefully that made sense? I would like to avoid these undesirable scenarios. How to do that? By comparing apples to apples and oranges to oranges: by comparing the server timestamp to the timestamp from the same server and local timestamp to local time. In order to do this, we just need to keep a list of timestamps around somewhere, from session to session. My proposal: When FTP client does checks for timestamps, it stores the last known server and local timestamps of each file in some designated working directory. And after each upload, it updates those timestamps. Then, it can easily determine, if the file on the server has been overwritten or if the local file has been updated since the last synchronization. If the local file is unchanged and server file is unchanged - skip. If the local file is changed and server file is unchanged - upload. If the local file is unchanged and server file is changed - skip. Or, optional behaviour could be to download changes. If the local file is changed and server file is changed - upload and issue warning. Or, the default behaviour could be to just issue warning. And
Re: [net] FTP client date parsing: new format
Very good news that Debian is going to an all-numeric date format. After mucking around in this mess for a couple of years, I often wondered why standard unix ftp bothered with the abbreviations at all. NT does not and does unix really want to take a back seat to NT in matters such as this? The numeric format is obviously superior. Neeme Praks wrote: This format is from the default FTP server daemon configuration that came with Debian: Connected to stf. 220 stf FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Name (stf:neeme): neeme 331 Password required for neeme. Password: 230- Linux stf 2.6.11 #1 SMP Wed Mar 2 14:08:21 CET 2005 i686 GNU/Linux 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User neeme logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp Rgds, Neeme Steve Cohen wrote: Wow! Thanks for showing us this. That's a format I've not seen before. Where did it come from? Is it by any chance a public site? In past experience, all unix ftp servers, which I presume this to be, have used abbreviations for the months. There IS a new system in the latest version of commons-net that would allow you to specify an alternate date format. I consider this a nice validation of the new design - it offers a way to work with a format we didn't even know existed. It's not hooked up to ant yet but that was always my intent. What say, other commons-net committers? Are we ready to build 1.4? Then I could add hooks for this new system in Ant. Steve Cohen Neeme Praks wrote: Hi all! Attached is a sample directory listing that breaks the 1.3.0 commons-net FTP client directory parsing, at least when used from Ant task. The basic difference is that the dates are specified as numbers (2005-03-21 14:26), not as month names. I saw on the mailing list that there is now a possibility to use custom date parsers, but I'm not sure how well that would mix with the Ant ftp task. Or maybe there is already a fix for this in CVS and I can just build from CVS? Thanks, Neeme ftp ls -l 200 PORT command successful. 150 Opening ASCII mode data connection for '/bin/ls'. total 356 -rw-r--r-- 1 inpoc inpoc 385 2005-03-21 14:26 about.vsp -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:26 animations.vsp -rw-r--r-- 1 inpoc inpoc 778 2005-03-21 14:27 animations.wap.vsp -rw-r- 1 inpoc inpoc 365 2005-03-21 14:27 animations.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 bite.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 biterus.inpoc.lt -rw-r--r-- 1 inpoc inpoc 198 2005-03-21 14:27 crossdomain.xml -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 dynamic_sms.vsp -rw-r--r-- 1 inpoc inpoc 1088 2005-03-21 14:27 dynamic_sms.wap.vsp -rw-r- 1 inpoc inpoc 355 2005-03-21 14:27 dynamic_sms.web.vsp drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgo.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 emtgorus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-21 12:44 face.inpoc.lv drwxr-xr-x 4 inpoc inpoc 4096 2004-10-21 14:45 flash lrwxrwxrwx 1 inpoc inpoc28 2005-03-02 18:06 gfx - ../../www.inpoc.no/ROOT/gfx/ drwxr-xr-x 2 inpoc inpoc 4096 2004-10-27 14:11 gfx.wap lrwxrwxrwx 1 inpoc inpoc26 2005-03-02 18:06 globalgfx - ../../../global/globalgfx/ lrwxrwxrwx 1 inpoc inpoc31 2005-03-02 18:06 globalincludes - ../../../global/globalincludes/ drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 golive.inpoc.lt drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.ee drwxrwxr-x 2 inpoc inpoc 4096 2005-03-08 11:12 goliverus.inpoc.lt drwxr-xr-x 2 inpoc inpoc 4096 2004-09-08 23:09 hei.inpoc.ee -rw-r--r-- 1 inpoc inpoc 381 2005-03-21 14:27 help.vsp -rw-r--r-- 1 inpoc inpoc 2232 2005-03-21 14:27 help.wap.vsp drwxr-xr-x 2 inpoc inpoc 4096 2004-11-09 13:33 ieskok.inpoc.lt lrwxrwxrwx 1 inpoc inpoc33 2005-03-02 18:06 includes - ../../www.inpoc.no/ROOT/includes/ -rw-r--r-- 1 inpoc inpoc 412 2005-03-21 14:27 index.vsp -rw-r--r-- 1 inpoc inpoc 1027 2004-09-08 23:09 index.wap.vsp drwxrwxr-x 3 inpoc inpoc 4096 2004-12-21 16:07 inpoc.delfi.ee drwxr-xr-x 2 inpoc inpoc 4096 2004-09-24 13:45 kangazoo.inpoc.lv drwxr-x--- 11 inpoc inpoc 4096 2005-01-17 15:49 localgfx -rw-r--r-- 1 inpoc inpoc27 2005-03-21 14:27 logos.vsp -rw-r--r-- 1 inpoc inpoc 1081 2005-03-21 14:27 logos.wap.vsp -rw-r- 1 inpoc inpoc 351 2005-03-21 14:27 logos.web.vsp lrwxrwxrwx 1 inpoc inpoc23 2005-03-02 18:06 macros - ../../../global/macros/ -rw-r--r-- 1 inpoc inpoc38 2005-03-21
Re: [net] FTP client date parsing: new format
Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] [VOTE] Bug 33190...
Could we come to some consensus on this item in Bugzilla? I have already put my $0.02 in as a comment. But, this one is somewhat easy either way we go with it. If the decision is to not include it, then that's a no-brainer. If we decide to include it, then it's not much effort to do that either. But, a decision has to be made. I'm -1 on including it, as I don't think it's a valid approach or all that common. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
I meant when you did the last release, of course. Steve Cohen wrote: Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - 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] [VOTE] Bug 33190...
--- James Carman [EMAIL PROTECTED] wrote: Could we come to some consensus on this item in Bugzilla? I have already put my $0.02 in as a comment. But, this one is somewhat easy either way we go with it. If the decision is to not include it, then that's a no-brainer. If we decide to include it, then it's not much effort to do that either. But, a decision has to be made. I'm -1 on including it, as I don't think it's a valid approach or all that common. Actually, I think it could be useful as a technique, if we put out of our minds the validness of the given use case. If we did include it, it would essentially be a CallClosureWhenCompleteIterator. So, I'm +0.5. However on coding matters, any -1 is a veto, so it won't happen if you -1. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTPclient: keeping track of dates of files on the server
ok, clear enough. I'll look into the source code of the ftp task and play around with it a bit. Another suggestion for that task is to allow retry-in-case-of-failure, not just abort or ignore as in the current version. But I'll take those issues up on Ant list. My use case is simple: I'm using ant ftp task to deploy Velocity scripts to several front-end machines (7 in total). And it is really annoying to change one file and to discover that instead of just uploading one file, it will upload a whole bunch of them... I actually need some more customized behaviour, so I will most probably write a separate task and see if there are any more interested parties in Ant community. Rgds, Neeme Steve Cohen wrote: Sorry I didn't read far enough. This is more properly a discussion for the Ant list. All we handle here is the raw FTP. Ant's FTP task depends on commons-net, though, and until we release the timezone-using version of commons-net, ant will not have the tools to do what you need. I may be speaking out of turn here, but I doubt that that Ant developers will be receptive to your suggestion. The ant ftp task has been designed as a fairly simple wrapper around raw ftp. The newer attribute of the ftp task offers just a simple date-time comparison within the general dependency framework of ant. It sounds like what you are asking for is something much more, basically a version-control system. Ant supports several of these and my guess is that they will tell you to use cvs or one of the proprietary version control systems that ant supports in order to accomplish this logic. Have you considered using the cvs task of ant? I programmed one of the version-control systems that ant supports and your issues sound very familiar to me. But I could be wrong, also. If you outline your use case on the ant list, you may find more interest in supporting it than I expect. If you do, I suspect that would be implemented in a new task that perhaps sits on top of ftp, because there are still many use cases for using the ftp task as is. In any case, the timezone feature of commons-net-ftp will be part of any possible solution. smime.p7s Description: S/MIME Cryptographic Signature
RE: [collections] [VOTE] Bug 33190...
Ok, then I'm a +0. I wouldn't want to veto it. I guess I should read up on the voting rules. I didn't realize that a -1 was so powerful. Then again, I'm not an official committer yet, so my vote doesn't count anyway. :-) Could we try to come up with a more valid use case, then? I don't see including something if we can't even fathom a reasonable use case for it. Off the top of my head, I can't think of a use for this technique. That doesn't mean there isn't one. Maybe I've just never encountered a situation where it would apply. It seems quite dangerous, though, to rely upon the exhaustion of an iterator to release or clean up resources. What happens if an exception is thrown while iterating? The Closure will never be called. James -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Thursday, March 24, 2005 9:04 AM To: Jakarta Commons Developers List Subject: Re: [collections] [VOTE] Bug 33190... --- James Carman [EMAIL PROTECTED] wrote: Could we come to some consensus on this item in Bugzilla? I have already put my $0.02 in as a comment. But, this one is somewhat easy either way we go with it. If the decision is to not include it, then that's a no-brainer. If we decide to include it, then it's not much effort to do that either. But, a decision has to be made. I'm -1 on including it, as I don't think it's a valid approach or all that common. Actually, I think it could be useful as a technique, if we put out of our minds the validness of the given use case. If we did include it, it would essentially be a CallClosureWhenCompleteIterator. So, I'm +0.5. However on coding matters, any -1 is a veto, so it won't happen if you -1. Stephen - 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: [net] FTP client date parsing: new format
The last release was from CVS. The docs were (are? - haven't checked) very CVS-centric. I haven't attmepted to try a release from SVN yet, however I presume it wouldn't be too arduous a task, given the ease of substitutability between CVS/SVN. I fixed the issue with missing JUnit tests - they were missing all along (my mistake), I just added them into SVN. As regards a timeline, I'm also pretty swamped over the next couple of weeks (starting a new role, etc), so it will be tight for me until then. If I do get a chance in the next couple of weeks I will look at fixing some of the more straightforward issues in BZ. It would be nice to get a release out before too long - maybe in the next 4-6 weeks, how does that sound as a rough timescale estimate? Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections] Generics/JDK 5
Hello, I was looking for a generics-capable version of commons-collections, however everything I could find were to small threads on the mailing list. Instead of complaining I decided to work on it myself. The first thing I did was creating a generics-version of the various interfaces provided by commons-collections. Now I'm seeking your advice: where should I put the changed source files, as some discussion is sorely needed? Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 32748] - [beanutils]special characters in mapped property keys are parsed incorrectly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32748. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32748 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dev@struts.apache.org |commons- ||[EMAIL PROTECTED] Component|Controller |Bean Utilities Product|Struts |Commons Summary|special characters in mapped|[beanutils]special |property keys are parsed|characters in mapped |incorrectly |property keys are parsed ||incorrectly Version|1.2.4 |unspecified --- Additional Comments From [EMAIL PROTECTED] 2005-03-24 16:29 --- This is a Commons BeanUtils issue rather than a Struts one, so I'm reassigning it there. On the issue of . characters in the keys for mapped properties, there is already an open bug in BeanUtils for it (see Bug 28813). Niall -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34165] - [configuration] CommandLineConfiguration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34165 --- Additional Comments From [EMAIL PROTECTED] 2005-03-24 17:16 --- Created an attachment (id=14554) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14554action=view) CommandLineConfiguration.java -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generics/JDK 5
http://collections15.sourceforge.net/ michael On Thu, 24 Mar 2005, Thomas Klaeger wrote: Hello, I was looking for a generics-capable version of commons-collections, however everything I could find were to small threads on the mailing list. Instead of complaining I decided to work on it myself. The first thing I did was creating a generics-version of the various interfaces provided by commons-collections. Now I'm seeking your advice: where should I put the changed source files, as some discussion is sorely needed? Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Generics/JDK 5
Hello Thomas, You're right. There was a brief discussion about a Java 5.0 port of collections. The upshot was the project that Michael has pointed out on SourceForge. There are two people working on this at the moment - myself and Mauro Franceschini. After an initial bout of work on this project, I'm afraid I've been hit by a number of personal problems over the past few months, so have virtually no time to do any work with it. Hopefully that should change soon, so I'll be able to start working on it again. If you're interested in discussing collections15 and perhaps contributing, then have a look at what's been done so far. I started by generifying them all, but as I've moved on to providing implementations of them, it's become obvious that small changes have been needed here and there. After converting all of the interfaces, I decided to start providing implementation of some of the simpler ones (basically the functor interfaces - Predicate, Closure, Transformer, Comparator, etc.). Mauro has also started work on Lists and Iterators. Any comments and/or help would be greatly appreciated. Chris Michael Heuer wrote: http://collections15.sourceforge.net/ michael On Thu, 24 Mar 2005, Thomas Klaeger wrote: Hello, I was looking for a generics-capable version of commons-collections, however everything I could find were to small threads on the mailing list. Instead of complaining I decided to work on it myself. The first thing I did was creating a generics-version of the various interfaces provided by commons-collections. Now I'm seeking your advice: where should I put the changed source files, as some discussion is sorely needed? Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch?] feedparser (organizing imports)
Matthias Wessendorf wrote: Hi Kevin, sorry for bothering you, but I started looking at sources for [feedparser] and saw lot's of import java.xxx.* and also unused importstatements. Are you interessted in structuring them? I liked the remove unused import statements patch. How did you find this out? Did you use checkstyle or something? I'm not sure about the generic import java.xxx.* removal. I prefer this style as it saves a LOT of time over worrying about which classes to import. I realize that some IDEs have support for just in time class import but I use Emacs which doesn't have that fancy feature ;) Would you be interested in separating the patches? I'd like to accept the remove unnecessary imports code. Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN][configuration]1.1RC3
After fixing a packaging issue with NOTICE.txt and a few minor updates I have created the third release candidate of the commons-configuration 1.1 release. The files are available for inspection at http://www.apache.org/~oheger/commons-configuration-1.1rc3 The name of the tag is CONFIGURATION_1_1RC3. I have also uploaded the documentation for RC3 to my home directory. It can be found at http://www.apache.org/~oheger/commons-configuration-1.1rc3-docs/ The release notes (in form of the changes report) can be found at http://www.apache.org/~oheger/commons-configuration-1.1rc3-docs/changes-report.html Comments are welcome! I plan to call for the release vote soon. Thanks, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34140] - [daemon] jsvc does not block on Linux
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34140. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34140 [EMAIL PROTECTED] changed: What|Removed |Added Summary|[commons-daemon]: jsvc does |[daemon] jsvc does not block |not block on Linux |on Linux -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34165] - [configuration] CommandLineConfiguration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34165 --- Additional Comments From [EMAIL PROTECTED] 2005-03-24 17:18 --- Created an attachment (id=14555) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14555action=view) TestCommandLineConfiguration.java -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34142] - use writeTo() instead of toByteArray in DeferredFileOutputStream.thresholdReached()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34142. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34142 --- Additional Comments From [EMAIL PROTECTED] 2005-03-23 06:49 --- I've applied the first patch. Is the second patch a fix to a bug in the first patch, or is it an enhancement? If the former, please attach a patch using the 'diff -u' format that the 'patch' utility understands; if the latter, please file a separate enhancement request (also with a 'diff -u' patch). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34142] - [io] use writeTo() instead of toByteArray in DeferredFileOutputStream.thresholdReached()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34142. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34142 [EMAIL PROTECTED] changed: What|Removed |Added Summary|use writeTo() instead of|[io] use writeTo() instead |toByteArray in |of toByteArray in |DeferredFileOutputStream.thr|DeferredFileOutputStream.thr |esholdReached() |esholdReached() -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34103] - [configuration] Inconsistent behavior
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34103. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34103 --- Additional Comments From [EMAIL PROTECTED] 2005-03-23 08:03 --- (In reply to comment #12) Do the beanutils converters really provide all features we would need? E.g. I am missing stuff like Collection - XXX array. After having slept a night over this problem I think that your suggestion could be easily implemented on top of the Configuration API. Create a new class ConverterConfiguration or whatever that may or may not be a Configuration decorator, but hold a reference to an original Configuration. In your proposed methods call the original Configuration's getProperty() method and act on the result as appropriate, e.g. perform type conversions. I would see this new class as an addition or maybe as a replacement for DataConfiguration. This would have the advantage that the core API needn't be changed and no additional dependency for a converter framework needs to be added. Users who can live with the provided standard data types just use a simple Configuration, others make use of the extended conversion features. And another word about throwing exceptions on missing properties: I am quite sure that we simply cannot change the current semantics now. If we did this, after an update to the new Configuration version a major part of the applications that use this API is likely to crash with unexpected exceptions being thrown. That won't make us any new friends... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Hi, Over on the log4j mailing list, we've been discussing an interesting idea for the next-generation commons-logging-type component, and wanted to run the idea by the commons-dev crew for feedback. This is just informal at this point, soliciting opinions. First, as background: - Jakarta Commons Logging (JCL) has some problems, as discussed in http://www.qos.ch/logging/classloader.jsp and http://marc.theaimsgroup.com/?t=11078097261 http://marc.theaimsgroup.com/?t=11078097261r=1w=2 r=1w=2 among many other problems. - The log4j team has developed UGLI (http://logging.apache.org/log4j/docs/ugli.html) to solve these problems, following a good amount of thought and discussion - UGLI is new and very few people know about it, while JCL is very familiar and widely used I (personally, not speaking for the entire log4j team here) think it would be a lot easier for UGLI to be adopted if it is essentially called JCL 2.0 or better yet, commons-logging 2.0 (CL2), taking advantage of that brand name instead of throwing a completely new and unfamiliar, yet another logging interface to the users. So I wanted to ask: what would the commons development community, especially those working on commons-logging, think of: - Move the commons-logging project out of jakarta, into its own project in Logging Services - Proactively cooperate with the log4j team, commons-logging team, and other interesting parties (e.g. Tomcat, so I'm wearing about three different hats when writing this message), to combine JCL 2.0 intended features with current UGLI features Comments? Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] / mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
Hi, Over on the log4j mailing list, weve been discussing an interesting idea for the next-generation commons-logging-type component, and wanted to run the idea by the commons-dev crew for feedback. This is just informal at this point, soliciting opinions. First, as background: - Jakarta Commons Logging (JCL) has some problems, as discussed in http://www.qos.ch/logging/classloader.jsp and http://marc.theaimsgroup.com/?t=11078097261r=1w=2 among many other places. - The log4j team has developed UGLI (http://logging.apache.org/log4j/docs/ugli.html) to solve these problems, following a good amount of thought and discussion - UGLI is new and very few people know about it, while JCL is very familiar and widely used I (personally, not speaking for the entire log4j team here) think it would be a lot easier for UGLI to be adopted if it is essentially called JCL 2.0 or better yet, commons-logging 2.0 (CL2), taking advantage of that brand name instead of throwing a completely new and unfamiliar, yet another logging interface to the users. So I wanted to ask: what would the commons development community, especially those working on commons-logging, think of: - Move the commons-logging project out of jakarta, into its own project in Logging Services - Proactively cooperate with the log4j team, commons-logging team, and other interesting parties (e.g. Tomcat, so Im wearing about three different hats when writing this message), to combine JCL 2.0 intended features with current UGLI features Comments? Yoav Shapira System Design and Management Fellow MIT Sloan School of Management / School of Engineering Cambridge, MA USA [EMAIL PROTECTED] / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r158940 - jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC3
Author: oheger Date: Thu Mar 24 11:38:52 2005 New Revision: 158940 URL: http://svn.apache.org/viewcvs?view=revrev=158940 Log: Tag for 1.1RC3 Added: jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC3/ - copied from r158939, jakarta/commons/proper/configuration/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Idea: combine JCL 2.0 and UGLI in Logging Services' CL2
On Thu, 24 Mar 2005 14:37:28 -0500, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, Over on the log4j mailing list, we've been discussing an interesting idea for the next-generation commons-logging-type component, and wanted to run the idea by the commons-dev crew for feedback. This is just informal at this point, soliciting opinions. First, as background: - Jakarta Commons Logging (JCL) has some problems, as discussed in http://www.qos.ch/logging/classloader.jsp and http://marc.theaimsgroup.com/?t=11078097261 http://marc.theaimsgroup.com/?t=11078097261r=1w=2 r=1w=2 among many other problems. - The log4j team has developed UGLI (http://logging.apache.org/log4j/docs/ugli.html) to solve these problems, following a good amount of thought and discussion - UGLI is new and very few people know about it, while JCL is very familiar and widely used I (personally, not speaking for the entire log4j team here) think it would be a lot easier for UGLI to be adopted if it is essentially called JCL 2.0 or better yet, commons-logging 2.0 (CL2), taking advantage of that brand name instead of throwing a completely new and unfamiliar, yet another logging interface to the users. So I wanted to ask: what would the commons development community, especially those working on commons-logging, think of: - Move the commons-logging project out of jakarta, into its own project in Logging Services - Proactively cooperate with the log4j team, commons-logging team, and other interesting parties (e.g. Tomcat, so I'm wearing about three different hats when writing this message), to combine JCL 2.0 intended features with current UGLI features Comments? At this point, the only productive thing that could happen is if log4j adopted the java.util.logging API as the logging API for log4j.next. The java.util.logging API, wether you guys accept it or not, is the only realistic standard moving forward. That way, we would not be needing any wrapper API gimmick, and applications could use the full logging APIs rather than being limited to a small subset of its functionality. One big thing you'll have to understand: I do not and will not change the API yet again (so anything new provided will have to be source and binary compatible). I'm just tired of logging problems. As a personal note, I find this proposal completely out of place after years of FUDing and dissing commons-logging in general, and anything not log4j in particular. -- x Rémy Maucherat Developer Consultant JBoss Group (Europe) SàRL x - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33190] - [collections] Facility for passing an Iterator object into the 'View' part of an MVC framework
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33190. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33190 --- Additional Comments From [EMAIL PROTECTED] 2005-03-24 12:52 --- I, for one, do not put iterators onto the request scope. I just put collections there. So, I would have to be -1 on adding this as a common feature. Also, what if there are multiple iterators added to the request? Which one will close the connection? What if the iterator is never used or not used fully (only showing the first 10 or so)? Is the connection not closed? I don't think I would ever use this idea. I would stick with a request filter. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34165] New: - [configuration] CommandLineConfiguration
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34165. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34165 Summary: [configuration] CommandLineConfiguration Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Configuration AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I implemented a simple configuration taking the properties from the command line. I don't know if it is worth adding in the main code base, but I'm submitting it here if ever someone find it useful. Comments are welcome :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34171] New: - [PATCH]: LazyList: implement set(int index, Object element)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34171.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34171
Summary: [PATCH]: LazyList: implement set(int index, Object
element)
Product: Commons
Version: Nightly Builds
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Collections
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
This patch enhances LazyList so that it will automatically grow larger when
set(int index, Object element) is called if the underlying List supports it
(set() is an optional method in the List interface.) Previously, LazyList only
grew larger when get(int index) was called.
--- LazyList.java.orig 2005-03-24 18:45:20.0 -0500
+++ LazyList.java 2005-03-24 19:04:03.0 -0500
@@ -29,6 +29,10 @@
* object from the factory. Thus this list is unsuitable for storing null
* objects.
* p
+ * If [EMAIL PROTECTED] #set(int)} is called with an index greater than the
size of the list,
+ * the list will automatically grow in size to the specified index, with the
gap filled
+ * by null.
+ * p
* For instance:
*
* pre
@@ -54,6 +58,7 @@
* @author Stephen Colebourne
* @author Arron Bates
* @author Paul Jack
+ * @author Paul Legato
*/
public class LazyList extends AbstractSerializableListDecorator {
@@ -127,6 +132,35 @@
}
}
+//---
+/**
+ * Decorate the set method to perform the lazy behaviour.
+ * p
+ * If the requested index is greater than the current size, the list will
+ * grow to the new size.
+ * Indexes in-between the old size and the requested size are left with a
+ * null placeholder that is replaced with a factory object when requested.
+ *
+ * @param index the index to set
+ * @param element the object to set at index
+ * @return Returns the object previously at that index (or null, if there
was nothing at that index)
+ * @throws UnsupportedOperationException if the underlying list doesn't
implement set()
+ * @throws ClassCastException if the underlying list doesn't like the class
ofelement
+ * @throws IllegalArgumentException if the underlying list doesn't like
some aspect of the specified element
+ */
+public Object set(int index, Object element)
+ {
+int size = getList().size();
+if (index = size) {
+// we have to grow the list
+for (int i = size; i = index; i++) {
+getList().add(null);
+}
+}
+
+ // set object at specified index and return value previously at that
location
+ return getList().set(index, element);
+}
public List subList(int fromIndex, int toIndex) {
List sub = getList().subList(fromIndex, toIndex);
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34142] - [io] use writeTo() instead of toByteArray in DeferredFileOutputStream.thresholdReached()
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34142. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34142 --- Additional Comments From [EMAIL PROTECTED] 2005-03-25 01:40 --- The seconde patch is an enhansment. I'll file a separate request with proper patch for it. Recommend closing this bug it first patch is ok. thx. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34171] - [collections] LazyList: implement set(int index, Object element)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34171. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34171 [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Summary|[PATCH]: LazyList: implement|[collections] LazyList: |set(int index, Object |implement set(int index, |element)|Object element) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30686] - [validator] UrlValidator fails http://www.google.com
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30686. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30686 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-03-25 02:01 --- *** Bug 34146 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] FTP client date parsing: new format
4-6 weeks sounds reasonable. Rory Winston wrote: The last release was from CVS. The docs were (are? - haven't checked) very CVS-centric. I haven't attmepted to try a release from SVN yet, however I presume it wouldn't be too arduous a task, given the ease of substitutability between CVS/SVN. I fixed the issue with missing JUnit tests - they were missing all along (my mistake), I just added them into SVN. As regards a timeline, I'm also pretty swamped over the next couple of weeks (starting a new role, etc), so it will be tight for me until then. If I do get a chance in the next couple of weeks I will look at fixing some of the more straightforward issues in BZ. It would be nice to get a release out before too long - maybe in the next 4-6 weeks, how does that sound as a rough timescale estimate? Jakarta Commons Developers List commons-dev@jakarta.apache.org wrote: Rory Winston wrote: SOunds good. I do think if we go for 1.4 though, we should probably include some of the smaller issues in BZ that would be easy to fix as well, and maybe get some of those cleaned up. IIRC, most of the smaller bugs include patches or source listings. _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm in agreement with that. Would you care to suggest a timeline? I will have very little free time over the next two weeks. After that, maybe I can look at it. When you did the last commit, was subversion in use yet by jakarta? I know the old process was very cvs-centric. HOw accurate were the docs in the new environment? Or is that an adventure yet to be experienced? There were some complaints a few weeks back about missing JUnit tests. Did you ever find out what the deal was with that? Did svn eat them or were they deliberately removed (perhaps because they were failing in Gump and no one knew how to fix them)? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34173] New: - [io][patch] add DeferredFileOutputStream.writeTo() + test
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34173. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34173 Summary: [io][patch] add DeferredFileOutputStream.writeTo() + test Product: Commons Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: IO AssignedTo: commons-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] avoid doubleing the memory requirement when all we want to do is transfer the content onto another OutputStream related to bug 34142 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34173] - [io][patch] add DeferredFileOutputStream.writeTo() + test
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34173. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34173 --- Additional Comments From [EMAIL PROTECTED] 2005-03-25 02:38 --- Created an attachment (id=14559) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14559action=view) new writeTo() method + 2 tests path also contains fix for 34142 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] [VOTE] Bug 33190...
James Carman wrote: Could we try to come up with a more valid use case, then? I don't see including something if we can't even fathom a reasonable use case for it. Off the top of my head, I can't think of a use for this technique. That doesn't mean there isn't one. Maybe I've just never encountered a situation where it would apply. It seems quite dangerous, though, to rely upon the exhaustion of an iterator to release or clean up resources. What happens if an exception is thrown while iterating? The Closure will never be called. Seems a bit odd to me, though I may also be missing the great use cases. I would also be hesitant to ever depend on this kind of thing for cleanup, for the reason that you point out above. Phil James -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Thursday, March 24, 2005 9:04 AM To: Jakarta Commons Developers List Subject: Re: [collections] [VOTE] Bug 33190... --- James Carman [EMAIL PROTECTED] wrote: Could we come to some consensus on this item in Bugzilla? I have already put my $0.02 in as a comment. But, this one is somewhat easy either way we go with it. If the decision is to not include it, then that's a no-brainer. If we decide to include it, then it's not much effort to do that either. But, a decision has to be made. I'm -1 on including it, as I don't think it's a valid approach or all that common. Actually, I think it could be useful as a technique, if we put out of our minds the validness of the given use case. If we did include it, it would essentially be a CallClosureWhenCompleteIterator. So, I'm +0.5. However on coding matters, any -1 is a veto, so it won't happen if you -1. Stephen - 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: [net] FTP client date parsing: new format
Rory Winston writes: As regards a timeline, I'm also pretty swamped over the next couple of weeks ( starting a new role, etc), so it will be tight for me until then. If I do get a chance in the next couple of weeks I will look at fixing some of the more s traightforward issues in BZ. It would be nice to get a release out before too My schedule opens up after April 25, but I'll try to handle some small issues like the recent POP3Client bug report before then. It would also be nice to close a bunch of the resolved issues. too long - maybe in the next 4-6 weeks, how does that sound as a rough timescale estimate? It sounds about right if everyone's tied up for at least the next two weeks and the bulk of the new code is already in CVS. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[httpclient] about bad_record_mac
Hi
I post a few weeks ago a bad_record_mac error.
With Steve, Brad and Oleg help I solved it.
My appli was working good until now. I have added
((SSLSocket)socket).setEnabledProtocols(new String[] {SSLv3});
((SSLSocket)socket).setUseClientMode(true);
In my custom SecureProtocolSocketFactory
I just install my appli on the production machine : just transfert the
jar and run appli.
And patatra similar (not same) problem (see log below). I then recompile
on production machine : same result.
My production machine run mandrake 10.1 with 2.6.8.1 kernel and
j2sdk1.4.2_04
Devt machine run fedora2 with 2.6.7 kernel and j2sdk1.4.2_04.
The problem does not arrived at same level it is at the very begining
on the good working machine the blocking point is passed with success
even it the connection to internet is closed.
Any idea welcome
Andre
Mar 25, 2005 7:46:23 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: I/O exception caught when processing request: Received fatal
alert: bad_record_mac
Mar 25, 2005 7:46:23 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: Retrying request
Mar 25, 2005 7:46:24 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: I/O exception caught when processing request: Received fatal
alert: bad_record_mac
Mar 25, 2005 7:46:24 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: Retrying request
Mar 25, 2005 7:46:25 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: I/O exception caught when processing request: Received fatal
alert: bad_record_mac
Mar 25, 2005 7:46:25 AM org.apache.commons.httpclient.HttpMethodDirector
executeWithRetry
INFO: Retrying request
Exception in thread main javax.net.ssl.SSLException: Received fatal
alert: bad_record_mac
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:124)
at
org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:825)
at
org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:1920)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1002)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:382)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:168)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:393)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at org.compiere.mfg_scm.mageManager.Mages.main(Unknown Source)
