Description of problem: when deleting watchdog entity via rest API you don't receive an xml respond, because 'application/xml is missing in the response headers * Example of the DELETE via res: DELETE https://10.35.161.33/api/vms/b1669863-f65a-4090-be8b-252ad18725a9/watchdogs/00000000-0000-0000-0000-000000000000 * Response headers : Date: Thu, 20 Aug 2015 08:21:43 GMT Pragma: No-cache Cache-Control: no-cache Expires: Thu, 01 Jan 1970 02:00:00 IST Content-Type: */* Version-Release number of selected component (if applicable): Red Hat Enterprise Virtualization Manager Version: 3.6.0-0.11.master.el6 How reproducible: 100% Steps to Reproduce: 1.create vm with watchdog device 2.try to delete watchdog device via rest API 3. Actual results: .Action actions: null brick: null bricks: null cluster: null comment: null connectivityTimeout: null creationStatus: null description: null disk: null disks: null fault: null fenceType: null gracePeriod: null host: null hostNics: null href: null id: null image: null iscsi: null job: {actions: null, comment: null, creationStatus: null, description: null, endTime: null, href: /ovirt-engine/api/jobs/e5213fc1-54aa-4baf-84ea-b6b7e61f02cc, id: e5213fc1-54aa-4baf-84ea-b6b7e61f02cc, lastUpdated: null, name: null, owner: null, startTime: null, status: null} logicalUnits: null modifiedBonds: null modifiedLabels: null modifiedNetworkAttachments: null name: null network: null option: null powerManagement: null proxyTicket: null reason: null removedBonds: null removedLabels: null removedNetworkAttachments: null resolutionType: null rootPassword: null snapshot: null ssh: null status: {detail: null, state: complete} storageDomain: null storageDomains: null synchronizedNetworkAttachments: null template: null ticket: null vm: null Expected results: the response should be xml Additional info:
This happens because the request doesn't include an "Accept" header, thus the application server is free to select whatever it likes. In this particular case it decides to send YAML. Not sure why, seems like the server selects randomly the response content type, and that the presence of headers like "Content-Type" have some influence. Ideally we should solve this making "application/xml" the default for all responses, but I couldn't find yet a way to configure the default response type in Resteasy. As a workaround include the "Accept: application/xml" header explicitly, that will force the server to use the expected media type.
The fix for bug 1250046 also solves this issue.
verified on 3.6.0-10