Forum Discussion

Enforcer's avatar
Enforcer
New Contributor
11 years ago

mock war containing old buggy log4j

Hi All!
I created mock war from UI and deployed it to tomcat 7/8. It's working fine but when I tried to redeploy/undeploy, tomcat reported error because hermes-1.14.jar was locked
After couple of days research I restored chain of problems

1. hermes-1.14.jar is the only jar in mock war WEB-INF/lib containing file log4j.properties. Without hermes-1.14.jar or with hermes-1.14.jar without log4j.properties bug is not reproducing
2. mock war uses outdated log4j-1.2.14.jar which contains unavoidable bug that locks log4j.properties or containing jar (hermes-1.14.jar in our case)
3. replacing log4j-1.2.14.jar to log4j-1.2.17.jar (latest version) did the work

So I'm humbly asking to update mock war generation (and SoapUI artifact dependency) - refresh log4j version to 1.2.17

Also I would like to report couple more small issues preventing manual build of mock war from gradle:
1. http://www.soapui.org/repository/maven2 ... -1.142.pom has incorrect groupId in pom file (cajo instead of gnu.cajo). please correct
2. http://www.soapui.org/repository/maven2 ... -jdk15.pom has incorrect groupId in pom file (r872 instead of r872-jdk15). please correct
3. please exclude dependency javax.jms from com.smartbear.soapui:soapui:5.0.0 or replace it with up to date javaee-api with scope provided
4. change scope of javax.servlet:servlet-api to provided
5. exclude dependency jetty:servlet-api from com.smartbear.soapui:soapui:5.0.0 because mock war doesn't contain such jar
6. same as above for l2fprod:l2fprod-common-directorychooser, l2fprod:l2fprod-common-fontchooser


and a general suggestion: please update all dependencies to their updated versions. Hopefully it'll fix most of existing bugs not presenting new ones

2 Replies

  • Enforcer's avatar
    Enforcer
    New Contributor
    there are also couple of leftovers after application has been undeployed:

      J2SE Timer thread
      Another typed Thread
      couple more, refer to attached java file

    They lead to memory leaks on app server and god knows what other problems.
    I'm attaching my context listener class that tries to mitigate those issues.
    To include it it your war mock just put it in web-inf/classes and add following section to web.xml:

    <listener>
    <listener-class>soapuimockfix.CleanupContextListener</listener-class>
    </listener>


    I doubt that I found all leftovers and my class contains proper fix but unfortunately I don't have time to dig more into this issue now.
  • redfish4ktc2's avatar
    redfish4ktc2
    Super Contributor
    hi Enforcer,
    about the problem with the dependencies, this is a known issue. SmartBear has upgraded some dependencies recently (see https://github.com/SmartBear/soapui/blo ... ES.txt#L58) but AFAIK they do not plan to do it for all dependencies for now.
    See also these topics
    * issues when running with gradle: viewtopic.php?f=13&t=22673
    * why SoapUI is using wrong maven coordinates: viewtopic.php?f=5&t=20368

    About the log4j upgrade and the custom listener, have you considered proposing a pull request to make these available directly in the SoapUI source code? See this documentation to be able to contribute: http://www.soapui.org/Developers-Corner ... oapui.html
    I can help you with this if you need/want