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