[jira] Resolved: (FILEUPLOAD-120) memory leak due to classloader leak (in commons.io)

["Jochen Wiedmann (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/FILEUPLOAD-120?page=all ]

Jochen Wiedmann resolved FILEUPLOAD-120.
----------------------------------------

    Resolution: Invalid

As you have found not only the problem, but the reason as well, I believe that there doesn't remain any work for the FILEUPLOAD team. Consequently, I am resolving this as "Invalid" (must be fixed externally). Thanks for reporting this.


> memory leak due to classloader leak (in commons.io)
> ---------------------------------------------------
>
>                 Key: FILEUPLOAD-120
>                 URL: http://issues.apache.org/jira/browse/FILEUPLOAD-120
>             Project: Commons FileUpload
>          Issue Type: Bug
>    Affects Versions: 1.1.1
>         Environment: JBoss portal
>            Reporter: Vera Mickaël
>
> commons.io opens a thread that is never stopped. The result is that a reference from a container class (jboss threads pool) to my webapp classloader is never released and my webapp classloader is never garbaged. After serveral deploy/undeploy cycles I experience an "OutOfMemoryError : PermGen".
> I did open an issue in commons.io : https://issues.apache.org/jira/browse/IO-99
> I also open an issue here as I think commons.fileupload have concerns about webapp environnements

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [BEANUTILS-257] Wrapping all checked exceptions

[Aa...@Globus.ch]

Hello,

Just to get an idea of the "savings", I converted PropertyUtilsTestCase. 
The old version has 3830 lines, the new one 3079 lines (20% less).

Please note that the same amount of savings could have been achieved by 
using "public test...() throws Exception" instead of catching and handling 
each checked exception with fail(). Moreover, PropertyUtilsTestCase is not 
a real world example for the BeanUtils usage.

Regards,

-- 
Aaron Digulla


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

[BEANUTILS-257] Wrapping all checked exceptions

[Aa...@Globus.ch]

Hello,

I'd like to start the discussion about 
http://issues.apache.org/jira/browse/BEANUTILS-257 which I opened.

The idea behind the issue came from using Spring and Hibernate. These big 
frameworks frown upon using checked exceptions because experience shows 
that the code which calls a method in the framework is rarely able to 
handle the exceptions directly. Usually, you either have to pass the 
exception on (adding numerous throws clauses to the code which nobody 
wants except the Java compiler) or you retreat to the dreaded empty-catch, 
or, even worse, to e.printStackTrace().

I have now created the patch. The patch itself is pretty small and simple 
(I was surprised myself; it took less than an hour to write and test):

- I added four exception classes which are derived from RuntimeException. 
They are named after the exception they are supposed to wrap (for example, 
IllegalAccessException, NoSuchMethodException, etc).
- Then I simply imported these in the header of each file where the 
checked exception is used. This overwrites the checked exception in the 
file.
- Lastly, I had to catch the checked exception in a few places (5, IIRC) 
and wrap them

Other things in the patch:

- I've moved invokeMethod() from PropertyUtilsBean to MethodUtils and made 
it public static because it's a very useful function (especially with the 
additional error handling).
- I've made the two private constants in ConstructorUtils public because 
they are very useful elsewhere. Not strictly necessary, though.

The net result is that you can now use all methods in BeanUtils without 
having to throw or catch any exception.

Except ... well, there's an unresolved issue in MappedPropertyDescriptor. 
This class extends PropertyDescriptor which throws a checked exception in 
the constructor (IntrospectionException) which can't be wrapped. I'm not 
sure how this could be solved (or if at all).

For those who are interested, I've attached the patch to my JIRA entry so 
you can have a look yourself.

To port old code to the new API, you just have to remove the import of 
java.lang.reflect.InvocationTargetException and add these lines:

import org.apache.commons.beanutils.exceptions.IllegalAccessException;
import org.apache.commons.beanutils.exceptions.InstantiationException;
import org.apache.commons.beanutils.exceptions.InvocationTargetException;
import org.apache.commons.beanutils.exceptions.NoSuchMethodException;

That's it. Another solution is to remove all try/catch/throws, of course.

Best regards,

-- 
Aaron Digulla


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org