Normal SFSB Business Methods named "remove"

[alrubinger]

This one has been unaddressed for awhile now.

It's the failing case associated with:
https://jira.jboss.org/jira/browse/EJBTHREE-1222

Target methods are resolved based upon a hash, and the hashing function does not take the declaring class into account, thus business interfaces and EJBObject resolve their "remove" methods identically:
https://jira.jboss.org/jira/browse/JBAOP-546

This cannot be fixed (to take declaring class into account).

Further, we can't swap out our use of the AOP MethodHashing for our own because we only directly hash and populate the method tables for "virtual" methods; all others are done by AOP ClassAdvisor, and we don't have the hooks (presently) to redefine the hash function to be applied.

So maybe our best hope is to extract out the hashing logic into a method we can override in ExtendedManagedObjectAdvisor; then ClassAdvisor calls will use our impl.

S,
ALR

[alrubinger]

OK, I can't fix this in AOP, even by extracting and overriding the hashing scheme.

ClassAdvisor registers methods by the bean impl class:

Putting advised method: -956421528 / public int org.jboss.ejb3.core.test.stateful.StatefulBean.getNextCounter()

While we determine invoked method by interface:

Method called: org.jboss.ejb3.core.test.stateful.StatefulLocalBusiness: org.jboss.ejb3.core.test.stateful.StatefulCommonBusiness.getNextCounter()
16:19:59,161 WARN [SessionSpecContainer] Method Hash used: 1793199750

When I throw in a hashing function that takes declaring class into account, then this will not be equal. No method will match.

And without the declaring class into consideration, methods named similarly from different interfaces will collide.

S,
ALR

[alrubinger]

I've been playing with registering the virtual methods of the interfaces instead of the bean impl class. This, coupled with an overriding hash function to take the declaring class of a method into account, moves us forward in terms of getting at whether we have a business or component "remove" method called.

However, it fails the following case:

@Stateless
@Remote(MyRemoteBusiness.class)
public class MyBean{...}

...because MyBean is not assignable to MyRemoteBusiness, MethodInvocation gives us a nice IllegalArgumentException.

I think I'm done messing with this and AOP for now. Patches in progress attached to :

https://jira.jboss.org/jira/browse/EJBTHREE-1621

S,
ALR