mileppaa
Occasional Contributor
Joined 12 years ago
User Profile
User Widgets
Contributions
Re: Hermes JMS not working properly with Ready API 1.5.0
Yep, Problem is inside the Ready API, not much I can do with that. Anyways, Jira issue was created about this as support was able to reproduce this. Solution for now is to use older version 1.4.1 Hermes JMS support in Ready API / SOAP UI is cool thing but I hope it could switched to some other JMS tool as Hermes is getting outdated and there seems to be no support for that anymore.6.7KViews0likes8CommentsHermes JMS not working properly with Ready API 1.5.0
Hi, I just had to switch back to 1.4.1 Ready API as I noticed that something has been changed in 1.5.0.regarding the hadling of Hermes in Groovy scripts. Problem is java linked naming exception coming when you try to run groovy script that tries to utilize Hermes. Example from http://readyapi.smartbear.com/structure/steps/script/groovy/jms is good example. When trying to run this script, error comes with this line: def hermes = HermesUtils.getHermes( context.testCase.testSuite.project, jmsEndpoint.sessionName) Original installation was made on top of Ready API 1.4.1 by update. When I noticed that Groovy scripts (using the HermesUtils getHermes) were not working, I removed the installation and installed a clean 1.5.0. Clean installation brought it's own problem with hermes, as after that the hermes-config -file was not found. Yes, I did give the path to the correct folder, and Yes, the config file was working before the 1.5.0 installation (And yes, it is now working with 1.4.1 version. This is the error: 2015-11-17 10:53:31,266 ERROR [errorlog] java.lang.LinkageError: loader constraint violation: loader (instance of sun/misc/Launcher$AppClassLoader) previously initiated loading for a different type with name "hermes/HermesDispatcher" java.lang.LinkageError: loader constraint violation: loader (instance of sun/misc/Launcher$AppClassLoader) previously initiated loading for a different type with name "hermes/HermesDispatcher" at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(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 java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Unknown Source) at java.lang.Class.privateGetPublicMethods(Unknown Source) at java.lang.Class.getMethods(Unknown Source) at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass.getSAMMethod(CachedSAMClass.java:164) at org.codehaus.groovy.reflection.ClassInfo.isSAM(ClassInfo.java:359) at org.codehaus.groovy.reflection.ClassInfo.createCachedClass(ClassInfo.java:349) at org.codehaus.groovy.reflection.ClassInfo.access$700(ClassInfo.java:41) at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:497) at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:488) at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:49) at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:36) at org.codehaus.groovy.reflection.ClassInfo.getCachedClass(ClassInfo.java:111) at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:110) at org.codehaus.groovy.classgen.asm.BytecodeHelper.box(BytecodeHelper.java:605) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.writeMethod(CallSiteGenerator.java:97) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.genCallXxxWithArray(CallSiteGenerator.java:140) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.genStaticMetaMethodSite(CallSiteGenerator.java:203) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compileStaticMethod(CallSiteGenerator.java:244) at org.codehaus.groovy.reflection.CachedMethod.createStaticMetaMethodSite(CachedMethod.java:288) at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.createStaticMetaMethodSite(StaticMetaMethodSite.java:114) at groovy.lang.MetaClassImpl.createStaticSite(MetaClassImpl.java:3385) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStaticSite(CallSiteArray.java:77) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:162) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133) at Script1.run(Script1.groovy:17) at com.eviware.soapui.support.scripting.groovy.SoapUIGroovyScriptEngine.run(SoapUIGroovyScriptEngine.java:92) at com.eviware.soapui.support.scripting.groovy.SoapUIProGroovyScriptEngineFactory$SoapUIProGroovyScriptEngine.run(SoapUIProGroovyScriptEngineFactory.java:76) at com.eviware.soapui.impl.wsdl.teststeps.WsdlGroovyScriptTestStep.run(WsdlGroovyScriptTestStep.java:155) at com.eviware.soapui.impl.wsdl.panels.teststeps.GroovyScriptStepDesktopPanel$RunAction$1.run(GroovyScriptStepDesktopPanel.java:263) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)Solved6.9KViews0likes10CommentsRe: Ready API 1.5.0 on Windows 7 keeps hanging and extremely slow
Hi, I noticed the same. Did you update the tool from 1.3 -> 1.5? I just did that and API logs seem to have lot's of errors. Something about events/listeners ... Anyway, I removed the whole installation, and then installed the 1.5.0 again and now it seems to be faster as there are no errors in logs... But now I have Hermes JMS issue as it is not working anymore :-(5.3KViews0likes0CommentsRe: remove an API in the API Navigator ?
Hi, Not sure if this helps but try using Project -view. I noticed the same thing when started to use this Ready API 1.4.1. In SoapUI NG API navigator you cannot do anything to those interfaces/apis but in project view, you have that remove option available.1.7KViews2likes0CommentsRe: Starting Hermes in Ready! API
Hmm.... Just figured a one solution to this... It seems that when Ready API is installed with HermesJMS, a environment parameter called HERMES_CONFIG is not set... So, if this is added to the environment variables (in Windows System), then Ready Api can start HermesJMS with proper configuration. Maybe this information could be added to Ready API installation notes?3KViews0likes0CommentsStarting Hermes in Ready! API
Hi, I just switched to Ready! API 1.4.1 from Soap UI 5.2.0 and was wondering the idea how HermesJMS is started with Ready API... When Ready API is started, and then Projects -is selected, and from the menu Project, select Start HermesJMS, the app puts up nice dialog to asking where the configuration hermes-config is located. Ok, this works fine and all your queues and stuff is found easily. However, if you start the hermesJMS from menu Tools -> HermesJMS, this does not ask any location for config file, it just tries to open default config from hermes installation path (it does not try to check eg Hermes Config -project property.) Ok, lets go to SoapUI NG. From there you have no access to HermesJMS, unless you create a JMS Request step. Well, after you create one you have this nice little tab after the Queue path field. Pressing it opens Hermes, but configuration is tried to load from just created folder named GIT_HOME... So, is there any general hermes path property/parameter that can be used to tell where the hermes-config -file is if this project property Hermes config is ignored? Soap Ui 2.5.0 did not had this kind of issue it must have something to do with the way that this Ready API -handles HermesJMS installation.Solved3KViews0likes1CommentRe: Using Project Property as a value for JMS Timeout Assertion
Ok, I think I got this solved... I did some searching for this SLA assertion thing and found NMRAO 's script assertion hint: assert messageExchange.timeTaken <= (context.expand('${#TestCase#SLA}') as Long), 'SLA failed ' So, after changing all of my JMS Timeout Assertions to Script assertions and changed script to use Project Property, I am able to use Project property as a assertion value. Thanx for help!! P.S. Next task is to find out why Soap-UI 5.2 (x64) testrunner gets this java.lang.ClassNotFoundException: com.eviware.soapui.plugins.auto.factories.AutoImportMethodFactory -error...2.1KViews0likes0CommentsRe: Using Project Property as a value for JMS Timeout Assertion
Yep, Expansion: ${#Project#Timeout}, we have a property named Timeout at project level. I also checked the SLA assertion (I have not used that before) and it's a same thing with that. You cannot use expansions with that either (5.0 and 5.2) :-( Anyway, I started to check from Soap Ui pages that have I understood something wrong with this testrequest Timeout -property. I used it before with the JMS Timeout assertion as there were no value asked during Assertion insert. And, in 5.0 it worked like that (I belive that it did :-), it used the timeout value set in testRequest -property. Now, the pages say that "The request Timeout property sets a limit on how long (in milliseconds) the request should wait for a response " I am not sure if that was there before? Well anyway, I was thinking that now this property Timeout is just separated from JMS Timeout assertion as, of course, you can receive other messages than JMS :-) And we need a property to tell soap ui that 'hey, wait only 20 secs for a response, not forever'... So logic is ok with this, now Ijust need to remember that in the future :-) But anyway, that does not give answers to the original issue, which is the thing that you can't use expansion to define that timeout value for JMS Timeout -assertion.2.1KViews0likes0CommentsRe: Using Project Property as a value for JMS Timeout Assertion
Hi, I have version 5.0 (x64 , free, Build Date: 20140409-1012 ) running and JMS Timeout -assertion is working there like I described eg. it uses Request property Timeout. With this version, adding JMS Timeout does not use this dialog that asks for Timeout -value. But with this 5.2 (Build Date: 20150701-1106), a dialog is does ask for this timeout value and it does not use Request property Timeout. I just tested it and only the value that you give via dialog is valid. Value inserted directly to Request Property Timeout is not used at all.2.1KViews0likes2Comments