1

I had to migrate an old JHipster app to JHipster 5.0 beta 0 to address several bugs, and while I was at it I tried to add the JHipster Registry to it (the app was load-balanced, with a Hazelcast cache).

The new 5.0 app never completely started and seemed to be locked right after Hazelcast configuration. The last log lines were :

2018-04-12 16:04:03.317  INFO 4160 --- [  restartedMain] com.hazelcast.core.LifecycleService      : [172.17.0.1]:5701 [dev] [3.9.3] [172.17.0.1]:5701 is STARTING
2018-04-12 16:04:03.378  WARN 4160 --- [  restartedMain] com.hazelcast.instance.Node              : [172.17.0.1]:5701 [dev] [3.9.3] No join method is enabled! Starting standalone.
2018-04-12 16:04:03.379  INFO 4160 --- [  restartedMain] com.hazelcast.system                     : [172.17.0.1]:5701 [dev] [3.9.3] Cluster version set to 3.9
2018-04-12 16:04:03.425  INFO 4160 --- [  restartedMain] com.hazelcast.core.LifecycleService      : [172.17.0.1]:5701 [dev] [3.9.3] [172.17.0.1]:5701 is STARTED

After further investigations, I created two barebone monolithic applications with JHipster, one with the registry and one without. Then I added the following configuration class in both projects :

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class SecurityConfigurationAdditional extends GlobalMethodSecurityConfiguration {

    @Autowired
    private UserRepository userRepository;

    @Override
    protected MethodSecurityExpressionHandler createExpressionHandler() {
        return null;
    }
}

The project without the Registry worked as expected, but the other project (with the Registry) locked the same way.

The responsible for this seems to be the autowired UserRepository, since when I comment out this one, the project with the registry works as well. The culprit has to be Netflix Eureka and/or Spring cloud, they are the only difference between my two projects.

Did anyone saw this kind of behaviour ?

0 Answers0