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