ContributionsMost RecentMost LikesSolutionsRe: How/where to download SOAP-UI sources? Thanks! Unfortunately, when trying to build, there are tons of UnitTest-errors: [ERROR] Tests run: 683, Failures: 259, Errors: 0, Skipped: 14, Time elapsed: 13.126 s <<< FAILURE! - in TestSuite [ERROR] createMockAsWar on createMockAsWar(com.eviware.soapui.actions.MockAsWarActionTest)(com.eviware.soapui.actions.MockAsWarActionTest) Time elapsed: 1.779 s <<< FAILURE! java.lang.ExceptionInInitializerError at com.eviware.soapui.actions.MockAsWarActionTest.setUpFormDialog(MockAsWarActionTest.java:64) at com.eviware.soapui.actions.MockAsWarActionTest.setUp(MockAsWarActionTest.java:60) Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @59e5ddf at com.eviware.soapui.actions.MockAsWarActionTest.setUpFormDialog(MockAsWarActionTest.java:64) at com.eviware.soapui.actions.MockAsWarActionTest.setUp(MockAsWarActionTest.java:60) [ERROR] builderValuesShouldMatchModel[0 - class com.eviware.soapui.impl.wsdl.panels.teststeps.amf.AMFRequestTestStepPanelBuilder] on builderValuesShouldMatchModel[0 - class com.eviware.soapui.impl.wsdl.panels.teststeps.amf.AMFRequestTestStepPanelBuilder](com.eviware.soapui.impl.GenericPanelBuilderTest)(com.eviware.soapui.impl.GenericPanelBuilderTest) Time elapsed: 0.004 s <<< FAILURE! java.lang.NoClassDefFoundError: Could not initialize class org.mockito.internal.creation.jmock.ClassImposterizer$3 at com.eviware.soapui.impl.GenericPanelBuilderTest.<init>(GenericPanelBuilderTest.java:95) The latter repeats a hundred times or so. "java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @59e5ddf"sounds like a Java version issue to me. Has this really ever been built with Java 16 (as the projects home-page "SmartBear/soapui: SoapUI is a free and open source cross-platform functional testing solution for APIs and web services. (github.com)" suggests?) GET-request: How to respond with a file-content verbatim, i.e. *exactly* as read from the file I am trying to mock a REST service that responds with the content of a .CSV (i.e. comma-separated values) file. This sounds pretty trivial but as turned out misc. character encoding issues make this more complicated as expected. For the REST-response I am reading the file using a Groovy script as below ($path is set via properties and calculated - not shown here): ... path-calculation omitted... log.info("reading data from '${path}'") def file = new File(path) if (file.exists() && file.isFile()) { byte[] fileBytes = file.bytes int length = fileBytes.length log.info("read ${length} bytes of data: '${fileBytes}'") String str = new String(fileBytes, java.nio.charset.StandardCharsets.ISO_8859_1) mockResponse.content = str } else { throw new Exception("file '${path}' not found!") } This works "almost", i.e. the file's content gets delivered but its character encoding is wrong (i.e. special characters like German Umlauts get garbled). The issue is that the original file's content is in ISO-8859-1 encoding and it has to be sent "verbatim", i.e. "bit-true" exactly as on the file. The fileBytes after reading contain the correct bytes values according to the ISO-8859-1 encoding and theString - when logged (not shown here) - is also correct, since it gets converted to Java's internal encoding using the second ISO-8859-1 character-set argument. However, the conversion from that String to the actually returned bytes is wrong. The response is configured with a "Content | Media type" header value of "text/csv; charset=ISO-8859-1" which is also correctly sent and received as: HTTP/1.1 200 OK Content-Type: text/csv; charset=ISO-8859-1 The delivered character-payload data, however, is obviously not encoded using that specified encoding but something else (I guess UTF-8). e.g. the string "männlich;8000 Zürich" arrives as "männlich;8000 Zürich" when correctly decoded - as specified in the header as ISO-8859-1 on the receiver side. I also looked at the received bytes using a Hex-Editor and the Umlauts obviously get encoded as two bytes, not one! I then tried to assign the original bytes to the mockResponse.content, i.e. // String str = new String(fileBytes, java.nio.charset.StandardCharsets.ISO_8859_1) mockResponse.responseContent = fileBytes but that didn't work. That is then sent out as character array, i.e. as "[99, 114, 101, 97, 116, 101, 100, 59, 97, 114, 98, ..." and thus useless. So - is there any possibility to convince SOAP-UI to actually encode the response in the character-code that is specified in the HTTP-response header? Or to assign the original fileBytes to the mockResponse's content somehow without byte=>String conversion? How/where to download SOAP-UI sources? We are - since years! - annoyed by a bug where a minimized window can not be re-openend anymore. The SOAP-UI log then always shows this error: "... An error occurred [illegal component position], see error log for details". This then always requires to interrupt your session, terminate and restart SOAP-UI and only then one can continue to work with it. Since development of the open source version seems to have more or less come to a stand-still and this bug is soooo tediousI am feeling tempted to go and try to fix that issue myself.After all: it's called the OpenSource version, isn't it? However, I searched around a bit on the SmartBear website but couldn't find a link or hint, from where to actually download the SOAP-UI sources. Could someone knowledgeable please point me there? Is that code really ALL open source?And is it in a shape (i.e. are there also all resources plus Maven/Ant/Gradle or whatever build scripts available) such that one actually has a chance to build it oneself with predictable effort? SolvedCan one explicitly stop the SOAPUI-Maven Plugin at the end of a module's build? Referring to my other question (https://community.smartbear.com/t5/SoapUI-Open-Source-Questions/Multiple-REST-mocks-on-same-port/m-p/242192😞 We are using thesoapui-maven-plugin to mock web services as well as REST services during our unit-tests (executed on a Jenkins build server). As we had to learn the soapui-maven-plugin only supports the mocking of a single REST service at a time. If your SOAP Project file contains multiple REST mocks then by default only the first REST service will be started, unless one specifies a particular service using the<mockService>specificServiceHere</mockService> configuration option. This works OK if one builds one module only. Since our project comprises multiple modules we need to enable/mock a different REST-service for each module's unit-tests. This, however, does not work (yet). While the REST services of the first module are being served properly, any subsequent module's REST service is not started, the corresponding requests always yield "404 Not found" only and hence our unit tests fail. Apparently the soapui-maven-plugin is NOT stopped and restarted with the next module's configuration but continues to run while the subsequent module is being built. It is thus still running the REST mocks for theprevious module and all calls to REST to service required for the testing of subsequent modules then fail. Is there a possibility to force-stop that plugin after the end of the tests of a module so that the plugin gets restarted for each module's build (with the proper settings for that module)? Hope I could make myself clear... Re: Multiple REST mocks on same port? That wouldn't buy me much. I am running the Mocks using the SOAP-UI Maven-plugin during a build on our Jenkins build server (for our UnitTests to find their mock-services). I don't see how I could run a shell command during that automatic build. Multiple REST mocks on same port? We are using the SOAP Maven plugin to start several mock services while doing unit tests. This has worked fine so far (we were mocking several SOAP services and one REST service so far - all via the same local endpoint and same port). Now we need to extend that a bit since we need to connect to yet another system and so we added a second REST mock to the project file but no matter what we are trying (and we fiddled already for almost a day): we always only get a "404 not found" back from that second mock service while running our UT on Jenkins. Which finally makes me wonder: is there some restriction or limitation on this? Can one serve only ONE REST endpoint on the same port from that maven plugin? I would find that really odd, since with SOAP-services that never was an issue. Also, serving multiple REST Mocks via the same port is not an issue at all in SOAPUI on my developer workstation. Local builds run just fine (but these don't use the Maven-Plugin to start the Mock. Rather there I always start SOAPUI locally and then fire up all the mocks (via a load script)). But that more and more seems to be the only explanation why we don't get any reasonable response from that second service when executing things on Jenkins... If that suspicion is true: can one redirect individual mock service to different ports via some plugin config option? Or do we really need to split our project file into two and then start TWO mock servers in parallel (if that's even possible)? That would be really tedious! Re: Is Hermes gone? I followed the referenced append but unfortunately this didn't work for me. No menu entry or anything that would have allowed me to start Hermes would show up. The referenced thread is also locked - or else I would have responded there... Could you provide additional info how you did that? Could it have to do with the fact thatI had to try with Java 11 since I didn't find Java 9 provided anywhere? Re: Make SOAPUI work with Hermes JMS again I followed the referenced append but unfortunately this didn't work for me. No menu entry or anything that would have allowed me to start Hermes would show up. The referenced thread is also locked - or else I would have responded there... Why does compiled mock not provide WSDL anymore? For our testing we run an old machine as our "mocks-server".After changes to some WSDL or schema then we upload the updated ...-soapui-project.xml file to said server and trigger a script that feeds that file to the SOAPUI war-generator and then throws the generated .war file onto a Tomcat-server which acts as our mock-server. So far it was always possible to request the WSDL from that server by calling the basic URL with a ?WSDL at the end of the URL. For some reason since a while that doesn't seem to work anymore, even though we didn't change anything on that system, i.e. neither the war-generator nor the tomcat has changed since quite some time. Occasionally that is quite convenient, esp. when a new team-member joins who doesn't yet know all the services and method names etc. "by heart". I also used that request as a "ping" or livelyhood-check for the mock-server, so it's a bit annoying that this seized to work. Any idea, why serving the WSDL doesn't work anymore? The actual mock-services still work fine, BTW! It's really only that WSDL page that is not served anymore but only yields a "404 Not found". Is that maybe some setting in the project file that could influence this? Or some option of the .war generator (even though - as I said - that hasn't been changed). Re: Is Hermes gone?I was exactly trying with v5.6. I'll consider retrograding. Thanks for making me aware!