Forum Discussion

jstrauss64's avatar
jstrauss64
Occasional Contributor
9 years ago
Solved

call to jms fails after upgrade

I upgraded to 1.5 yesterday and now some tests are not running. Specifically, any tests that include a call to JMS is failing.

 

In the ready-api-errors.log file I get this:

 

2015-11-12 11:32:06,261 ERROR [errorlog] java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
    at weblogic.security.service.SubjectManagerImpl.initializeKernelID(SubjectManagerImpl.java:293)
    at weblogic.security.service.SubjectManagerImpl.<clinit>(SubjectManagerImpl.java:29)
    at weblogic.security.service.SecurityManager.<clinit>(SecurityManager.java:24)
    at weblogic.security.service.GetKernelIdentityAction.run(GetKernelIdentityAction.java:25)
    at java.security.AccessController.doPrivileged(Native Method)
    at weblogic.jndi.WLSJNDIEnvironmentImpl.<clinit>(WLSJNDIEnvironmentImpl.java:57)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Unknown Source)
    at weblogic.jndi.internal.JNDIEnvironment.getJNDIEnvironment(JNDIEnvironment.java:33)
    at weblogic.jndi.Environment.<clinit>(Environment.java:89)
    at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:117)
    at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
    at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
    at javax.naming.InitialContext.init(Unknown Source)
    at javax.naming.InitialContext.<init>(Unknown Source)
    at hermes.JNDIContextFactory.createContext(JNDIContextFactory.java:261)
    at hermes.JNDIConnectionFactory.createConnection(JNDIConnectionFactory.java:80)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.JMSConnectionHolder.createConnection(JMSConnectionHolder.java:87)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.HermesJmsRequestSendTransport.execute(HermesJmsRequestSendTransport.java:37)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.HermesJmsRequestTransport.sendRequest(HermesJmsRequestTransport.java:98)
    at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.SecurityException: sealing violation: can't seal package javax.security.auth: already loaded
    at java.net.URLClassLoader.getAndVerifyPackage(Unknown Source)
    at java.net.URLClassLoader.definePackageInternal(Unknown Source)
    at java.net.URLClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.access$100(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.util.HermesUtils$ReverseOrderClassLoader.innerLoadClass(HermesUtils.java:332)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.util.HermesUtils$ReverseOrderClassLoader.loadClass(HermesUtils.java:319)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at hermes.impl.LoaderSupport$DebugClassLoader.loadClass(LoaderSupport.java:99)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at weblogic.security.acl.internal.AuthenticatedSubject.<init>(AuthenticatedSubject.java:101)
    at weblogic.security.acl.internal.AuthenticatedSubject.<clinit>(AuthenticatedSubject.java:39)
    ... 26 more

 

And in the ready-api.log I get this:

2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-imq.jar for hermes.ext.imq.ImqAdminFactory
2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-aq.jar for hermes.ext.oracle.aq.OracleAQAdminFactory
2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-ems.jar for hermes.ext.ems.TibcoEMSAdminFactory
2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-webspheremq.jar for hermes.ext.mq.MQSeriesAdminFactory
2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-jbossmq.jar for hermes.ext.jbossmq.JBossMQAdminFactory
2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-arjuna.jar for hermes.ext.arjuna.ArjunaMSAdminFactory
2015-11-12 11:32:06,013 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-weblogic.jar for hermes.ext.weblogic.WebLogicJMSAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-joram.jar for hermes.ext.joram.JoramAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-wme.jar for hermes.ext.wme.WMEAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-openjms.jar for hermes.ext.openjms.OpenJMSAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-fiorano.jar for hermes.ext.fiorano.FioranoAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-sonicmq.jar for hermes.ext.sonicmq.SonicMQAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-sapjms.jar for hermes.ext.sap.SAPJMSAdminFactory
2015-11-12 11:32:06,014 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-activemq.jar for hermes.ext.activemq.ActiveMQAdminFactory
2015-11-12 11:32:06,015 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-seebeyond.jar for hermes.ext.seebeyond.ican.SeeBeyondICANAdminFactory
2015-11-12 11:32:06,015 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-seebeyond.jar for hermes.ext.seebeyond.jcaps.SeeBeyondJCAPSAdminFactory
2015-11-12 11:32:06,015 ERROR [ConfigDAOImpl] cannot find ../lib/hermes-sapjms.jar for hermes.ext.sap.SAPJMSAdminFactory
2015-11-12 11:32:06,261 ERROR [errorlog] java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
    at weblogic.security.service.SubjectManagerImpl.initializeKernelID(SubjectManagerImpl.java:293)
    at weblogic.security.service.SubjectManagerImpl.<clinit>(SubjectManagerImpl.java:29)
    at weblogic.security.service.SecurityManager.<clinit>(SecurityManager.java:24)
    at weblogic.security.service.GetKernelIdentityAction.run(GetKernelIdentityAction.java:25)
    at java.security.AccessController.doPrivileged(Native Method)
    at weblogic.jndi.WLSJNDIEnvironmentImpl.<clinit>(WLSJNDIEnvironmentImpl.java:57)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Unknown Source)
    at weblogic.jndi.internal.JNDIEnvironment.getJNDIEnvironment(JNDIEnvironment.java:33)
    at weblogic.jndi.Environment.<clinit>(Environment.java:89)
    at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:117)
    at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
    at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
    at javax.naming.InitialContext.init(Unknown Source)
    at javax.naming.InitialContext.<init>(Unknown Source)
    at hermes.JNDIContextFactory.createContext(JNDIContextFactory.java:261)
    at hermes.JNDIConnectionFactory.createConnection(JNDIConnectionFactory.java:80)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.JMSConnectionHolder.createConnection(JMSConnectionHolder.java:87)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.HermesJmsRequestSendTransport.execute(HermesJmsRequestSendTransport.java:37)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.HermesJmsRequestTransport.sendRequest(HermesJmsRequestTransport.java:98)
    at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:119)
    at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.SecurityException: sealing violation: can't seal package javax.security.auth: already loaded
    at java.net.URLClassLoader.getAndVerifyPackage(Unknown Source)
    at java.net.URLClassLoader.definePackageInternal(Unknown Source)
    at java.net.URLClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.access$100(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.net.URLClassLoader$1.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(Unknown Source)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.util.HermesUtils$ReverseOrderClassLoader.innerLoadClass(HermesUtils.java:332)
    at com.eviware.soapui.impl.wsdl.submit.transports.jms.util.HermesUtils$ReverseOrderClassLoader.loadClass(HermesUtils.java:319)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at hermes.impl.LoaderSupport$DebugClassLoader.loadClass(LoaderSupport.java:99)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at weblogic.security.acl.internal.AuthenticatedSubject.<init>(AuthenticatedSubject.java:101)
    at weblogic.security.acl.internal.AuthenticatedSubject.<clinit>(AuthenticatedSubject.java:39)
    ... 26 more

 

In the preferences > tools, I have set the path for hermesJMS to C:\Program Files\SmartBear\ReadyAPI-1.4.1\hermesJMS.

 

Any clue why these tests would stop working? I'm leaning towards a config file was overwritten in the upgrade, but I'm not sure where to look for that. I was hoping the upgrade would be smooth. My other option is to roll back and try again, but if it is a config issue, that should be an easy fix, right?

 

Thanks.

  • Anton,

    I selected the "install in the current directory" (ReadyAPI-1.4.1) instead of "install in a new directory" (ReadyAPI-1.5.0), so the path to hermes is correct. I'm wondering if I would have had the problem if I had chosen a the new path instead.

     

    FYI, I uninstalled the upgrade and went back to 1.4.1 and I'm not having the problem anymore. If/when I upgrade to 1.5, I will  choose the install in a new directory option.

16 Replies

    • jstrauss64's avatar
      jstrauss64
      Occasional Contributor

      Thanks, Rao.

       

      I haven't had any luck with resolving the issue I'm having. I think I will uninstall the upgrade and start from the beginning.

       

      I did learn a lesson. Always back up before upgrading!

       

      • nmrao's avatar
        nmrao
        Champion Level 3
        That is right jstrauss64. Usually upgrading involves certain changes which are sometimes necessary, may not be at times., and go for upgrade when absolutely needed. Always perform some sanity checks before upgrade, so that you know better the upgrade works for you or not.
  • AntonE's avatar
    AntonE
    SmartBear Alumni (Retired)

    jstrauss64 wrote:

    In the preferences > tools, I have set the path for hermesJMS to C:\Program Files\SmartBear\ReadyAPI-1.4.1\hermesJMS.

     


    I'm not sure it will help with this problem, but in general you should change the path to hermesJMS after upgrade, as some libraries can be replaced in new versions. So, for Ready! API 1.5.0 the path should be C:\Program Files\SmartBear\ReadyAPI-1.5.0\hermesJMS.

    • przemekch's avatar
      przemekch
      Occasional Contributor
      Hi Anton,
      I'm using Maven plugin so I can't do that.
      Secondly I'm not using the installer version but the zip package without Hermes. And I do have a settings file which points to Hermes location and I pase it as Maven parameter to the maven plugin.
      Locally I have fixed the issue by copying Hermes ext libraries to ready api/bin/ext dir but how to do it with the Maven plugin. Some dependencies are missing.
      • AntonE's avatar
        AntonE
        SmartBear Alumni (Retired)

        przemekch, do you have exactly the same error? If not, could you post your error log here? Also, I can see that jstrauss64 uses WebLogic. What JMS provider do you use?

    • jstrauss64's avatar
      jstrauss64
      Occasional Contributor

      Anton,

      I selected the "install in the current directory" (ReadyAPI-1.4.1) instead of "install in a new directory" (ReadyAPI-1.5.0), so the path to hermes is correct. I'm wondering if I would have had the problem if I had chosen a the new path instead.

       

      FYI, I uninstalled the upgrade and went back to 1.4.1 and I'm not having the problem anymore. If/when I upgrade to 1.5, I will  choose the install in a new directory option.

    • przemekch's avatar
      przemekch
      Occasional Contributor
      I can't see a nightly build Maven plugin....
      • nmrao's avatar
        nmrao
        Champion Level 3

        przemekch, there was not any suggession to use nightly build for Maven Plugin. I believe that changes to resolve issue in ReadyAPI nightly build as the user stated. If you want to try the updated build from the given location to see if the issue that you have is resolved.