Forum Discussion
MMehalso
14 years agoOccasional Contributor
Hey Ole,
Thanks for the reply! I agree, what I posted is not the right way to go; we were just going for a quick patch to move along some tests.
And we obviously like the design and product you guys have put together, we're just being picky about matching it to our needs
I'll definitely give the nightly build a shot. The only problem, I think, is that the MockServletSoapUICore accesses it's outer class object - the actual servlet instantiation - to look for the appropriate mock runner for an incoming request.
So if we have a single *Core object, it's can only access the mock services associated with it's outer servlet. An example would be a request to servlet #2 after servlet #1 has already initialized and created it's SoapUI Core:
Request->Servlet #2->SoapUICore->Servlet #1->mockRunners --- mock runner not found
The problem is here & here:
I think there are two options for a quick fix -
1. Store all the MockRunners in the MockServletSoapUICore object instead of in each servlet. That way you have a single list holding services from, potentially, multiple projects.
2. Rather than access the mockRunners list by reference to the outer class object, (i.e. MockAsWarServlet.this.mockRunners), pass them as a parameter to the MockServetSoapUICore's dispatchRequest() method. That way you have a single SoapUICore, which the static SoapUI class knows about, and the core object can just use the provided mock runner list to decide how to execute the incoming request. That way, the core really shouldn't have to know about any of the servlets at all... strong cohesion & low coupling
I may give #2 a shot as it's a relatively simple change.
Thanks again!
Matt
Thanks for the reply! I agree, what I posted is not the right way to go; we were just going for a quick patch to move along some tests.
And we obviously like the design and product you guys have put together, we're just being picky about matching it to our needs

I'll definitely give the nightly build a shot. The only problem, I think, is that the MockServletSoapUICore accesses it's outer class object - the actual servlet instantiation - to look for the appropriate mock runner for an incoming request.
So if we have a single *Core object, it's can only access the mock services associated with it's outer servlet. An example would be a request to servlet #2 after servlet #1 has already initialized and created it's SoapUI Core:
Request->Servlet #2->SoapUICore->Servlet #1->mockRunners --- mock runner not found
The problem is here & here:
/* */ public MockRunner[] getMockRunners()
/* */ {
/* 332 */ return ((MockRunner[])MockAsWarServlet.this.mockRunners.toArray(new MockRunner[MockAsWarServlet.this.mockRunners.size()]));
/* */ }
/* */ public boolean hasRunningMock(MockService mockService)
/* */ {
/* 337 */ for (MockRunner runner : MockAsWarServlet.this.mockRunners)
/* */ {
/* 339 */ if (runner.getMockService() == mockService)
/* */ {
/* 341 */ return true;
/* */ }
/* */ }
/* */
/* 345 */ return false;
/* */ }
I think there are two options for a quick fix -
1. Store all the MockRunners in the MockServletSoapUICore object instead of in each servlet. That way you have a single list holding services from, potentially, multiple projects.
2. Rather than access the mockRunners list by reference to the outer class object, (i.e. MockAsWarServlet.this.mockRunners), pass them as a parameter to the MockServetSoapUICore's dispatchRequest() method. That way you have a single SoapUICore, which the static SoapUI class knows about, and the core object can just use the provided mock runner list to decide how to execute the incoming request. That way, the core really shouldn't have to know about any of the servlets at all... strong cohesion & low coupling

I may give #2 a shot as it's a relatively simple change.
Thanks again!
Matt