Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn message when booting application #459

Closed
jjchiw opened this issue Feb 14, 2017 · 6 comments · Fixed by #626
Closed

Warn message when booting application #459

jjchiw opened this issue Feb 14, 2017 · 6 comments · Fixed by #626

Comments

@jjchiw
Copy link

jjchiw commented Feb 14, 2017

Hi!

I have this warn message when booting the app

2017-02-14 17:19:23.722  WARN --- [ost-startStop-1] o.s.b.GenericTypeAwarePropertyDescriptor : 
Invalid JavaBean property 'exceptionMappings' being accessed! Ambiguous write methods
found next to actually used 
[public void grails.plugin.springsecurity.web.authentication.AjaxAwareAuthenticationFailureHandler.setExceptionMappings(java.util.List)]: 
[public void org.springframework.security.web.authentication.ExceptionMappingAuthenticationFailureHandler.setExceptionMappings(java.util.Map)]

ExceptionMappingAuthenticationFailureHandler L70

AjaxAwareAuthenticationFailureHandler L57

I'm using:

| Grails Version: 3.2.4
| Groovy Version: 2.4.7
| JVM Version: 1.8.0_112
| spring-security-core Version: 3.1.1

it's not a blocking issue just a minor/little one

Thanks :)

@sdelamo
Copy link
Contributor

sdelamo commented Apr 21, 2017

How to reproduce

In a simple app such as:

https://github.com/grails-spring-security-samples/grails-spring-security-ajax

Log with warn level:

root(WARN, ['STDOUT']).

When the app starts the next log entry is printed:

2017-04-21 15:31:13.877 WARN --- [ost-startStop-1] o.s.b.GenericTypeAwarePropertyDescriptor : Invalid JavaBean property 'exceptionMappings' being accessed! Ambiguous write methods found next to actually used [public void grails.plugin.springsecurity.web.authentication.AjaxAwareAuthenticationFailureHandler.setExceptionMappings(java.util.List)]: [public void org.springframework.security.web.authentication.ExceptionMappingAuthenticationFailureHandler.setExceptionMappings(java.util.Map)]

@sdelamo
Copy link
Contributor

sdelamo commented Apr 21, 2017

WARN log is throw because:

`AjaxAwareAuthenticationFailureHandler' method signature is:

void setExceptionMappings(List<Map<String, ?>> mappings) {

Ancestor class ExceptionMappingAuthenticationFailureHandler method signature is:

public void setExceptionMappings(Map<?, ?> failureUrlMap) {

grails.plugin.springsecurity.failureHandler.exceptionMappingsconfiguration parameter is documented as a List of Maps.

On solution to remove this warning entry would be to change the configuration parameter to be a map instead of a list of maps.

@ddelponte
Copy link
Contributor

Closing because this was tagged as "Won't Fix" on April 21, 2017.

@ddelponte
Copy link
Contributor

Reopening based on comment from virtualdogbert in slack:
Comment below:

I'm seeing the following warning, and it's just kind of annoying, but doesn't seem to break anything:
WARN o.s.b.GenericTypeAwarePropertyDescriptor - Invalid JavaBean property 'exceptionMappings' being accessed! Ambiguous write methods found next to actually used [public void grails.plugin.springsecurity.web.authentication.AjaxAwareAuthenticationFailureHandler.setExceptionMappings(java.util.List)]: [public void org.springframework.security.web.authentication.ExceptionMappingAuthenticationFailureHandler.setExceptionMappings(java.util.Map)]

So looking this up I found this issue:
#459

In my app I'm not setting failureHandler.exceptionMappings, so that would imply that the default in wrong. What should this be so the warning goes away?
Also that solution should get added to the ticket, so others know what should change. Also Since the default is wrong this ticket should not be won't fix, and should be reopened in my opinion.

@ddelponte ddelponte reopened this May 1, 2019
@sdelamo sdelamo removed their assignment Jul 23, 2020
@jamesdh
Copy link
Contributor

jamesdh commented Dec 15, 2020

@jamesdh
Copy link
Contributor

jamesdh commented Dec 15, 2020

It appears the only way around this warning is to change the default setter method to a different name. The Spring team had a related issue at one point when dealing w/ multiple args which they fixed, but for this setter w/ a matching number of args, it's warning appears to be correct.

This is the commit that appears to be the cause of this.

jamesdh added a commit to jamesdh/grails-spring-security-core that referenced this issue Dec 16, 2020
Adds an alternatively named bean setter that serves the exact same purpose, but will avoid tripping the GenericTypeAwarePropertyDescriptor "ambiguous property" warning by default. Also changes the default config names so spring will utilize the new setter by default.

Kept the original around so as to not break any custom defined AjaxAwareAuthenticationFailureHandler.

Fixes grails#459
jamesdh added a commit to jamesdh/grails-spring-security-core that referenced this issue Dec 16, 2020
Adds an alternatively named bean setter that serves the exact same purpose, but will avoid tripping the GenericTypeAwarePropertyDescriptor "ambiguous property" warning by default. Also changes the default config names so spring will utilize the new setter by default.

Kept the original around so as to not break any custom defined AjaxAwareAuthenticationFailureHandler.

Fixes grails#459
bobbywarner pushed a commit that referenced this issue Mar 17, 2021
Adds an alternatively named bean setter that serves the exact same purpose, but will avoid tripping the GenericTypeAwarePropertyDescriptor "ambiguous property" warning by default. Also changes the default config names so spring will utilize the new setter by default.

Kept the original around so as to not break any custom defined AjaxAwareAuthenticationFailureHandler.

Fixes #459
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants