[ 
https://issues.apache.org/jira/browse/TRANSPORTS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270279#comment-14270279
 ] 

Martin Gainty commented on TRANSPORTS-55:
-----------------------------------------

Parroting the cl-mt guide from Java 
registerAsParallelCapable()  should be called after classloader is created in a 
static initalizer:

   " If you have a custom class loader with a risk of deadlocking, with the 
Java SE 7 release, you can avoid deadlocks by following these rules:

        Ensure that your custom class loader is multithread safe for concurrent 
class loading.

        a. Decide upon an internal locking scheme. For example, 
java.lang.ClassLoader uses a locking scheme based on the requested class name.

        b. Remove all synchronization on the class loader object lock alone.

        c. Ensure that critical sections are safe for multiple threads loading 
different classes.

        In your custom class loader's static initializer, invoke 
java.lang.ClassLoader's static method registerAsParallelCapable(). This 
registration indicates that all instances of your custom class loader are 
multithread safe.

        Check that all class loader classes that this custom class loader 
extends also invoke the registerAsParallelCapable() method in their class 
initializers. Ensure that they are multithread safe for concurrent class 
loading.

    If your custom class loader overrides only findClass(String), you do not 
need further changes. This is the recommended mechanism to create a custom 
class loader."

http://stackoverflow.com/questions/18640996/java-deadlock-in-classloaders
http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html

do you want to implement this (so any resource acquired by CL is at least 
thread-safe)?
Saludos Cordiales,
Martín

> Improper Resource Shutdown or Release in BaseUtils.java 246
> -----------------------------------------------------------
>
>                 Key: TRANSPORTS-55
>                 URL: https://issues.apache.org/jira/browse/TRANSPORTS-55
>             Project: Axis2 Transports
>          Issue Type: Bug
>          Components: Base
>    Affects Versions: 1.0.0
>            Reporter: David Camilo Espitia Manrique
>              Labels: security
>             Fix For: 1.0.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We are currently using "Axis2-transport-base 1.0.0 " and the veracode 
> analysis found a bug in this class "BaseUtils.java" line 246:
> Type:  Improper Resource Shutdown or Release
> Description:
> The application fails to release (or incorrectly releases) a system resource 
> before it is made available for re-use. This
> condition often occurs with resources such as database connections or file 
> handles. Most unreleased resource issues
> result in general software reliability problems, but if an attacker can 
> intentionally trigger a resource leak, it may be
> possible to launch a denial of service attack by depleting the resource pool.
> Recommendations:
> When a resource is created or allocated, the developer is responsible for 
> properly releasing the resource as well as
> accounting for all potential paths of expiration or invalidation. Ensure that 
> all code paths properly release resources



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to