'Invalid bean definition' when migrating Spring Boot 2.0.6 to 2.1.0 with EvaluationContextExtensionSupport...

In Spring Boot 2.1.0 EvaluationContextExtensionSupport is deprecated and https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/query/spi/EvaluationContextExtensionSupport.html says to Implement EvaluationContextExtension directly

Even though it is only deprecated, it instantly starting failing on this upgrade with this stacktrace:

Caused by: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'methodSecurityInterceptor' defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]: Cannot register bean definition [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]] for bean 'methodSecurityInterceptor': There is already [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=methodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [ournamespace/configuration/MethodSecurityConfiguration.class]] bound.

    at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition(DefaultListableBeanFactory.java:894)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:274)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:141)

...and so on

I don't explicitly override this bean, so I'm guessing this is just a side effect of what we're doing in our current code. If I do allow bean overriding with spring.main.allow-bean-definition-overriding=true as per https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.1-Release-Notes#bean-overriding then I simply get another exception.

java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

However, I don't even want to override any bean behavior, the goal is to get a custom permission evaluator working again the way Spring intends it to work.

This is how it did work in the last version:

In Spring Boot 2.0.6 we had the following to get our custom PermissionEvaluator class to work:

A class that extended EvaluationContextExtensionSupport

import org.springframework.data.repository.query.spi.EvaluationContextExtensionSupport;

import org.springframework.security.access.expression.SecurityExpressionRoot;

import org.springframework.security.core.Authentication;

import org.springframework.security.core.context.SecurityContextHolder;



public class SecurityEvaluationContextExtension extends EvaluationContextExtensionSupport {



    @Override

    public String getExtensionId() {

        return "security";

    }



    @Override

    public SecurityExpressionRoot getRootObject() {

        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

            return new SecurityExpressionRoot(authentication) {

        };

    }

}

And then a class where the expression handler is created with our permission evaluator, and with a @Bean with a EvaluationContextExtension

import ournamespace.security.CustomPermissionEvaluator;

import ournamespace.security.SecurityEvaluationContextExtension;

import lombok.RequiredArgsConstructor;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.data.repository.query.spi.EvaluationContextExtension;

import org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler;

import org.springframework.security.access.expression.method.MethodSecurityExpressionHandler;

import org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration;



@Configuration

@RequiredArgsConstructor

public class MethodSecurityConfiguration extends GlobalMethodSecurityConfiguration {



    private final CustomPermissionEvaluator permissionEvaluator;



    @Override

    protected MethodSecurityExpressionHandler createExpressionHandler() {

        DefaultMethodSecurityExpressionHandler expressionHandler =

                new DefaultMethodSecurityExpressionHandler();

        expressionHandler.setPermissionEvaluator(permissionEvaluator);

        return expressionHandler;

    }



    @Bean

    EvaluationContextExtension securityExtension() {

        return new SecurityEvaluationContextExtension();

    }

}

And finally we have this in an otherwise mostly empty class:

@EnableGlobalMethodSecurity(prePostEnabled = true)

public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

   ...

}

This is because the custom permission evaluator never did apply to all methods if we just put this in the MethodSecurityConfiguration class.
The server in question is an oauth2 resource server so we don't configure anything else in the WebSecurityConfigurerAdapter. We also implement our own UserDetails and we extend the DefaultUserAuthenticationConverter, if this is in any way relevant for the new solution.

I have tried implementing EvaluationContextExtension class directly, as stated in the deprecation warning. It's just a simple modification by changing the extends interface to implements EvaluationContextExtension.
I have also tried changing to the seemingly newer package org.springframework.data.spel.spi

I've tried deleting our own SecurityEvaluationContextExtension and returning https://docs.spring.io/spring-security/site/docs/current/api/org/springframework/security/data/repository/query/SecurityEvaluationContextExtension.html as a bean directly but for some reason that data package isn't available in Spring Boot 2.1.0

I've tried just removing the definition of that bean altogether.

All these things result in various 'invalid bean definition' errors on startup.

Does anyone know where to find a migration guide or any other resource on how this is supposed to work now?

Just for reference sake, the actual CustomPermissionEvaluator class:

import ournamespace.configuration.Constants;

import ournamespace.exception.InternalException;

import ournamespace.model.Account;

import ournamespace.model.Member;

import ournamespace.model.Project;

import ournamespace.repository.MemberRepository;

import ournamespace.service.ServiceUtil;

import lombok.RequiredArgsConstructor;

import org.springframework.security.access.PermissionEvaluator;

import org.springframework.security.core.Authentication;

import org.springframework.stereotype.Component;



import java.io.Serializable;



import static ournamespace.model.MemberStatus.JOINED;

import static ournamespace.model.ProjectRole.*;



@RequiredArgsConstructor

@Component

public class CustomPermissionEvaluator implements PermissionEvaluator {



    private final MemberRepository memberRepository;



    @Override

    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {

        if (targetDomainObject == null)

            return false;



        if (!(permission instanceof String))

            return false;



        if (auth == null)

            return false;



        Account account = ServiceUtil.getAccount(auth);



        if (targetDomainObject instanceof Project)

            return hasPermissionOnProject(account, (Project) targetDomainObject, (String) permission);

        //and so on

    }

}

And an example on how it's used:

public interface ProjectRepository extends PagingAndSortingRepository<Project, UUID> {



    @Override

    @PreAuthorize("hasPermission(#project, " + Constants.WRITE + ")")

    <S extends Project> S save(@Param("project") S project);

}

edited Nov 26 '18 at 7:10

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

Can you also add error stack trace?

– Sukhpal Singh
Nov 23 '18 at 15:11

@SukhpalSingh I added a piece of stacktrace that the deprecated code now throws. Stacktraces for all the things I tried would go a bit too far, it's a lengthy post as it is and I have no idea if they made sense.

– Sebastiaan van den Broek
Nov 23 '18 at 15:17

@SebastiaanvandenBroek Going back to your comment about deleting your SecurityEvaluationContextExtension. This bean gets exposed automatically by Spring Boot when the spring-security-data and spring-boot-starter-security dependencies are present. Can you delete your custom class and delete the bean method?

– jzheaux
Nov 28 '18 at 20:49

add a comment |

Even though it is only deprecated, it instantly starting failing on this upgrade with this stacktrace:

Caused by: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'methodSecurityInterceptor' defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]: Cannot register bean definition [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]] for bean 'methodSecurityInterceptor': There is already [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=methodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [ournamespace/configuration/MethodSecurityConfiguration.class]] bound.

    at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition(DefaultListableBeanFactory.java:894)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:274)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:141)

...and so on

java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

However, I don't even want to override any bean behavior, the goal is to get a custom permission evaluator working again the way Spring intends it to work.

This is how it did work in the last version:

In Spring Boot 2.0.6 we had the following to get our custom PermissionEvaluator class to work:

A class that extended EvaluationContextExtensionSupport

import org.springframework.data.repository.query.spi.EvaluationContextExtensionSupport;

import org.springframework.security.access.expression.SecurityExpressionRoot;

import org.springframework.security.core.Authentication;

import org.springframework.security.core.context.SecurityContextHolder;



public class SecurityEvaluationContextExtension extends EvaluationContextExtensionSupport {



    @Override

    public String getExtensionId() {

        return "security";

    }



    @Override

    public SecurityExpressionRoot getRootObject() {

        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

            return new SecurityExpressionRoot(authentication) {

        };

    }

}

And then a class where the expression handler is created with our permission evaluator, and with a @Bean with a EvaluationContextExtension

import ournamespace.security.CustomPermissionEvaluator;

import ournamespace.security.SecurityEvaluationContextExtension;

import lombok.RequiredArgsConstructor;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.data.repository.query.spi.EvaluationContextExtension;

import org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler;

import org.springframework.security.access.expression.method.MethodSecurityExpressionHandler;

import org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration;



@Configuration

@RequiredArgsConstructor

public class MethodSecurityConfiguration extends GlobalMethodSecurityConfiguration {



    private final CustomPermissionEvaluator permissionEvaluator;



    @Override

    protected MethodSecurityExpressionHandler createExpressionHandler() {

        DefaultMethodSecurityExpressionHandler expressionHandler =

                new DefaultMethodSecurityExpressionHandler();

        expressionHandler.setPermissionEvaluator(permissionEvaluator);

        return expressionHandler;

    }



    @Bean

    EvaluationContextExtension securityExtension() {

        return new SecurityEvaluationContextExtension();

    }

}

And finally we have this in an otherwise mostly empty class:

@EnableGlobalMethodSecurity(prePostEnabled = true)

public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

   ...

}

I've tried just removing the definition of that bean altogether.

All these things result in various 'invalid bean definition' errors on startup.

Does anyone know where to find a migration guide or any other resource on how this is supposed to work now?

Just for reference sake, the actual CustomPermissionEvaluator class:

import ournamespace.configuration.Constants;

import ournamespace.exception.InternalException;

import ournamespace.model.Account;

import ournamespace.model.Member;

import ournamespace.model.Project;

import ournamespace.repository.MemberRepository;

import ournamespace.service.ServiceUtil;

import lombok.RequiredArgsConstructor;

import org.springframework.security.access.PermissionEvaluator;

import org.springframework.security.core.Authentication;

import org.springframework.stereotype.Component;



import java.io.Serializable;



import static ournamespace.model.MemberStatus.JOINED;

import static ournamespace.model.ProjectRole.*;



@RequiredArgsConstructor

@Component

public class CustomPermissionEvaluator implements PermissionEvaluator {



    private final MemberRepository memberRepository;



    @Override

    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {

        if (targetDomainObject == null)

            return false;



        if (!(permission instanceof String))

            return false;



        if (auth == null)

            return false;



        Account account = ServiceUtil.getAccount(auth);



        if (targetDomainObject instanceof Project)

            return hasPermissionOnProject(account, (Project) targetDomainObject, (String) permission);

        //and so on

    }

}

And an example on how it's used:

public interface ProjectRepository extends PagingAndSortingRepository<Project, UUID> {



    @Override

    @PreAuthorize("hasPermission(#project, " + Constants.WRITE + ")")

    <S extends Project> S save(@Param("project") S project);

}

edited Nov 26 '18 at 7:10

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

Can you also add error stack trace?

– Sukhpal Singh
Nov 23 '18 at 15:11

@SukhpalSingh I added a piece of stacktrace that the deprecated code now throws. Stacktraces for all the things I tried would go a bit too far, it's a lengthy post as it is and I have no idea if they made sense.

– Sebastiaan van den Broek
Nov 23 '18 at 15:17

@SebastiaanvandenBroek Going back to your comment about deleting your SecurityEvaluationContextExtension. This bean gets exposed automatically by Spring Boot when the spring-security-data and spring-boot-starter-security dependencies are present. Can you delete your custom class and delete the bean method?

– jzheaux
Nov 28 '18 at 20:49

add a comment |

Even though it is only deprecated, it instantly starting failing on this upgrade with this stacktrace:

Caused by: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'methodSecurityInterceptor' defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]: Cannot register bean definition [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]] for bean 'methodSecurityInterceptor': There is already [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=methodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [ournamespace/configuration/MethodSecurityConfiguration.class]] bound.

    at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition(DefaultListableBeanFactory.java:894)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:274)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:141)

...and so on

java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

However, I don't even want to override any bean behavior, the goal is to get a custom permission evaluator working again the way Spring intends it to work.

This is how it did work in the last version:

In Spring Boot 2.0.6 we had the following to get our custom PermissionEvaluator class to work:

A class that extended EvaluationContextExtensionSupport

import org.springframework.data.repository.query.spi.EvaluationContextExtensionSupport;

import org.springframework.security.access.expression.SecurityExpressionRoot;

import org.springframework.security.core.Authentication;

import org.springframework.security.core.context.SecurityContextHolder;



public class SecurityEvaluationContextExtension extends EvaluationContextExtensionSupport {



    @Override

    public String getExtensionId() {

        return "security";

    }



    @Override

    public SecurityExpressionRoot getRootObject() {

        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

            return new SecurityExpressionRoot(authentication) {

        };

    }

}

And then a class where the expression handler is created with our permission evaluator, and with a @Bean with a EvaluationContextExtension

import ournamespace.security.CustomPermissionEvaluator;

import ournamespace.security.SecurityEvaluationContextExtension;

import lombok.RequiredArgsConstructor;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.data.repository.query.spi.EvaluationContextExtension;

import org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler;

import org.springframework.security.access.expression.method.MethodSecurityExpressionHandler;

import org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration;



@Configuration

@RequiredArgsConstructor

public class MethodSecurityConfiguration extends GlobalMethodSecurityConfiguration {



    private final CustomPermissionEvaluator permissionEvaluator;



    @Override

    protected MethodSecurityExpressionHandler createExpressionHandler() {

        DefaultMethodSecurityExpressionHandler expressionHandler =

                new DefaultMethodSecurityExpressionHandler();

        expressionHandler.setPermissionEvaluator(permissionEvaluator);

        return expressionHandler;

    }



    @Bean

    EvaluationContextExtension securityExtension() {

        return new SecurityEvaluationContextExtension();

    }

}

And finally we have this in an otherwise mostly empty class:

@EnableGlobalMethodSecurity(prePostEnabled = true)

public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

   ...

}

I've tried just removing the definition of that bean altogether.

All these things result in various 'invalid bean definition' errors on startup.

Does anyone know where to find a migration guide or any other resource on how this is supposed to work now?

Just for reference sake, the actual CustomPermissionEvaluator class:

import ournamespace.configuration.Constants;

import ournamespace.exception.InternalException;

import ournamespace.model.Account;

import ournamespace.model.Member;

import ournamespace.model.Project;

import ournamespace.repository.MemberRepository;

import ournamespace.service.ServiceUtil;

import lombok.RequiredArgsConstructor;

import org.springframework.security.access.PermissionEvaluator;

import org.springframework.security.core.Authentication;

import org.springframework.stereotype.Component;



import java.io.Serializable;



import static ournamespace.model.MemberStatus.JOINED;

import static ournamespace.model.ProjectRole.*;



@RequiredArgsConstructor

@Component

public class CustomPermissionEvaluator implements PermissionEvaluator {



    private final MemberRepository memberRepository;



    @Override

    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {

        if (targetDomainObject == null)

            return false;



        if (!(permission instanceof String))

            return false;



        if (auth == null)

            return false;



        Account account = ServiceUtil.getAccount(auth);



        if (targetDomainObject instanceof Project)

            return hasPermissionOnProject(account, (Project) targetDomainObject, (String) permission);

        //and so on

    }

}

And an example on how it's used:

public interface ProjectRepository extends PagingAndSortingRepository<Project, UUID> {



    @Override

    @PreAuthorize("hasPermission(#project, " + Constants.WRITE + ")")

    <S extends Project> S save(@Param("project") S project);

}

edited Nov 26 '18 at 7:10

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

Even though it is only deprecated, it instantly starting failing on this upgrade with this stacktrace:

Caused by: org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name 'methodSecurityInterceptor' defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]: Cannot register bean definition [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [org/springframework/security/config/annotation/method/configuration/GlobalMethodSecurityConfiguration.class]] for bean 'methodSecurityInterceptor': There is already [Root bean: class [null]; scope=; abstract=false; lazyInit=false; autowireMode=3; dependencyCheck=0; autowireCandidate=true; primary=false; factoryBeanName=methodSecurityConfiguration; factoryMethodName=methodSecurityInterceptor; initMethodName=null; destroyMethodName=(inferred); defined in class path resource [ournamespace/configuration/MethodSecurityConfiguration.class]] bound.

    at org.springframework.beans.factory.support.DefaultListableBeanFactory.registerBeanDefinition(DefaultListableBeanFactory.java:894)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForBeanMethod(ConfigurationClassBeanDefinitionReader.java:274)

    at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.loadBeanDefinitionsForConfigurationClass(ConfigurationClassBeanDefinitionReader.java:141)

...and so on

java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

However, I don't even want to override any bean behavior, the goal is to get a custom permission evaluator working again the way Spring intends it to work.

This is how it did work in the last version:

In Spring Boot 2.0.6 we had the following to get our custom PermissionEvaluator class to work:

A class that extended EvaluationContextExtensionSupport

import org.springframework.data.repository.query.spi.EvaluationContextExtensionSupport;

import org.springframework.security.access.expression.SecurityExpressionRoot;

import org.springframework.security.core.Authentication;

import org.springframework.security.core.context.SecurityContextHolder;



public class SecurityEvaluationContextExtension extends EvaluationContextExtensionSupport {



    @Override

    public String getExtensionId() {

        return "security";

    }



    @Override

    public SecurityExpressionRoot getRootObject() {

        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

            return new SecurityExpressionRoot(authentication) {

        };

    }

}

And then a class where the expression handler is created with our permission evaluator, and with a @Bean with a EvaluationContextExtension

import ournamespace.security.CustomPermissionEvaluator;

import ournamespace.security.SecurityEvaluationContextExtension;

import lombok.RequiredArgsConstructor;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.data.repository.query.spi.EvaluationContextExtension;

import org.springframework.security.access.expression.method.DefaultMethodSecurityExpressionHandler;

import org.springframework.security.access.expression.method.MethodSecurityExpressionHandler;

import org.springframework.security.config.annotation.method.configuration.GlobalMethodSecurityConfiguration;



@Configuration

@RequiredArgsConstructor

public class MethodSecurityConfiguration extends GlobalMethodSecurityConfiguration {



    private final CustomPermissionEvaluator permissionEvaluator;



    @Override

    protected MethodSecurityExpressionHandler createExpressionHandler() {

        DefaultMethodSecurityExpressionHandler expressionHandler =

                new DefaultMethodSecurityExpressionHandler();

        expressionHandler.setPermissionEvaluator(permissionEvaluator);

        return expressionHandler;

    }



    @Bean

    EvaluationContextExtension securityExtension() {

        return new SecurityEvaluationContextExtension();

    }

}

And finally we have this in an otherwise mostly empty class:

@EnableGlobalMethodSecurity(prePostEnabled = true)

public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {

   ...

}

I've tried just removing the definition of that bean altogether.

All these things result in various 'invalid bean definition' errors on startup.

Does anyone know where to find a migration guide or any other resource on how this is supposed to work now?

Just for reference sake, the actual CustomPermissionEvaluator class:

import ournamespace.configuration.Constants;

import ournamespace.exception.InternalException;

import ournamespace.model.Account;

import ournamespace.model.Member;

import ournamespace.model.Project;

import ournamespace.repository.MemberRepository;

import ournamespace.service.ServiceUtil;

import lombok.RequiredArgsConstructor;

import org.springframework.security.access.PermissionEvaluator;

import org.springframework.security.core.Authentication;

import org.springframework.stereotype.Component;



import java.io.Serializable;



import static ournamespace.model.MemberStatus.JOINED;

import static ournamespace.model.ProjectRole.*;



@RequiredArgsConstructor

@Component

public class CustomPermissionEvaluator implements PermissionEvaluator {



    private final MemberRepository memberRepository;



    @Override

    public boolean hasPermission(Authentication auth, Object targetDomainObject, Object permission) {

        if (targetDomainObject == null)

            return false;



        if (!(permission instanceof String))

            return false;



        if (auth == null)

            return false;



        Account account = ServiceUtil.getAccount(auth);



        if (targetDomainObject instanceof Project)

            return hasPermissionOnProject(account, (Project) targetDomainObject, (String) permission);

        //and so on

    }

}

And an example on how it's used:

public interface ProjectRepository extends PagingAndSortingRepository<Project, UUID> {



    @Override

    @PreAuthorize("hasPermission(#project, " + Constants.WRITE + ")")

    <S extends Project> S save(@Param("project") S project);

}

java spring spring-boot spring-security

edited Nov 26 '18 at 7:10

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

edited Nov 26 '18 at 7:10

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

edited Nov 26 '18 at 7:10

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

asked Nov 21 '18 at 10:52

Sebastiaan van den Broek

3,35331944

Can you also add error stack trace?

– Sukhpal Singh
Nov 23 '18 at 15:11

@SukhpalSingh I added a piece of stacktrace that the deprecated code now throws. Stacktraces for all the things I tried would go a bit too far, it's a lengthy post as it is and I have no idea if they made sense.

– Sebastiaan van den Broek
Nov 23 '18 at 15:17

@SebastiaanvandenBroek Going back to your comment about deleting your SecurityEvaluationContextExtension. This bean gets exposed automatically by Spring Boot when the spring-security-data and spring-boot-starter-security dependencies are present. Can you delete your custom class and delete the bean method?

– jzheaux
Nov 28 '18 at 20:49

add a comment |

Can you also add error stack trace?

– Sukhpal Singh
Nov 23 '18 at 15:11

@SukhpalSingh I added a piece of stacktrace that the deprecated code now throws. Stacktraces for all the things I tried would go a bit too far, it's a lengthy post as it is and I have no idea if they made sense.

– Sebastiaan van den Broek
Nov 23 '18 at 15:17

@SebastiaanvandenBroek Going back to your comment about deleting your SecurityEvaluationContextExtension. This bean gets exposed automatically by Spring Boot when the spring-security-data and spring-boot-starter-security dependencies are present. Can you delete your custom class and delete the bean method?

– jzheaux
Nov 28 '18 at 20:49

Can you also add error stack trace?

– Sukhpal Singh
Nov 23 '18 at 15:11

@SukhpalSingh I added a piece of stacktrace that the deprecated code now throws. Stacktraces for all the things I tried would go a bit too far, it's a lengthy post as it is and I have no idea if they made sense.

– Sebastiaan van den Broek
Nov 23 '18 at 15:17

@SebastiaanvandenBroek Going back to your comment about deleting your SecurityEvaluationContextExtension. This bean gets exposed automatically by Spring Boot when the spring-security-data and spring-boot-starter-security dependencies are present. Can you delete your custom class and delete the bean method?

– jzheaux
Nov 28 '18 at 20:49

add a comment |

2 Answers
2

active

oldest

votes

+50

I took your code and created a sample app from it. I posted it here:

https://github.com/jzheaux/stackoverflow-53410526

Your @EnableGlobalMethodSecurity annotation is on WebSecurityConfigurerAdapter. You also have a class that extends GlobalMethodSecurityConfiguration. This can cause some ordering issues at startup at times, which may be what you are seeing => two MethodSecurityExpressionHandlers get created as well as two EvaluationContextExtensions.

Whether this is precisely the case or not (I'm guessing that it is), when I matched your @EnableGlobalMethodSecurity with your custom GlobalMethodSecurityConfiguration, things started up fine.

Also, though, it seems that your custom EvaluationContextExtension is very similar to the Spring Security default. You might consider removing that class as well as the corresponding bean method, if you can, since Spring Boot exposes one automatically when you have spring-boot-starter-security and spring-security-data as dependencies.

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

Thanks for your effort, I will have a look and try some suggestions. We had to put our @EnableGlobalMethodSecurity on that WebSecurityConfigurerAdapter because otherwise for random repositories it would not trigger the custom PermissionEvaluator. This was when we were still using Spring Data Rest though. You can see my self-answered question at stackoverflow.com/a/48868723/144578 if interested.

– Sebastiaan van den Broek
Nov 29 '18 at 1:57

Ignore what I said on the custom PermissionEvaluator not triggering on random repositories. It's not triggered if I move the @EnableGlobalMethodSecurity annotation, full stop. I just didn't notice on other repo's because there it wasn't needed to apply security correctly, as there it was already done at the time of retrieving the entity from the database.

– Sebastiaan van den Broek
Nov 29 '18 at 2:45

How would you suggest I should be registering a custom PermissionEvaluator the idiomatic way, in such a way that it is triggered for every method call regardless of how it enters the application?

– Sebastiaan van den Broek
Nov 29 '18 at 2:57

Just to be clear, I can confirm that the CustomPermissionEvaluator in the posted project does indeed get invoked when invoking ProjectRepository#save. If all you need to do is customize the permission evaluator, though, you can expose it as a bean, and Spring Security will pick it up, i.e. delete MethodSecurityConfiguration.java. You will still need to have PreAuthorize either way, though. It won't be triggered for "every method" in the application.

– jzheaux
Nov 29 '18 at 18:16

1

Okay, @SebastiaanvandenBroek, don't hesitate to ping me on Gitter next time you get time to try again. I try to hang out there every now and again.

– jzheaux
Nov 30 '18 at 4:17

|
show 4 more comments

You're overriding methodSecurityInterceptor bean. It was working previously as bean overriding was allowed.

Bean overriding has been disabled by default to prevent a bean being accidentally overridden. If you are relying on overriding, you will need to set spring.main.allow-bean-definition-overriding to true.

Spring-Boot-2.1-Release-Notes#bean-overriding

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

I am not directly overriding this bean, it’s a result of the combination of things we’re doing. I would prefer not to turn a switch and have a workaround that may or may not work for a while, but to truly get rid of @Deprecated code and find a way to make this work the way it is supposed to in this new version of Spring Boot.

– Sebastiaan van den Broek
Nov 23 '18 at 16:02

@SebastiaanvandenBroek I think current error you're facing isn't related to any other upgrade(s) in boot. Maybe downgrading then checking logs will help you to check whether you were overriding bean earlier too. But did it work after setting this property?

– Sukhpal Singh
Nov 23 '18 at 16:11

It is related to this, absolutely. I only changed the version from 2.0.1 to 2.1.0. Honestly I don't even want to try overriding something that isn't standard, because these classes are also deprecated and bound to disappear. I am sure there is a way in Spring to still have this kind of more fine-grained method security and I want to use that in the idiomatic way.

– Sebastiaan van den Broek
Nov 23 '18 at 16:17

Alright, just to give it a shot I did try setting that property. That just means the exception changes to java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Is EvaluationContextExtension bean still present or no? It would be helpful to provide sample project and a test case

– Sukhpal Singh
Nov 23 '18 at 16:35

|
show 1 more comment

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53410526%2finvalid-bean-definition-when-migrating-spring-boot-2-0-6-to-2-1-0-with-evaluat%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

+50

I took your code and created a sample app from it. I posted it here:

https://github.com/jzheaux/stackoverflow-53410526

Whether this is precisely the case or not (I'm guessing that it is), when I matched your @EnableGlobalMethodSecurity with your custom GlobalMethodSecurityConfiguration, things started up fine.

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

Thanks for your effort, I will have a look and try some suggestions. We had to put our @EnableGlobalMethodSecurity on that WebSecurityConfigurerAdapter because otherwise for random repositories it would not trigger the custom PermissionEvaluator. This was when we were still using Spring Data Rest though. You can see my self-answered question at stackoverflow.com/a/48868723/144578 if interested.

– Sebastiaan van den Broek
Nov 29 '18 at 1:57

Ignore what I said on the custom PermissionEvaluator not triggering on random repositories. It's not triggered if I move the @EnableGlobalMethodSecurity annotation, full stop. I just didn't notice on other repo's because there it wasn't needed to apply security correctly, as there it was already done at the time of retrieving the entity from the database.

– Sebastiaan van den Broek
Nov 29 '18 at 2:45

How would you suggest I should be registering a custom PermissionEvaluator the idiomatic way, in such a way that it is triggered for every method call regardless of how it enters the application?

– Sebastiaan van den Broek
Nov 29 '18 at 2:57

Just to be clear, I can confirm that the CustomPermissionEvaluator in the posted project does indeed get invoked when invoking ProjectRepository#save. If all you need to do is customize the permission evaluator, though, you can expose it as a bean, and Spring Security will pick it up, i.e. delete MethodSecurityConfiguration.java. You will still need to have PreAuthorize either way, though. It won't be triggered for "every method" in the application.

– jzheaux
Nov 29 '18 at 18:16

1

Okay, @SebastiaanvandenBroek, don't hesitate to ping me on Gitter next time you get time to try again. I try to hang out there every now and again.

– jzheaux
Nov 30 '18 at 4:17

|
show 4 more comments

+50

I took your code and created a sample app from it. I posted it here:

https://github.com/jzheaux/stackoverflow-53410526

Whether this is precisely the case or not (I'm guessing that it is), when I matched your @EnableGlobalMethodSecurity with your custom GlobalMethodSecurityConfiguration, things started up fine.

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

Thanks for your effort, I will have a look and try some suggestions. We had to put our @EnableGlobalMethodSecurity on that WebSecurityConfigurerAdapter because otherwise for random repositories it would not trigger the custom PermissionEvaluator. This was when we were still using Spring Data Rest though. You can see my self-answered question at stackoverflow.com/a/48868723/144578 if interested.

– Sebastiaan van den Broek
Nov 29 '18 at 1:57

Ignore what I said on the custom PermissionEvaluator not triggering on random repositories. It's not triggered if I move the @EnableGlobalMethodSecurity annotation, full stop. I just didn't notice on other repo's because there it wasn't needed to apply security correctly, as there it was already done at the time of retrieving the entity from the database.

– Sebastiaan van den Broek
Nov 29 '18 at 2:45

How would you suggest I should be registering a custom PermissionEvaluator the idiomatic way, in such a way that it is triggered for every method call regardless of how it enters the application?

– Sebastiaan van den Broek
Nov 29 '18 at 2:57

Just to be clear, I can confirm that the CustomPermissionEvaluator in the posted project does indeed get invoked when invoking ProjectRepository#save. If all you need to do is customize the permission evaluator, though, you can expose it as a bean, and Spring Security will pick it up, i.e. delete MethodSecurityConfiguration.java. You will still need to have PreAuthorize either way, though. It won't be triggered for "every method" in the application.

– jzheaux
Nov 29 '18 at 18:16

1

Okay, @SebastiaanvandenBroek, don't hesitate to ping me on Gitter next time you get time to try again. I try to hang out there every now and again.

– jzheaux
Nov 30 '18 at 4:17

|
show 4 more comments

+50

I took your code and created a sample app from it. I posted it here:

https://github.com/jzheaux/stackoverflow-53410526

Whether this is precisely the case or not (I'm guessing that it is), when I matched your @EnableGlobalMethodSecurity with your custom GlobalMethodSecurityConfiguration, things started up fine.

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

I took your code and created a sample app from it. I posted it here:

https://github.com/jzheaux/stackoverflow-53410526

Whether this is precisely the case or not (I'm guessing that it is), when I matched your @EnableGlobalMethodSecurity with your custom GlobalMethodSecurityConfiguration, things started up fine.

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

answered Nov 28 '18 at 21:52

jzheaux

2,5042921

Thanks for your effort, I will have a look and try some suggestions. We had to put our @EnableGlobalMethodSecurity on that WebSecurityConfigurerAdapter because otherwise for random repositories it would not trigger the custom PermissionEvaluator. This was when we were still using Spring Data Rest though. You can see my self-answered question at stackoverflow.com/a/48868723/144578 if interested.

– Sebastiaan van den Broek
Nov 29 '18 at 1:57

Ignore what I said on the custom PermissionEvaluator not triggering on random repositories. It's not triggered if I move the @EnableGlobalMethodSecurity annotation, full stop. I just didn't notice on other repo's because there it wasn't needed to apply security correctly, as there it was already done at the time of retrieving the entity from the database.

– Sebastiaan van den Broek
Nov 29 '18 at 2:45

How would you suggest I should be registering a custom PermissionEvaluator the idiomatic way, in such a way that it is triggered for every method call regardless of how it enters the application?

– Sebastiaan van den Broek
Nov 29 '18 at 2:57

Just to be clear, I can confirm that the CustomPermissionEvaluator in the posted project does indeed get invoked when invoking ProjectRepository#save. If all you need to do is customize the permission evaluator, though, you can expose it as a bean, and Spring Security will pick it up, i.e. delete MethodSecurityConfiguration.java. You will still need to have PreAuthorize either way, though. It won't be triggered for "every method" in the application.

– jzheaux
Nov 29 '18 at 18:16

1

Okay, @SebastiaanvandenBroek, don't hesitate to ping me on Gitter next time you get time to try again. I try to hang out there every now and again.

– jzheaux
Nov 30 '18 at 4:17

|
show 4 more comments

Thanks for your effort, I will have a look and try some suggestions. We had to put our @EnableGlobalMethodSecurity on that WebSecurityConfigurerAdapter because otherwise for random repositories it would not trigger the custom PermissionEvaluator. This was when we were still using Spring Data Rest though. You can see my self-answered question at stackoverflow.com/a/48868723/144578 if interested.

– Sebastiaan van den Broek
Nov 29 '18 at 1:57

Ignore what I said on the custom PermissionEvaluator not triggering on random repositories. It's not triggered if I move the @EnableGlobalMethodSecurity annotation, full stop. I just didn't notice on other repo's because there it wasn't needed to apply security correctly, as there it was already done at the time of retrieving the entity from the database.

– Sebastiaan van den Broek
Nov 29 '18 at 2:45

How would you suggest I should be registering a custom PermissionEvaluator the idiomatic way, in such a way that it is triggered for every method call regardless of how it enters the application?

– Sebastiaan van den Broek
Nov 29 '18 at 2:57

Just to be clear, I can confirm that the CustomPermissionEvaluator in the posted project does indeed get invoked when invoking ProjectRepository#save. If all you need to do is customize the permission evaluator, though, you can expose it as a bean, and Spring Security will pick it up, i.e. delete MethodSecurityConfiguration.java. You will still need to have PreAuthorize either way, though. It won't be triggered for "every method" in the application.

– jzheaux
Nov 29 '18 at 18:16

1

Okay, @SebastiaanvandenBroek, don't hesitate to ping me on Gitter next time you get time to try again. I try to hang out there every now and again.

– jzheaux
Nov 30 '18 at 4:17

Thanks for your effort, I will have a look and try some suggestions. We had to put our @EnableGlobalMethodSecurity on that WebSecurityConfigurerAdapter because otherwise for random repositories it would not trigger the custom PermissionEvaluator. This was when we were still using Spring Data Rest though. You can see my self-answered question at stackoverflow.com/a/48868723/144578 if interested.

– Sebastiaan van den Broek
Nov 29 '18 at 1:57

Ignore what I said on the custom PermissionEvaluator not triggering on random repositories. It's not triggered if I move the @EnableGlobalMethodSecurity annotation, full stop. I just didn't notice on other repo's because there it wasn't needed to apply security correctly, as there it was already done at the time of retrieving the entity from the database.

– Sebastiaan van den Broek
Nov 29 '18 at 2:45

How would you suggest I should be registering a custom PermissionEvaluator the idiomatic way, in such a way that it is triggered for every method call regardless of how it enters the application?

– Sebastiaan van den Broek
Nov 29 '18 at 2:57

Just to be clear, I can confirm that the CustomPermissionEvaluator in the posted project does indeed get invoked when invoking ProjectRepository#save. If all you need to do is customize the permission evaluator, though, you can expose it as a bean, and Spring Security will pick it up, i.e. delete MethodSecurityConfiguration.java. You will still need to have PreAuthorize either way, though. It won't be triggered for "every method" in the application.

– jzheaux
Nov 29 '18 at 18:16

Okay, @SebastiaanvandenBroek, don't hesitate to ping me on Gitter next time you get time to try again. I try to hang out there every now and again.

– jzheaux
Nov 30 '18 at 4:17

|
show 4 more comments

You're overriding methodSecurityInterceptor bean. It was working previously as bean overriding was allowed.

Bean overriding has been disabled by default to prevent a bean being accidentally overridden. If you are relying on overriding, you will need to set spring.main.allow-bean-definition-overriding to true.

Spring-Boot-2.1-Release-Notes#bean-overriding

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

I am not directly overriding this bean, it’s a result of the combination of things we’re doing. I would prefer not to turn a switch and have a workaround that may or may not work for a while, but to truly get rid of @Deprecated code and find a way to make this work the way it is supposed to in this new version of Spring Boot.

– Sebastiaan van den Broek
Nov 23 '18 at 16:02

@SebastiaanvandenBroek I think current error you're facing isn't related to any other upgrade(s) in boot. Maybe downgrading then checking logs will help you to check whether you were overriding bean earlier too. But did it work after setting this property?

– Sukhpal Singh
Nov 23 '18 at 16:11

It is related to this, absolutely. I only changed the version from 2.0.1 to 2.1.0. Honestly I don't even want to try overriding something that isn't standard, because these classes are also deprecated and bound to disappear. I am sure there is a way in Spring to still have this kind of more fine-grained method security and I want to use that in the idiomatic way.

– Sebastiaan van den Broek
Nov 23 '18 at 16:17

Alright, just to give it a shot I did try setting that property. That just means the exception changes to java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Is EvaluationContextExtension bean still present or no? It would be helpful to provide sample project and a test case

– Sukhpal Singh
Nov 23 '18 at 16:35

|
show 1 more comment

You're overriding methodSecurityInterceptor bean. It was working previously as bean overriding was allowed.

Bean overriding has been disabled by default to prevent a bean being accidentally overridden. If you are relying on overriding, you will need to set spring.main.allow-bean-definition-overriding to true.

Spring-Boot-2.1-Release-Notes#bean-overriding

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

I am not directly overriding this bean, it’s a result of the combination of things we’re doing. I would prefer not to turn a switch and have a workaround that may or may not work for a while, but to truly get rid of @Deprecated code and find a way to make this work the way it is supposed to in this new version of Spring Boot.

– Sebastiaan van den Broek
Nov 23 '18 at 16:02

@SebastiaanvandenBroek I think current error you're facing isn't related to any other upgrade(s) in boot. Maybe downgrading then checking logs will help you to check whether you were overriding bean earlier too. But did it work after setting this property?

– Sukhpal Singh
Nov 23 '18 at 16:11

It is related to this, absolutely. I only changed the version from 2.0.1 to 2.1.0. Honestly I don't even want to try overriding something that isn't standard, because these classes are also deprecated and bound to disappear. I am sure there is a way in Spring to still have this kind of more fine-grained method security and I want to use that in the idiomatic way.

– Sebastiaan van den Broek
Nov 23 '18 at 16:17

Alright, just to give it a shot I did try setting that property. That just means the exception changes to java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Is EvaluationContextExtension bean still present or no? It would be helpful to provide sample project and a test case

– Sukhpal Singh
Nov 23 '18 at 16:35

|
show 1 more comment

You're overriding methodSecurityInterceptor bean. It was working previously as bean overriding was allowed.

Bean overriding has been disabled by default to prevent a bean being accidentally overridden. If you are relying on overriding, you will need to set spring.main.allow-bean-definition-overriding to true.

Spring-Boot-2.1-Release-Notes#bean-overriding

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

You're overriding methodSecurityInterceptor bean. It was working previously as bean overriding was allowed.

Bean overriding has been disabled by default to prevent a bean being accidentally overridden. If you are relying on overriding, you will need to set spring.main.allow-bean-definition-overriding to true.

Spring-Boot-2.1-Release-Notes#bean-overriding

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

answered Nov 23 '18 at 15:46

Sukhpal Singh

899210

I am not directly overriding this bean, it’s a result of the combination of things we’re doing. I would prefer not to turn a switch and have a workaround that may or may not work for a while, but to truly get rid of @Deprecated code and find a way to make this work the way it is supposed to in this new version of Spring Boot.

– Sebastiaan van den Broek
Nov 23 '18 at 16:02

@SebastiaanvandenBroek I think current error you're facing isn't related to any other upgrade(s) in boot. Maybe downgrading then checking logs will help you to check whether you were overriding bean earlier too. But did it work after setting this property?

– Sukhpal Singh
Nov 23 '18 at 16:11

It is related to this, absolutely. I only changed the version from 2.0.1 to 2.1.0. Honestly I don't even want to try overriding something that isn't standard, because these classes are also deprecated and bound to disappear. I am sure there is a way in Spring to still have this kind of more fine-grained method security and I want to use that in the idiomatic way.

– Sebastiaan van den Broek
Nov 23 '18 at 16:17

Alright, just to give it a shot I did try setting that property. That just means the exception changes to java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Is EvaluationContextExtension bean still present or no? It would be helpful to provide sample project and a test case

– Sukhpal Singh
Nov 23 '18 at 16:35

|
show 1 more comment

I am not directly overriding this bean, it’s a result of the combination of things we’re doing. I would prefer not to turn a switch and have a workaround that may or may not work for a while, but to truly get rid of @Deprecated code and find a way to make this work the way it is supposed to in this new version of Spring Boot.

– Sebastiaan van den Broek
Nov 23 '18 at 16:02

@SebastiaanvandenBroek I think current error you're facing isn't related to any other upgrade(s) in boot. Maybe downgrading then checking logs will help you to check whether you were overriding bean earlier too. But did it work after setting this property?

– Sukhpal Singh
Nov 23 '18 at 16:11

It is related to this, absolutely. I only changed the version from 2.0.1 to 2.1.0. Honestly I don't even want to try overriding something that isn't standard, because these classes are also deprecated and bound to disappear. I am sure there is a way in Spring to still have this kind of more fine-grained method security and I want to use that in the idiomatic way.

– Sebastiaan van den Broek
Nov 23 '18 at 16:17

Alright, just to give it a shot I did try setting that property. That just means the exception changes to java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Is EvaluationContextExtension bean still present or no? It would be helpful to provide sample project and a test case

– Sukhpal Singh
Nov 23 '18 at 16:35

I am not directly overriding this bean, it’s a result of the combination of things we’re doing. I would prefer not to turn a switch and have a workaround that may or may not work for a while, but to truly get rid of @Deprecated code and find a way to make this work the way it is supposed to in this new version of Spring Boot.

– Sebastiaan van den Broek
Nov 23 '18 at 16:02

@SebastiaanvandenBroek I think current error you're facing isn't related to any other upgrade(s) in boot. Maybe downgrading then checking logs will help you to check whether you were overriding bean earlier too. But did it work after setting this property?

– Sukhpal Singh
Nov 23 '18 at 16:11

It is related to this, absolutely. I only changed the version from 2.0.1 to 2.1.0. Honestly I don't even want to try overriding something that isn't standard, because these classes are also deprecated and bound to disappear. I am sure there is a way in Spring to still have this kind of more fine-grained method security and I want to use that in the idiomatic way.

– Sebastiaan van den Broek
Nov 23 '18 at 16:17

Alright, just to give it a shot I did try setting that property. That just means the exception changes to

java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb 	at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Alright, just to give it a shot I did try setting that property. That just means the exception changes to

java.lang.IllegalStateException: Duplicate key org.springframework.data.spel.ExtensionAwareEvaluationContextProvider$EvaluationContextExtensionAdapter@10dfbbbb 	at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) ~[na:1.8.0_162]

– Sebastiaan van den Broek
Nov 23 '18 at 16:21

Is EvaluationContextExtension bean still present or no? It would be helpful to provide sample project and a test case

– Sukhpal Singh
Nov 23 '18 at 16:35

|
show 1 more comment

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu