tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Zbyszynski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENEJB-1108) CoreDeploymentInfo should not be using Method objects as keys in HashMaps since Method.hashCode() returns the same for overloaded methods.
Date Wed, 11 Nov 2009 02:01:27 GMT

    [ https://issues.apache.org/jira/browse/OPENEJB-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776237#action_12776237
] 

Marc Zbyszynski commented on OPENEJB-1108:
------------------------------------------

Actually changing the method name did not solve my original problem, so the HashMap thing
may not actually be an issue. Please don't spend any time researching this until I do some
more research. I will update this ticket tomorrow, or close it if I figure out the problem.

> 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.


Mime
View raw message