Error on running After startup (Start SSO Java action)

0
Hi all,   I have a question about running the After startup. Part of the after startup is the java action ‘Start SSO’ from the Mendix SAML module. I’ve not faced this problem before, but now I’m running into the problem I can’t deploy on an environment because of ‘Starting application failed’. I’ve added some extra log messages to make a 100% sure the problem is the ‘Start SSO’-java action, and it is (since it is started but not completed). Is there anyone who may have ideas on solving this issue?    Aug 28 16:38:23.297 - INFO - Core: Running after-startup-action... Aug 28 16:38:23.317 - INFO - AS_AfterStartup_Main: MaakGoudseLabelAanAlsNodig completed Aug 28 16:38:23.322 - INFO - AS_AfterStartup_Main: AS_GenereerIngangsdatums completed Aug 28 16:38:23.339 - INFO - Startup: AS_MaakEersteAccountAlsNodig completed Aug 28 16:38:23.353 - INFO - Startup: AS_VergunningTypeOphalenAanmaken completed Aug 28 16:38:23.368 - INFO - Startup: StartDeeplink (true) completed Aug 28 16:38:23.378 - INFO - Startup: Startup_InitialiseDeeplinks completed Aug 28 16:38:23.451 - INFO - Startup: Start SAML Aug 28 16:38:24.574 - INFO - SAML_SSO: Loading urn:oasis:names:tc:SAML:2.0:protocol metadata from /srv/cloud/slots/tr10000/deploy/data/tmp/saml_IdPFile1567003104574.xml Aug 28 16:38:24.762 - CRITICAL - ActionManager: Error in execution of monitored action '{"name":"Oscar.AS_AfterStartup_Main","type":"Microflow"}' (execution id: 462b8759-ad50-4413-b8ba-3ce49cd02b6f, execution type: CUSTOM) Aug 28 16:38:24.763 - CRITICAL - ActionManager: (1/75) java.lang.NoSuchMethodError: org.apache.commons.codec.digest.DigestUtils.sha1Hex([B)Ljava/lang/String; Aug 28 16:38:24.763 - CRITICAL - ActionManager: (2/75) #011at saml20goudse.implementation.security.SecurityHelper.addAllToKeyStore(SecurityHelper.java:273) Aug 28 16:38:24.763 - CRITICAL - ActionManager: (3/75) #011at saml20goudse.implementation.security.SecurityHelper.appendToIdPKeyStore(SecurityHelper.java:254) Aug 28 16:38:24.763 - CRITICAL - ActionManager: (4/75) #011at saml20goudse.implementation.security.CredentialRepository.setupTrustStore(CredentialRepository.java:180) Aug 28 16:38:24.763 - CRITICAL - ActionManager: (5/75) #011at saml20goudse.implementation.security.CredentialRepository.updateConfiguration(CredentialRepository.java:95) Aug 28 16:38:24.763 - CRITICAL - ActionManager: (6/75) #011at saml20goudse.implementation.SAMLRequestHandler.initServlet(SAMLRequestHandler.java:103) Aug 28 16:38:24.763 - CRITICAL - ActionManager: (7/75) #011at saml20goudse.implementation.SAMLRequestHandler.<init>(SAMLRequestHandler.java:67) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (8/75) #011at saml20goudse.implementation.SAMLRequestHandler.getInstance(SAMLRequestHandler.java:59) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (9/75) #011at saml20goudse.implementation.SSOServerConfiguration.start(SSOServerConfiguration.java:18) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (10/75) #011at saml20goudse.actions.StartSSO.executeAction(StartSSO.java:27) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (11/75) #011at saml20goudse.actions.StartSSO.executeAction(StartSSO.java:16) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (12/75) #011at com.mendix.systemwideinterfaces.core.UserAction.execute(UserAction.java:46) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (13/75) #011at com.mendix.basis.actionmanagement.CoreActionHandlerImpl.doCall(CoreActionHandlerImpl.scala:79) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (14/75) #011at com.mendix.basis.actionmanagement.CoreActionHandlerImpl.call(CoreActionHandlerImpl.scala:57) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (15/75) #011at com.mendix.core.actionmanagement.CoreAction.call(CoreAction.java:55) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (16/75) #011at com.mendix.basis.actionmanagement.ActionManagerBase$1.execute(ActionManagerBase.java:150) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (17/75) #011at com.mendix.util.classloading.Runner.doRunUsingClassLoaderOf(Runner.java:32) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (18/75) #011at com.mendix.basis.actionmanagement.ActionManagerBase.executeSync(ActionManagerBase.java:155) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (19/75) #011at com.mendix.basis.component.InternalCoreBase.execute(InternalCoreBase.java:414) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (20/75) #011at com.mendix.modules.microflowengine.actions.actioncall.JavaAction.execute(JavaAction.scala:56) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (21/75) #011at com.mendix.modules.microflowengine.microflow.impl.MicroflowObject.execute(MicroflowObject.java:47) Aug 28 16:38:24.764 - CRITICAL - ActionManager: (22/75) #011at  
asked
4 answers
1

Hi Vianey,

I also had this problem some time ago and for me it helped to clean dulpicate jar files, which can be found in your userlib. You can see in the error 'java.lang.NoSuchMethodError: org.apache.commons.codec...’, so perhaps you have got multiple versions of this jar file. Note that you can have the commons.codec-{version}.jar and org.apache.commons.codec-{version} which can also conflict with eachother. See for example this post to see how to cleanup your jar files https://forum.mendix.com/link/questions/92900

answered
1

Hi Vianey, That sounds indeed very weared, but I don't now how it is compiled and wheter this can go wrong 'randomly’. However, it can never hurt to check your jar files. Just check whether you find multiple commons.codec (also with org.apache in front) versions in your userlib and delete the old one. Also see this forum post with the same issue: https://forum.mendix.com/link/questions/86721

answered
0

Hi Johan,

 

Thank you for the suggestion! I forgot to add a bit of, maybe very important, context: I get this error when I'm deploying this on my Acceptance Environment. When deploying the exact same deployment package on my Test Environment, there are no issues. With this added context, together with your suggestion, what pops up in my mind is: If it indeed would be an error because of duplicated jar files, the same would happen when deploying on my Test Environment right? Or am I wrong on this one, what are your thoughts on this?

answered
0

Hi Johan, sorry this reaction is a little bit late. Meanwhile we did some research and looked at other possibilities which may could be the reason of the error but it looks your suggestion was right. A new version of the same software, but with a cleaned userlib folder without older jar files is deployable on the environment. We’re doing a little bit more research because we’re curious on how the double files we’re created, but we’ve found the reason so thank you.

answered