Re: [DBCP] Remove SQLNestedException
On 7/24/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: > > > On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >> > >> So, should we drop SQLNestedException? > > > > This is tempting, but it breaks backward compatibility, so we should > > probably deprecate in 1.3 and remove in the next major release. I > > guess the deprecation warning / release notes should just tell people > > to remove "legacy" casts in client code, since we never advertise this > > exception. > > Sounds good. I marked the class as deprecated, moved DBCP-143 to > 1.4, and added a note to the change log. > He means v2.0 AFAICT. Details [1]. -Rahul [1] http://jakarta.apache.org/commons/releases/versioning.html Yes that's what I meant, following our rules. In this case, that is a little extreme, however, since the only breakage that I can think of is old 1.3 code that includes explicit casts in catch blocks, or direct usage or extension of the since-1.4-obsolete exception class itself. Is this really worth waiting for 2.0? Am I missing something here? Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] dbcp failed.
Should be fixed now. The nightlies run the m1 build and that needs the transitive dependencies to be specified. We could change the nightly to m2, but I think it is a good idea to keep the m1 build working for now and the nightly can alter us if we break it. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r559315 - /jakarta/commons/proper/dbcp/trunk/project.xml
Author: psteitz Date: Tue Jul 24 21:45:13 2007 New Revision: 559315 URL: http://svn.apache.org/viewvc?view=rev&rev=559315 Log: Added transitive dependencies needed by m1 build. Modified: jakarta/commons/proper/dbcp/trunk/project.xml Modified: jakarta/commons/proper/dbcp/trunk/project.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/project.xml?view=diff&rev=559315&r1=559314&r2=559315 == --- jakarta/commons/proper/dbcp/trunk/project.xml (original) +++ jakarta/commons/proper/dbcp/trunk/project.xml Tue Jul 24 21:45:13 2007 @@ -210,6 +210,18 @@ Only required for managed connections tests + + + org.apache.geronimo.specs + geronimo-ejb_2.1_spec + 1.1 + + + + backport-util-concurrent + backport-util-concurrent + 2.2 + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moderator volunteer?
On 7/24/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 7/24/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > Thanks Phil :) > NP. Impressive response time by Brett. Almost as impressive as the spammers. Now if I can just determine which commons component will help this poor soul get the money he is owed;-) Obviously Commons Transaction :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded
[ https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened FILEUPLOAD-140: -- Reopening as there's a post-close comment on there. > Means to preserve text parameters when upload limit exceeded > > > Key: FILEUPLOAD-140 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Paul Benedict >Assignee: Jochen Wiedmann > > I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but > am lacking the means to do it. The current use is with the deprecated > DiskFileUpload and I prefer to have this class fixed first. When > SizeLimitExceededException is thrown, it does not return the items it has > collected thus far. I see two possible solutions which involve adding a > property on the exception to return them: > (1) Return the parameters thus gathered or > (2) finish out the input stream but throw away all file items and return only > the text parameters. > Otherwise, whenever a the upload exceeds its limit, all other input > parameters disappear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515107 ] Paul Benedict commented on FILEUPLOAD-141: -- Here's a past ticket from Struts on the very issue: https://issues.apache.org/struts/browse/STR-3031 > Remove FileItems if FileUploadBase.parseRequest() fails > --- > > Key: FILEUPLOAD-141 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 > Environment: commons-fileupload is used for parsing > multipart/form-data POST requests in servlets. > OS: Linux >Reporter: Marcus Klein > > If the method FileUploadBase.parseRequest() throws a FileUploadException, the > already parsed FileItem objects are not accessible and removed by the garbage > collector. Now expect a fileupload that fills the servers hard disc with > FileItems until no space is left on the device. The method parseRequest() > throws a FileUploadException and there are several FileItem objects that > still exist in the device because the garbage collector does not run and > removes them. This causes failing fileuploads until the garbage collector > runs and removes the lost FileItem objects. I suggest calling > FileItem.delete() on all FileItem objects created in the method > FileUploadBase.parseRequest() if the method is left with a > FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration][all] Support for OS environment variables
Well, deprecated doesn't mean gone. So, if it was undeprecated in 1.5 then I wouldn't consider it deprecated in earlier versions any more. I would just consider it a goofy warning to deal with. At least that is the way I would look at that. Then, I also don't look at deprecated to mean don't "ever" use. As in this case, it didn't make sense for it to go away as it is something which is needed, and was probably undeprecated for the same reason other desktop integration as added such as OS taskbar icons and menus in 1.6, and other times this has occurred in different APIs yet the API lags on because there is no good alternative. Just as in the NetBeans APIs there are some APIs which have been deprecated yet no new APIs are under way yet, so they won't be going away any time soon, so until they are replaced the deprecated ones have to be used. Wade --- Oliver Heger <[EMAIL PROTECTED]> wrote: > Wade Chandler wrote: > > Sure, but not from a configuration perspective. > For > > instance, if daemon used configuration for a > > configuration file it could be easier to use. > Provide > > multiple configuration files with your > distribution > > which allows users to more easily install and > > uninstall services and operate on them without > > remembering command line switches etc. launcher > could > > even use configuration (which is smaller than ANT) > yet > > also allow ANT and not have as many runtime > > requirements. Then of course other applications > can > > just use a single configuration entry point and > use > > configuration information and reference > environment > > variables without having to hard code them into > their > > sources...makes it configurable. > > > > > > Wade > > > > --- Mark Fortner <[EMAIL PROTECTED]> wrote: > > > >> Isn't this already handled by System.getenv? > > System.getenv() has long been deprecated and is now > available again > since 1.5. [configuration] still has 1.3 as minimum > required JDK; I > don't know when we switch to 1.5 (there will > probably be another version > that requires 1.4). > > My problem with this issue is that it will probably > take a high effort > to implement it correctly for earlier JDKs, while we > get it for free in > 1.5. This seem counter-productive. > > Oliver > > >> > >> On 7/23/07, Wade Chandler > >> <[EMAIL PROTECTED]> wrote: > >>> Personally, I think this type thing comes in > very > >>> handy in different situations. It would even be > >> handy > >>> in daemon and launcher. Look how many times > >> scripts > >>> have to be written for every OS to get different > >>> things like JAVA_HOME and ANT_HOME or similar > into > >> an > >>> application. It has been deprecated for a long > >> time, > >>> but I doubt it will ever be removed. It seems to > >> be > >>> quite needed in situations. > >>> > >>> Wade > >>> > >>> --- Oliver Heger <[EMAIL PROTECTED]> > >> wrote: > Hi all, > > for [configuration] we have a feature request > >> for > supporting environment > variables [1]. I searched the archives and > found > that this topic has > been discussed before [2]. > > I was wondering whether situation has changed > >> since > then. My personal > opinion is expressed in the Jira ticket in [1]. > >> What > do others think? > > Please note that the ticket contains an > >> attachment > with a simple > implementation for accessing environment > >> variables. > Thanks > Oliver > > [1] > > > > http://issues.apache.org/jira/browse/CONFIGURATION-284 > [2] > > > > http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325 > > > > > > > > - > > 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: Moderator volunteer?
On 7/24/07, Henri Yandell <[EMAIL PROTECTED]> wrote: Thanks Phil :) NP. Impressive response time by Brett. Almost as impressive as the spammers. Now if I can just determine which commons component will help this poor soul get the money he is owed;-) Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration][all] Support for OS environment variables
Wade Chandler wrote: Sure, but not from a configuration perspective. For instance, if daemon used configuration for a configuration file it could be easier to use. Provide multiple configuration files with your distribution which allows users to more easily install and uninstall services and operate on them without remembering command line switches etc. launcher could even use configuration (which is smaller than ANT) yet also allow ANT and not have as many runtime requirements. Then of course other applications can just use a single configuration entry point and use configuration information and reference environment variables without having to hard code them into their sources...makes it configurable. Wade --- Mark Fortner <[EMAIL PROTECTED]> wrote: Isn't this already handled by System.getenv? System.getenv() has long been deprecated and is now available again since 1.5. [configuration] still has 1.3 as minimum required JDK; I don't know when we switch to 1.5 (there will probably be another version that requires 1.4). My problem with this issue is that it will probably take a high effort to implement it correctly for earlier JDKs, while we get it for free in 1.5. This seem counter-productive. Oliver On 7/23/07, Wade Chandler <[EMAIL PROTECTED]> wrote: Personally, I think this type thing comes in very handy in different situations. It would even be handy in daemon and launcher. Look how many times scripts have to be written for every OS to get different things like JAVA_HOME and ANT_HOME or similar into an application. It has been deprecated for a long time, but I doubt it will ever be removed. It seems to be quite needed in situations. Wade --- Oliver Heger <[EMAIL PROTECTED]> wrote: Hi all, for [configuration] we have a feature request for supporting environment variables [1]. I searched the archives and found that this topic has been discussed before [2]. I was wondering whether situation has changed since then. My personal opinion is expressed in the Jira ticket in [1]. What do others think? Please note that the ticket contains an attachment with a simple implementation for accessing environment variables. Thanks Oliver [1] http://issues.apache.org/jira/browse/CONFIGURATION-284 [2] http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325 - 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: Moderator volunteer?
Thanks Phil :) On 7/23/07, Brett Porter <[EMAIL PROTECTED]> wrote: swapped :) On 24/07/07, Phil Steitz <[EMAIL PROTECTED]> wrote: > I will do this. > > Phil > > On 7/23/07, Henri Yandell <[EMAIL PROTECTED]> wrote: > > Is there anyone who could volunteer to moderate the list? > > > > I'm looking to share the load and get off of commons-dev moderating :) > > > > 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] > > -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - 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: [nightly build] dbcp failed.
Yeah, our work CI also found it. Linux box. On 7/24/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Can anyone else reproduce this failure? > Yes (XP, Tiger, m102). -Rahul > -dain > > On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote: > > > Failed build logs: > > http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log > > - 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: File upload
On 7/24/07, Hetal Varma <[EMAIL PROTECTED]> wrote: Hi, I want a code for uploading a file to the location (that should be user specific means user select at runtime- on the server). This list is for development discussions related to Commons components. Please try the user list instead for usage questions. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
File upload
Hi, I want a code for uploading a file to the location (that should be user specific means user select at runtime- on the server). Please help me. Thank You.
Re: [nightly build] dbcp failed.
On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Can anyone else reproduce this failure? Yes (XP, Tiger, m102). -Rahul -dain On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote: > Failed build logs: > http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove SQLNestedException
On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: > On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: >> >> So, should we drop SQLNestedException? > > This is tempting, but it breaks backward compatibility, so we should > probably deprecate in 1.3 and remove in the next major release. I > guess the deprecation warning / release notes should just tell people > to remove "legacy" casts in client code, since we never advertise this > exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. He means v2.0 AFAICT. Details [1]. -Rahul [1] http://jakarta.apache.org/commons/releases/versioning.html -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] svn props (was: svn commit: r558884)
On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: dain Date: Mon Jul 23 15:28:37 2007 New Revision: 558884 URL: http://svn.apache.org/viewvc?view=rev&rev=558884 Log: DBCP-221 Changed BasicDataSource.close() to permanently mark the data source as closed. At close all idle connections are destroyed and the method returns. As existing active connections are closed, they are destroyed. Added: jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/managed/TestBasicManagedDataSource.java It seems no props were added. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r559136 - /jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Author: dain Date: Tue Jul 24 10:48:05 2007 New Revision: 559136 URL: http://svn.apache.org/viewvc?view=rev&rev=559136 Log: Added note about fix to BasicDataSource.close() Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml?view=diff&rev=559136&r1=559135&r2=559136 == --- jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml (original) +++ jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml Tue Jul 24 10:48:05 2007 @@ -82,6 +82,12 @@ SQLNestedException has been deprecated and will be replaced in DBCP 1.4 with SQLException and standard Java exception chaining. + +BasicDataSource.close() now permanently marks the data source as closed, +and no new connections can be obtained from the data source. At close all +idle connections are destroyed and the method returns. As the remaining +active connections are closed, they are destroyed. +
Re: [DBCP] Remove SQLNestedException
On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: DBCP-143 talks about problem with propagation of SQLNestedException to clients and the comment suggests a conversion to normal Java nested exception when we switch to Java 1.4. Since we made the leap, I did a bit of refactoring to remove this exception class. Basically I replace: new SQLNestedException(msg, e); with: (SQLException) new SQLException(msg).initCause(e); I attached this at a patch to 143 as I'm not 100% sure we want to go this direction. So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove "legacy" casts in client code, since we never advertise this exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r559128 - /jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Author: dain Date: Tue Jul 24 10:35:02 2007 New Revision: 559128 URL: http://svn.apache.org/viewvc?view=rev&rev=559128 Log: Added change log note on the deprecation of SQLNestedException Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml URL: http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml?view=diff&rev=559128&r1=559127&r2=559128 == --- jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml (original) +++ jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml Tue Jul 24 10:35:02 2007 @@ -78,6 +78,10 @@ to create the statement or result set is returned from either getConnection() or getStatement(). + +SQLNestedException has been deprecated and will be replaced in DBCP 1.4 with +SQLException and standard Java exception chaining. +
[jira] Updated: (DBCP-143) [dbcp] SQLNestedException thrown by server causes client ClassNotFoundException.
[ https://issues.apache.org/jira/browse/DBCP-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-143: Fix Version/s: (was: 1.3) 1.4 SQLNestedException has been deprecated in 1.3 and will be removed in 1.4 > [dbcp] SQLNestedException thrown by server causes client > ClassNotFoundException. > > > Key: DBCP-143 > URL: https://issues.apache.org/jira/browse/DBCP-143 > Project: Commons Dbcp > Issue Type: Bug > Environment: Operating System: other > Platform: Other >Reporter: Andreas Krüger > Fix For: 1.4 > > Attachments: DBCP-143.patch > > > This is a GUI client / application server / database server application. > On the GUI client side, we see java.lang.ClassNotFoundException: > org.apache.commons.dbcp.SQLNestedException. > This happens when the database server is down, DBCP cannot connect to the > database, and throws a org.apache.commons.dbcp.SQLNestedException. > Our application server code sends the java.sql.SQLException it sees to the > client via RMI. > However, on the client, we have not provided commons-dbcp.jar. > And I don't think we should - DBCP is server code. > But, when the client does not have SQLNestedException's class file, the > attempt > to de-serialize it results in the ClassNotFoundException we've been seeing. > Even old http://java.sun.com/j2se/1.3/docs/api/java/sql/SQLException.html has > the facilities that SQLNestedExcepion offers: It is able to chain another > SQLException to itself. So while SQLNestedException clearly causes problems, I > don't understand what DBCP gains from it. > What would we loose if it were scratched? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r559119 - /jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java
Author: dain
Date: Tue Jul 24 10:24:03 2007
New Revision: 559119
URL: http://svn.apache.org/viewvc?view=rev&rev=559119
Log:
Deprecated SQLNestedException
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java?view=diff&rev=559119&r1=559118&r2=559119
==
---
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java
(original)
+++
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java
Tue Jul 24 10:24:03 2007
@@ -28,6 +28,7 @@
*
* @author Dirk Verbeeck
* @version $Revision$ $Date$
+ * @deprecated Use '(SQLException) new SQLException(msg).initCause(e)'
instead; this class will be removed in DBCP 1.4
*/
public class SQLNestedException extends SQLException {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [nightly build] dbcp failed.
Can anyone else reproduce this failure? -dain On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log - 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]
[jira] Reopened: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened FILEUPLOAD-141: -- (Reopening as closed issues with ongoing conversations are too easy to lose track of) > Remove FileItems if FileUploadBase.parseRequest() fails > --- > > Key: FILEUPLOAD-141 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 > Environment: commons-fileupload is used for parsing > multipart/form-data POST requests in servlets. > OS: Linux >Reporter: Marcus Klein > > If the method FileUploadBase.parseRequest() throws a FileUploadException, the > already parsed FileItem objects are not accessible and removed by the garbage > collector. Now expect a fileupload that fills the servers hard disc with > FileItems until no space is left on the device. The method parseRequest() > throws a FileUploadException and there are several FileItem objects that > still exist in the device because the garbage collector does not run and > removes them. This causes failing fileuploads until the garbage collector > runs and removes the lost FileItem objects. I suggest calling > FileItem.delete() on all FileItem objects created in the method > FileUploadBase.parseRequest() if the method is left with a > FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration][all] Support for OS environment variables
Sure, but not from a configuration perspective. For instance, if daemon used configuration for a configuration file it could be easier to use. Provide multiple configuration files with your distribution which allows users to more easily install and uninstall services and operate on them without remembering command line switches etc. launcher could even use configuration (which is smaller than ANT) yet also allow ANT and not have as many runtime requirements. Then of course other applications can just use a single configuration entry point and use configuration information and reference environment variables without having to hard code them into their sources...makes it configurable. Wade --- Mark Fortner <[EMAIL PROTECTED]> wrote: > Isn't this already handled by System.getenv? > > On 7/23/07, Wade Chandler > <[EMAIL PROTECTED]> wrote: > > > > Personally, I think this type thing comes in very > > handy in different situations. It would even be > handy > > in daemon and launcher. Look how many times > scripts > > have to be written for every OS to get different > > things like JAVA_HOME and ANT_HOME or similar into > an > > application. It has been deprecated for a long > time, > > but I doubt it will ever be removed. It seems to > be > > quite needed in situations. > > > > Wade > > > > --- Oliver Heger <[EMAIL PROTECTED]> > wrote: > > > > > Hi all, > > > > > > for [configuration] we have a feature request > for > > > supporting environment > > > variables [1]. I searched the archives and found > > > that this topic has > > > been discussed before [2]. > > > > > > I was wondering whether situation has changed > since > > > then. My personal > > > opinion is expressed in the Jira ticket in [1]. > What > > > do others think? > > > > > > Please note that the ticket contains an > attachment > > > with a simple > > > implementation for accessing environment > variables. > > > > > > Thanks > > > Oliver > > > > > > [1] > > > > > > http://issues.apache.org/jira/browse/CONFIGURATION-284 > > > [2] > > > > > > http://thread.gmane.org/gmane.comp.jakarta.commons.devel/33239/focus=33325 > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove SQLNestedException
On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote: DBCP-143 talks about problem with propagation of SQLNestedException to clients and the comment suggests a conversion to normal Java nested exception when we switch to Java 1.4. Since we made the leap, I did a bit of refactoring to remove this exception class. Basically I replace: new SQLNestedException(msg, e); with: (SQLException) new SQLException(msg).initCause(e); I attached this at a patch to 143 as I'm not 100% sure we want to go this direction. So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove "legacy" casts in client code, since we never advertise this exception. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514940 ] Paul Benedict edited comment on FILEUPLOAD-141 at 7/24/07 4:12 AM: --- That's why it should be an option. Adding a boolean property to control this behavior would be a minor enhancement. I've seen this issue come up before in server environments, so this request is definitely not unusual. And in fact, this would be a feature I would want to use often with my own customers. To have it supported officially by Commons Upload would be beneficial and, I think, warranted. was: That's why it should be an option. Adding a boolean property to control this behavior would be a minor enhancement. > Remove FileItems if FileUploadBase.parseRequest() fails > --- > > Key: FILEUPLOAD-141 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 > Environment: commons-fileupload is used for parsing > multipart/form-data POST requests in servlets. > OS: Linux >Reporter: Marcus Klein > > If the method FileUploadBase.parseRequest() throws a FileUploadException, the > already parsed FileItem objects are not accessible and removed by the garbage > collector. Now expect a fileupload that fills the servers hard disc with > FileItems until no space is left on the device. The method parseRequest() > throws a FileUploadException and there are several FileItem objects that > still exist in the device because the garbage collector does not run and > removes them. This causes failing fileuploads until the garbage collector > runs and removes the lost FileItem objects. I suggest calling > FileItem.delete() on all FileItem objects created in the method > FileUploadBase.parseRequest() if the method is left with a > FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514940 ] Paul Benedict commented on FILEUPLOAD-141: -- That's why it should be an option. Adding a boolean property to control this behavior would be a minor enhancement. > Remove FileItems if FileUploadBase.parseRequest() fails > --- > > Key: FILEUPLOAD-141 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 > Environment: commons-fileupload is used for parsing > multipart/form-data POST requests in servlets. > OS: Linux >Reporter: Marcus Klein > > If the method FileUploadBase.parseRequest() throws a FileUploadException, the > already parsed FileItem objects are not accessible and removed by the garbage > collector. Now expect a fileupload that fills the servers hard disc with > FileItems until no space is left on the device. The method parseRequest() > throws a FileUploadException and there are several FileItem objects that > still exist in the device because the garbage collector does not run and > removes them. This causes failing fileuploads until the garbage collector > runs and removes the lost FileItem objects. I suggest calling > FileItem.delete() on all FileItem objects created in the method > FileUploadBase.parseRequest() if the method is left with a > FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-24072007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-24072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-24072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-24072007.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-24072007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.characters(pChars, pOffset, pLen); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:305: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.init(pData); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:315: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] __handler_Name.init(getData()); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressHandler.java:22: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressHandler [
[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-jaxme has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-jaxme : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-jaxme-24072007.jar] identifier set to project name -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-js. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-xs. -DEBUG- Dependency on packaged-jaxme exists, no need to add for property maven.jar.jaxme-api. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/gump_work/build_commons-jelly_commons-jelly-tags-jaxme.html Work Name: build_commons-jelly_commons-jelly-tags-jaxme (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-24072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/xmlunit/target/commons-jelly-tags-xmlunit-24072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-24072007.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxme2-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmeapi-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmejs-0.5.jar:/srv/gump/packages/ws-jaxme-0.5/lib/jaxmexs-0.5.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xmlunit/build/lib/xmlunit-24072007.jar - [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.characters(pChars, pOffset, pLen); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:305: cannot find symbol [javac] symbol : variable super [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] super.init(pData); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressTypeHandler.java:315: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressTypeHandler [javac] __handler_Name.init(getData()); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/jaxme/src/test/org/apache/ws/jaxme/examples/misc/address/impl/AddressHandler.java:22: cannot find symbol [javac] symbol : method getData() [javac] location: class org.apache.ws.jaxme.examples.misc.address.impl.AddressHandler [
[nightly build] dbcp failed.
Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-util (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-util has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-util : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-util-24072007.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/gump_work/build_commons-jelly_commons-jelly-tags-util.html Work Name: build_commons-jelly_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/util] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-24072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24072007.jar:/srv/gump/public/workspace/jakarta-commons/lang/commons-lang-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-24072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: commons-beanutils-bean-collections-1.7.0.jar (try downloading from http://jakarta.apache.org/commons/beanutils/) Total time: 2 seconds Finished at: Tue Jul 24 01:57:05 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0824072007, vmgump:vmgump-public:0824072007 Gump E-mail Identifier (unique within run) #44. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-jelly-tags-util (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project commons-jelly-tags-util has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 11 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-ant : Commons Jelly - commons-jelly-tags-fmt : Commons Jelly - commons-jelly-tags-fmt-test : Commons Jelly - commons-jelly-tags-html : Commons Jelly - commons-jelly-tags-jsl : Commons Jelly - commons-jelly-tags-jsl-test : Commons Jelly - commons-jelly-tags-util : Commons Jelly - maven : Project Management Tools - maven-bootstrap : Project Management Tools Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-jelly-tags-util-24072007.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/util/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/gump_work/build_commons-jelly_commons-jelly-tags-util.html Work Name: build_commons-jelly_commons-jelly-tags-util (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/util] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-24072007.jar:/srv/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24072007.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-24072007.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-24072007.jar:/srv/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-24072007.jar:/srv/gump/public/workspace/jakarta-commons/lang/commons-lang-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072007.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-24072007.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependency: commons-beanutils-bean-collections-1.7.0.jar (try downloading from http://jakarta.apache.org/commons/beanutils/) Total time: 2 seconds Finished at: Tue Jul 24 01:57:05 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-util/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0824072007, vmgump:vmgump-public:0824072007 Gump E-mail Identifier (unique within run) #44. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-24072007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/jakarta-commons-sandbox/id] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072007.jar:/srv/gump/public/workspace/junit/dist/junit-24072007.jar:/srv/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/srv/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependencies: dom4j-1.4.jar commons-jelly-1.0-RC1.jar commons-jelly-tags-jsl-1.0.jar commons-jelly-tags-log-1.0.jar commons-jelly-tags-velocity-1.0.jar commons-jelly-tags-xml-1.1.jar (try downloading from http://jakarta.apache.org/commons/jelly/libs/xml/) maven-1.0.2.jar maven-model-3.0.0.jar velocity-1.4.jar commons-jelly-tags-fmt-1.0.jar Total time: 2 seconds Finished at: Tue Jul 24 01:56:41 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0824072007, vmgump:vmgump-public:0824072007 Gump E-mail Identifier (unique within run) #43. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project commons-id (in module jakarta-commons-sandbox) 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-id has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-id : Commons Identifier Package Full details are available at: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-id-24072007.jar] identifier set to project name -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/jakarta-commons-sandbox/id/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_work/build_jakarta-commons-sandbox_commons-id.html Work Name: build_jakarta-commons-sandbox_commons-id (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/jakarta-commons-sandbox/id] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-24072007.jar:/srv/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-24072007.jar:/srv/gump/public/workspace/junit/dist/junit-24072007.jar:/srv/gump/packages/maven-cobertura-plugin/maven-cobertura-plugin-1.1.jar:/srv/gump/packages/maven-xdoc-plugin/maven-xdoc-plugin-1.9.2.jar - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 The build cannot continue because of the following unsatisfied dependencies: dom4j-1.4.jar commons-jelly-1.0-RC1.jar commons-jelly-tags-jsl-1.0.jar commons-jelly-tags-log-1.0.jar commons-jelly-tags-velocity-1.0.jar commons-jelly-tags-xml-1.1.jar (try downloading from http://jakarta.apache.org/commons/jelly/libs/xml/) maven-1.0.2.jar maven-model-3.0.0.jar velocity-1.4.jar commons-jelly-tags-fmt-1.0.jar Total time: 2 seconds Finished at: Tue Jul 24 01:56:41 GMT-08:00 2007 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/rss.xml - Atom: http://vmgump.apache.org/gump/public/jakarta-commons-sandbox/commons-id/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 0824072007, vmgump:vmgump-public:0824072007 Gump E-mail Identifier (unique within run) #43. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514923 ] Jochen Wiedmann commented on FILEUPLOAD-141: The fact that you want the files to be deleted is, IMO, by no means an indicator that others do wish the same. > Remove FileItems if FileUploadBase.parseRequest() fails > --- > > Key: FILEUPLOAD-141 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 > Environment: commons-fileupload is used for parsing > multipart/form-data POST requests in servlets. > OS: Linux >Reporter: Marcus Klein > > If the method FileUploadBase.parseRequest() throws a FileUploadException, the > already parsed FileItem objects are not accessible and removed by the garbage > collector. Now expect a fileupload that fills the servers hard disc with > FileItems until no space is left on the device. The method parseRequest() > throws a FileUploadException and there are several FileItem objects that > still exist in the device because the garbage collector does not run and > removes them. This causes failing fileuploads until the garbage collector > runs and removes the lost FileItem objects. I suggest calling > FileItem.delete() on all FileItem objects created in the method > FileUploadBase.parseRequest() if the method is left with a > FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514895 ] Marcus Klein commented on FILEUPLOAD-141: - I think that the commons-fileupload API is especially used in server environments. Hanging files are always an issue in server environments in my opinion. Every unused file descriptor wastes resources in a server environment that may lead to problems due to always limited system resources. Can you please explain the compatibility problems that will occur with my suggested changes? How could cause calling delete() on not referenced FileItem objects any problems? > Remove FileItems if FileUploadBase.parseRequest() fails > --- > > Key: FILEUPLOAD-141 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 > Project: Commons FileUpload > Issue Type: Improvement >Affects Versions: 1.2 > Environment: commons-fileupload is used for parsing > multipart/form-data POST requests in servlets. > OS: Linux >Reporter: Marcus Klein > > If the method FileUploadBase.parseRequest() throws a FileUploadException, the > already parsed FileItem objects are not accessible and removed by the garbage > collector. Now expect a fileupload that fills the servers hard disc with > FileItems until no space is left on the device. The method parseRequest() > throws a FileUploadException and there are several FileItem objects that > still exist in the device because the garbage collector does not run and > removes them. This causes failing fileuploads until the garbage collector > runs and removes the lost FileItem objects. I suggest calling > FileItem.delete() on all FileItem objects created in the method > FileUploadBase.parseRequest() if the method is left with a > FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
