You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Marc Zbyszynski (JIRA)" <ji...@apache.org> on 2009/11/11 06:32:27 UTC

[jira] Resolved: (OPENEJB-1108) CoreDeploymentInfo should not be using Method objects as keys in HashMaps since Method.hashCode() returns the same for overloaded methods.

     [ https://issues.apache.org/jira/browse/OPENEJB-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marc Zbyszynski resolved OPENEJB-1108.
--------------------------------------

    Resolution: Invalid

Sorry, after more research it appears that this not actually an issue. InterceptorBindingBuilder is correctly dealing with methods and method parameters. The problem I am having has something to do with InterceptorBindingBuilder.implies. My method annotated with @ExcludeClassInterceptors has an input parameter that for some reason is not being found by the class loader in line 229 of InterceptorBindingBuilder . Probably something to do with my environment. 

Please ignore this issue. Sorry for the noise.

> CoreDeploymentInfo should not be using Method objects as keys in HashMaps since Method.hashCode() returns the same for overloaded methods.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OPENEJB-1108
>                 URL: https://issues.apache.org/jira/browse/OPENEJB-1108
>             Project: OpenEJB
>          Issue Type: Bug
>          Components: container system
>    Affects Versions: 3.1.2
>         Environment: Windows XP, Java JDK 1.6.0_12
>            Reporter: Marc Zbyszynski
>
> I think I found a bug in org.apache.openejb.core.CoreDeploymentInfo.java. Apologies if it has already been reported (I searched around in Jira and couldn't find anything).
> The issue is with this method:
>     public void mapMethods(Method interfaceMethod, Method beanMethod){
>         methodMap.put(interfaceMethod, beanMethod);
>     }
> methodMap is a HashMap:
> private final Map<Method, Method> methodMap = new HashMap<Method, Method>();
> The problem I found is with overloaded methods. The hashCode implementation of Method is:
>     public int hashCode() {
> 	return getDeclaringClass().getName().hashCode() ^ getName().hashCode();
>     }
> I found that if I had a session bean with two methods with the same name but different method signatures like so:
> public void startEditing(Long,Long);
> public void startEditing(Long,String);
> then the second method was over-writing the first in that HashMap. The problem this was causing for me had to do with interceptors. In my implementation class I was declaring interceptors at the class level, but for the two methods above I was using @ExcludeClassInterceptors. When I ran my tests, I found that one of the above methods was ignoring the class-level interceptors as expected, but the other was not.
> I believe this is because one of the method signatures is missing in from that map of messages since they both have the same hashCode value.
> It seems pretty strange that Method.hashCode() doesn't take into account the method parameters, but since that's not something that they are likely to change any time soon, CoreDeploymentInfo should not use HashMap<Method, Method> to store ejb methods....
> Sorry again if I got any of this wrong or if I did not provide enough information.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.