MethodSecurityInterceptor and inherited methods inherited, interface, property, relevant, methods

amy

Hi all,

I was trying to wire up a MethodSecurityInterceptor and kept getting this exception on startup:Code:
java.lang.IllegalArgumentException: Couldn't find method 'find*' on interface playground.service.PurchaseService
The relevant part of the MethodSecurityInterceptor config is:Code:
lt;property name=quot;objectDefinitionSourcequot;gt;
lt;valuegt;        playground.service.PurchaseService.find*=ROLE_ADMIN,ROLE_USER
lt;/valuegt;
lt;/propertygt;
Now, the find* methods on PurchaseService are inherited from a base interface -- there aren't actually any defined in the interface.  It took me some time to discover that that was the source of the exception as it was pretty counterintuitive (to me, at least) that inherited methods would not be available targets for the objectDefinitionSource.

So I investigated the Acegi source and discovered (I believe) where the problem is coming from:

from org.acegisecurity.intercept.method.MethodDefinitio  nMap.java:

Code: 116     public void addSecureMethod(Class clazz, String mappedName, ConfigAttributeDefinition attr) { 117         String name = clazz.getName() + '.' + mappedName; 118  119         if (logger.isDebugEnabled()) { 120             logger.debug(quot;Adding secure method [quot; + name + quot;] with attributes [quot; + attr + quot;]quot;); 121         } 122  123         Method[] methods = clazz.getDeclaredMethods();  lt;---- Right here
The getDeclaredMethods() call is what does it.  According to the javadoc, it:
Returns an array of Method objects reflecting all the methods declared by the class or interface represented by this Class object. This includes public, protected, default (package) access, and private methods, _but excludes inherited methods_. ...

So there you have it.  Now, my question is, why is getDeclaredMethods() used rather than getMethods() here?  Is there some reason that MethodSecurityInterceptor should not wrap inherited methods?  Am I completely missing some simple point?  I'm new to Acegi and Spring, so that may well be the case... if so, I would appreciate it if someone could point it out to me

If not, maybe this would be a good change?Thanks!

I don't know if there is a special reason for doing it the way it is. However, at least it is consistent with Spring itself. For example when defining a transaction interceptor you face the same issue when you are about to specify methods to intercept.
Anyway, even if the behavior will not be changed it might be a good thing to document this prominently.

Regards,
Andreas

Thanks for the reply Andreas.  My biggest concern here was that there was some very good reason for Acegi's behaviour that I just wasn't aware of, and you've helped assure me that isn't the case.

I'm surprised that this hasn't come up before, though; I did some forum searching before I made the first post but didn't turn up anything relevant.  It seems to me that this would be quite a common usage (wanting to apply a MethodSecurityInterceptor to an inherited method).  Has no one else run into this problem?

Me. I think it's a bit too restrictive.
showthread.php?t=28593