Mock Services - Multiple MockAsWarServlets

Hey guys -

Let me first-off say thanks a ton for getting the 'Deploy as WAR' functionality working for WebLogic. We've been using your product for some time with a large enterprise client and have been forced to use some workarounds to really integrate soapUI mock services into our QA and integration environments. I think that getting a lot of these issues ironed out will go a long way towards making your product the de facto standard for service stubs, at least with us and our clients.

So anyway, cutting to the chase:

The best way we've been able to package and deploy the soapUI-generated WARs is to bundle them up in an .EAR file before deploying to WebLogic. When deploying strictly as a WAR, we ran into countless classloading issues due to conflicts with several of the base XML packages included in WLS. This includes a small manual step, obviously, but is worth it to us if we can get a good process going for creating, modifying, and deploying these services.

The only problem we ran into, though, is that we're trying to use multiple projects (and therefore multiple MockAsWarServlets) in the same JVM. The problem here is that, during initialization, the MockAsWarServlet creates a new MockServletSoapUICore during initialization and stores it statically in the SoapUI class.

SoapUI.setServletCore(new MockServletSoapUICore(getServletContext(), true)

All further requests to get the core object, which then points back to the servlet and list of mock runners, goes through the static SoapUI class.

getMockServletCore().dispatchRequest(request, response)

So say we have two different projects running under the same ear on the same server. The first servlet that gets hit initializes and executes fine. The second servlet that gets hit also initializes and executes fine, but during initialization, this second call replaces the SoapUI class's SoapUICore object with a new one. So now if we go back and try to hit the first web service, we never get to it as the mock runner is never found during request execution (This also is not thread-safe, but that's not directly giving us any trouble right now).

I went in and resolved the issue locally with a small code change to your source. Rather than store the SoapUICore object on the SoapUI static class, I just added a member to the MockAsWarServlet class. That way, each servlet has its own SoapUI core, and we don't have any conflicts when multiple are running. Not sure this is the best way to go, though, as the DefaultSoapUICore class looks like a heavyweight. It'd be nice if multiple projects/servlets could share the same core, but without overwriting / interfering with eachother. Do you think you all can resolve this in a future release? Our project is able to continue with the patched MockAsWarServlet for now, but to sell this to the entire enterprise, and future clients, we really need something that works right out of the box.

Here's a summary of the changes I made to MockAsWarServlet
Added a member:

private MockServletSoapUICore serlvetsCore;

Added a setter:

protected void setMockServletCore(MockServletSoapUICore core)
{
    this.servletsCore = core;
}

Replaced calls to SoapUI.setSoapUICore with:

setMockServletCore(core)

Replaced getter:

protected MockServletSoapUICore getMockServletCore() 
{
    return this.servletsCore;
}

Thanks for your help!

Matt