1

We have an application using Spring MVC. We recently changed our build process to use Maven 3.0.5 instead of Maven 3.2.3 (there is not a relevant reason for this) and started experiencing exceptions deploying into WebLogic.

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationController': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: protected org.springframework.security.authentication.AuthenticationManager com.es3.ers.controller.AuthenticationController.authManager; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'securityConfig': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: com.es3.ers.filter.AuthenticationTokenProcessingFilter com.es3.ers.config.SecurityConfig.authenticationTokenProcessingFilter; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationTokenProcessingFilter': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: org.springframework.security.authentication.AuthenticationManager com.es3.ers.filter.AuthenticationTokenProcessingFilter.authenticationManager; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'authenticationManager': Requested bean is currently in creation: Is there an unresolvable circular reference?

Some research yielded an issue in our code which we did resolve to get the application working again, but it really got me thinking as to why the Maven version would affect Spring in this way.

I compared the versions built on 3.0.5 and 3.2.3 and other than the timestamps in the MANIFEST file there were no differences. I then looked at the structure of the archive and noticed that the 3.0.5 version had these three (related to the bug) files:

$ unzip -t ers.war | grep -E "(AuthenticationController|AuthenticationTokenProcessingFilter|SecurityConfig)\.class"
    testing: WEB-INF/classes/com/es3/ers/controller/AuthenticationController.class   OK
    testing: WEB-INF/classes/com/es3/ers/filter/AuthenticationTokenProcessingFilter.class   OK
    testing: WEB-INF/classes/com/es3/ers/config/SecurityConfig.class   OK

The 3.2.3 had these same three files:

$  unzip -t ers.war | grep -E "(AuthenticationController|AuthenticationTokenProcessingFilter|SecurityConfig)\.class"
    testing: WEB-INF/classes/com/es3/ers/filter/AuthenticationTokenProcessingFilter.class   OK
    testing: WEB-INF/classes/com/es3/ers/controller/AuthenticationController.class   OK
    testing: WEB-INF/classes/com/es3/ers/config/SecurityConfig.class   OK

You will notice that AuthenticationController is before AuthenticationTokenProcessingFilter from Maven 3.0.5 and in 3.2.3 they are opposite. Out of ideas I extracted the files out of the 3.0.5 archive, removed them and added them back so they were in the same order:

$ unzip ers.war WEB-INF/classes/com/es3/ers/controller/AuthenticationController.class WEB-INF/classes/com/es3/ers/config/SecurityConfig.class
$ zip -d ers.war WEB-INF/classes/com/es3/ers/controller/AuthenticationController.class WEB-INF/classes/com/es3/ers/config/SecurityConfig.class
$ zip -ru ers.war WEB-INF/classes/com/es3/ers/controller/AuthenticationController.class WEB-INF/classes/com/es3/ers/config/SecurityConfig.class
$ unzip -t ers.war | grep -E "(AuthenticationController|AuthenticationTokenProcessingFilter|SecurityConfig)\.class"
        testing: WEB-INF/classes/com/es3/ers/filter/AuthenticationTokenProcessingFilter.class   OK
        testing: WEB-INF/classes/com/es3/ers/controller/AuthenticationController.class   OK
        testing: WEB-INF/classes/com/es3/ers/config/SecurityConfig.class   OK

After the manipulation of the files in the archive we were able to successfully deploy to WebLogic. The fix is obviously to correct the bug in our code, but what is happening here? I counted this as Maven related because it is obviously building the WAR in a very consistent order per version, so it was interesting to me that it changed. Maven 3.0.5 and 3.2.3 are using the same version of the Maven WAR plugin.

Kevin Seymour
  • 766
  • 9
  • 25
  • Please make a full working example project which could be used as base for an analysis.. – khmarbaise Jun 01 '18 at 19:35
  • Furthermore what was the error message in WebLogic with the one which does not work? Are you using the save version of JDK for that build? Have you pinned all plugins which their versions? As you mentioned you code had an issue? Is the order of classes within the archive really relevant? – khmarbaise Jun 01 '18 at 19:42
  • A full working example will be hard to create which is why I tried to keep my question high level. I took the version built on Maven 3.0.5, which errors, re-ordered the classes using zip, and then was able to deploy successfully: the ONLY change was the order the classes are physically present in the archive. The error is included in my original question. We removed an @Autowired reference that wasn't being used in AuthenticationTokenProcessingFilter that was duplicated in AuthenticationController to resolve the issue. – Kevin Seymour Jun 01 '18 at 19:52
  • So in the end it was a code issue not a problem in Maven? Apart from that If can't offer a full example no one will be able to follow that? Furthermore why are you using using an old Maven version? – khmarbaise Jun 01 '18 at 19:56
  • Agree it is a code problem. The question is really around why/ how Maven orders adding classes to the WAR and why Spring would be able to resolve dependencies correctly with one order versus another (could just be a timing thing, but I doubt it). – Kevin Seymour Jun 01 '18 at 19:58
  • We upgraded from RHEL 5.9 to RHEL 7.4 for our build environment and Maven is a standard package in RHEL 7.4 so we opted to use 3.0.5 which ships which the version we have instead of a custom install which we had on RHEL 5.9. I will see about a working example. – Kevin Seymour Jun 01 '18 at 19:59
  • The order of loading classes is based on the classpath (assuming your are running not on JDK9+ modules) and the classes are unique(including the package)..If you have duplicated classes on the class path the order counts..first one wins...means which jar is first on the classpath...If you have upgraded your OS..I assume your JDK has been upgraded as well. I don't like these relations between os and Maven/JDK's cause those cycle are much too long...(most recent version in Maven 3.5.3..) and Maven 3.0.5 is from 2013 ? .... – khmarbaise Jun 01 '18 at 20:03
  • the order not should an issue, it can change for several reasons (including filesystem), this is specified in the JCP like it's mentioned at: https://stackoverflow.com/questions/4466526/order-of-class-loading-from-a-war-file – devwebcl Jun 04 '18 at 23:29

0 Answers0