Details
-
Task
-
Resolution: Done
-
Major
-
None
-
None
Description
[3:44 PM] Kabir Khan: @DarranLofthouse I see this in the logs
[3:44 PM] Kabir Khan: 2017-01-16 15:38:55,589 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.ManagementRealm: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.ManagementRealm: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoSuchMethodError: org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.setDefaultRealm(Ljava/lang/String;)Lorg/wildfly/security/auth/realm/LegacyPropertiesSecurityRealm$Builder;
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:187)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:171)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
... 3 more
[3:44 PM] Kabir Khan: @BrianStansberry perhaps ClientCompatibilityUnitTestCase should be in core rather than full?
[3:47 PM] Darran Lofthouse: @KabirKhan do we have any error as to why it is not up?
[3:47 PM] Kabir Khan: Yes, the NoSuchErrorException
[3:48 PM] Kabir Khan: umm
[3:48 PM] Kabir Khan: I invented a new class
[3:48 PM] Kabir Khan: NoSuchMethodError
[3:48 PM] Kabir Khan: I pasted it above my mention of Brian
[3:49 PM] Kabir Khan: So PropertiesRealmDefinition is calling a non-existent setDefaultRealm() method on LegacyPropertiesSecurityRealm's builder
[3:49 PM] Darran Lofthouse: @KabirKhan if the method doesn't exist that means the wrong Elytron version is being used
[3:50 PM] Kabir Khan: Argh
[3:50 PM] Kabir Khan: I released core without your PR merged
[3:50 PM] Darran Lofthouse: LOL - that would explain how the wrong Elytron version is being used
[3:51 PM] Kabir Khan: ok, I'll try again
[3:53 PM] Brian Stansberry: @KabirKhan perhaps but I bet there was a reason we didn't move it
[3:55 PM] Kabir Khan: On the positive side, it is not the night before the release
[3:58 PM] Brian Stansberry: @KabirKhan if there is such a reason I don't see it in the code for that test
[3:58 PM] Kabir Khan: yeah, me neither
[3:59 PM] Kabir Khan: @BrianStansberry I'll rerelease core to fix my previous error
[3:59 PM] Kabir Khan: but can look into this
[3:59 PM] Kabir Khan: I'll create a Jira so I remember
[3:59 PM] Brian Stansberry: @KabirKhan thanks
[4:00 PM] Kabir Khan: although, I guess in this case it was a good thing
[4:00 PM] Brian Stansberry: @KabirKhan tangent: do you recall if in the mixed domain tests we have the test driver invoke any ops against the legacy slave?
[4:00 PM] Kabir Khan: this was what alerted e to the problem
[4:00 PM] Kabir Khan: @BrianStansberry not off the top of my head, but I'd guess there should be at least some direct read-resource calls
[4:00 PM] Brian Stansberry: @KabirKhan ah, you mean it was something in the full config that failed, that wouldn't be in core?
[4:01 PM] Brian Stansberry: i'd say we shouldn't move that test but instead copy it
[4:01 PM] Kabir Khan: @BrianStansberry there was an update to the elytron subsystem in full calling some stuff in Elytron
[4:02 PM] Kabir Khan: that Elytron stuff wasn't there, because I had forgotten to merge the core PR that brought it in the Elytron upgrade
[4:02 PM] Kabir Khan: so I saw NoSuchMethodErrors