Keep original baseUrl (if it exist) when setting Content_Location in header

[basecade]

When returning a resource with an existing baseUrl then keep it when setting Content_Location in the header.
This can happen when a service returns a resource that belongs on another service.

[coveralls]

Coverage decreased (-0.02%) to 75.784% when pulling 085ff1e on jasmdk:headerContentLocationKeepBaseUrl into f17fc4c on jamesagnew:master.

[basecade]

I have added a test for the new code, so I'm not sure I understand why the coverage has descreased.

[jamesagnew]

I'm not sure I understand the purpose of this- Why would you want a server to return a resource and provide a content location that the server itself doesn't agree with? This feels likely to cause more bugs in user code than it fixes...

[basecade]

Hi James,

Thank you for your feedback!
Let me try and explain my scenario. I have two microservices. Service1 is responsible for Resouce1 and Service2 is responsible for Resource2.
Service1 has a custom operation on a PlainProvider that creates an instance of both Resource1 and Resource2. So internally the custom operation on Service1 is using the GenericClient to create an instance of Resource2 on Service2. When Resource2 is returned to the custom operation it has a baseUrl matching Service2 in the idElement because of the HEADER_CONTENT_LOCATION. This is fine because if reflects where Resource2 resides. But when returning Resource2 from Service1 the HEADER_CONTENT_LOCATION is set to Service1 eventhough it already have an explicit location specified in the baseUrl.

Then you can argue that Resource1 and Resource2 should be on the same service, but my hands are a bit tied by some customer requirements. This is why I need to keep the existing baseUrl if there is one.

Hope my explanation makes sense :)

Best Regards,
Anders Havn