Description of problem: When I use the new operation to create a deployment unit http://localhost:8080/business-central/rest/deployment/[id]/deploy, in default is used JSON and the following exception is thrown because the response cannot be unmarshalled: Bad entity: [{"operation":"DEPLOY","deploymentUnit":{"groupId":"org.jboss","artifactId":"remote-file-deployment","version":"1.0-SNAPSHOT","kbaseName":null,"ksessionName":null,"strategy":"SINGLETON","status":"DEPLOYING","identifier":"org.jboss:remote-file-deployment:1.0-SNAPSHOT"},"success":true,"explanation":"Deployment (deploy) job submitted successfully."}] In JaxbDeploymentJobResult (https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-remote/kie-services-client/src/main/java/org/kie/services/client/serialization/jaxb/impl/deploy/JaxbDeploymentJobResult.java) you can see the deployment unit has set name "deployment-unit" but the marshalled version above has key "deploymentUnit" that is why the response cannot be unmarshalled. javax.xml.bind.UnmarshalException - with linked exception: [com.sun.istack.SAXParseException2; columnNumber: 0; unexpected element (uri:"", local:"operation"). Expected elements are <{}deployment-job-result>,<{}deployment-unit>] The workaround is to use XML instead, so in REST request you will specify the accept in HTTP header of request. The XML response is marshalled correctly. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Vikram, I am sorry but the doc text does not describe the issue correctly. There is nothing to do with XML, XML is just a workaround. The problem is that the response which client receives is wrong because the property name "deployment-unit" is marshalled as "deploymentUnit" instead. So, as a result the unmarshalling process (transferring response back to the object) will fail because the property will not be recognized correctly. I would say something like: Using the REST API to create a new deployment unit causes the response to be incorrectly marshalled into a JSON object. The response cannot be unmarshalled but the deployment process will happen eventually. As a workaround, it is possible to require "application/xml" format in the Accept part of the request message header.
(In reply to Ivo Bek from comment #1) > Vikram, > > I am sorry but the doc text does not describe the issue correctly. There is > nothing to do with XML, XML is just a workaround. The problem is that the > response which client receives is wrong because the property name > "deployment-unit" is marshalled as "deploymentUnit" instead. So, as a result > the unmarshalling process (transferring response back to the object) will > fail because the property will not be recognized correctly. > > I would say something like: > Using the REST API to create a new deployment unit causes the response to be > incorrectly marshalled into a JSON object. The response cannot be > unmarshalled but the deployment process will happen eventually. As a > workaround, it is possible to require "application/xml" format in the Accept > part of the request message header. Wonderful. Thanks for the feedback Ivo. I have updated the release notes with the updated text.
Fixed. Commits: 6.0.x: https://github.com/droolsjbpm/droolsjbpm-integration/commit/421a56c2 master: https://github.com/droolsjbpm/droolsjbpm-integration/commit/31f8adb5
This no longer has a target release of 6.0.0.
Verified in BPMS 6.0.1.ER1
I am sorry, I tested the issue with a wrong test and unfortunately I see there is still the same problem. Bad entity: [{"operation":"DEPLOY","deploymentUnit":{"groupId":"org.jboss","artifactId":"remote-file-deployment","version":"1.0-SNAPSHOT","kbaseName":null,"ksessionName":null,"strategy":"SINGLETON","identifier":"org.jboss:remote-file-deployment:1.0-SNAPSHOT","status":"DEPLOYING"},"success":true,"explanation":"Deployment (deploy) job submitted successfully."}] As you can see the deploymentUnit is not marshalled to "deployment-unit" as it is required. unexpected element (uri:"", local:"operation"). Expected elements are <{}deployment-job-result>,<{}deployment-unit>] The commit seems to be in the sync but probably it doesn't have the wanted effect.
Fixed. Commits: 6.0.x: https://github.com/droolsjbpm/droolsjbpm-integration/commit/eec1b108 master: https://github.com/droolsjbpm/droolsjbpm-integration/commit/38d52ea0
The issue is still in BPMS 6.0.1.ER2. Maybe the problem is somewhere else. I get: {"operation":"DEPLOY","deploymentUnit":{"groupId":"org.jboss","artifactId":"remote-file-deployment","version":"1.0-SNAPSHOT","kbaseName":null,"ksessionName":null,"strategy":"SINGLETON","identifier":"org.jboss:remote-file-deployment:1.0-SNAPSHOT","status":"DEPLOYING"},"success":true,"explanation":"Deployment (deploy) job submitted successfully."} I just wonder why the "operation" field is unexpected. The exception is: [com.sun.istack.SAXParseException2; columnNumber: 0; unexpected element (uri:"", local:"operation"). Expected elements are <{}deployment-job-result>,<{}deployment-unit>] at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:662) at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:258) at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(Loader.java:253) at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(Loader.java:120) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(UnmarshallingContext.java:1063) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:498) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:480) at com.sun.xml.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:75) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.handleStartElement(StAXStreamConnector.java:246) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:180) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:370) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:342) at org.jboss.resteasy.plugins.providers.jaxb.json.JettisonMappedUnmarshaller.unmarshal(JettisonMappedUnmarshaller.java:164) at org.jboss.resteasy.plugins.providers.jaxb.json.JettisonMappedUnmarshaller.unmarshal(JettisonMappedUnmarshaller.java:149) at org.jboss.resteasy.plugins.providers.jaxb.AbstractJAXBProvider.readFrom(AbstractJAXBProvider.java:121) at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:105) at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:63) at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) at org.jboss.resteasy.client.core.BaseClientResponse.readFrom(BaseClientResponse.java:433) at org.jboss.resteasy.client.core.BaseClientResponse.getEntity(BaseClientResponse.java:377) at org.jboss.resteasy.client.core.BaseClientResponse.getEntity(BaseClientResponse.java:338) at org.jboss.qa.bpms.rest.wb.RestWorkbenchClient.process(RestWorkbenchClient.java:97) at org.jboss.qa.bpms.rest.wb.RestWorkbenchClient.post(RestWorkbenchClient.java:61) at org.jboss.qa.bpms.rest.wb.RestWorkbenchClient.createDeploymentUnit(RestWorkbenchClient.java:257) at org.jboss.qa.bpms.rest.wb.WorkbenchClientWithAcknowledgement.createDeploymentUnit(WorkbenchClientWithAcknowledgement.java:158) at org.jboss.qa.bpms.deployment.RemoteFileDeploymentTest.createDeploymentUnit(RemoteFileDeploymentTest.java:27)
It looks a lot like the test is casting the response object incorrectly, but I can't find it in the code. Are you using the latest commit on the master branch of jbossqe/brms.git?
Hi Marco, yes I use the last commit of the brms repository. I transfer the response to JaxbDeploymentJobResult or something similar which is returned in the operation of DeploymentResource.
Ivo can you please provide the commit hash (id)? The exception stack is old and was obtained using a state which is different than the one in master now! E.g. line 97 in the RestWorkbenchClient points to '}'. If it's too hard to find the commit hash then it might be better to reproduce this once more and update the exception stack.
I've tested this backwards and forwards and I can't reproduce this problem at the moment.
I've been able to set up the test that Ivo uses and can reproduce the problem.
Fixed. Commits: 6.0.x: https://github.com/droolsjbpm/droolsjbpm-integration/commit/c1ba5515 master: https://github.com/droolsjbpm/droolsjbpm-integration/commit/c1ba5515
Some more notes about the bug and the fix here: 1. The problem here is of course on the client side, not on the server side. At the moment, the following configurations are supported: - the configurations/framework used in the RemoteFileDeploymentTest - the configurations/framework provided by the kie-services-client RestRequestHelper and other kie-services-client classes For obvious reasons, it's not practical nor wise to provide support for every client-side JSON framework/configuration: the focus of my work is jBPM, not REST. If there are bugs on the client side that involve JSON in the future, I'd like to suggest that tests using them then use the RestRequestHelper class (in kie-services-client) to interact with the server side. If the bug is also present when using the RestRequestHelper class, then at least fixing the bug will contribute to an already supported option, as opposed to adding one more configuration to support. Lastly, supporting all possible configurations for clients is of course not possible. 2. The fix here breaks JSON backwards-compatibility a little bit. Namely, before this fix, JSON entities looked like this: {"deployment-job-result":["org.kie.services.client.serialization.jaxb.impl.deploy.JaxbDeploymentJobResult",{"operation":"DEPLOY","deploymentUnit":[... However, now they look like this: {"operation":"DEPLOY","deploymentUnit":[... In other words, extra information is now included because of the options used in the ObjectMapper instance (See this code here: https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.0.x/kie-remote/kie-services-jaxb/src/main/java/org/kie/services/client/serialization/jaxb/json/JaxbJacksonObjectMapper.java ). The extra information that's now included in the JSON entity comes from 2 options: 1. The root value is "wrapped". The RemoteFileDeploymentTest expects this. 2. The type information is included. Users that are *not* using Java to interact with the REST services, might have problems with this. (For example, Javascript clients that are used to a very specific JSON format). Some Java users will need to change the configuration the client-side REST code if they use JSON: namely, they will need to change the config so that the deserializer unwraps the root element in a JSON entity.
Verified in BPMS 6.0.2.ER2 Additionally I filed BZ 1092588.
We've decided to revert the commits that fixed this issue. There are a couple of reasons for this, but the main one is that this changes the (JSON) API for clients between 6.0.1 and 6.0.2 in a large way. Also, including the class name in the JSON is not necessary for users who will be interacting with the REST services from a web page. I know that the original test (RemoteFileDeploymentTest) doesn't work with the REST services as they are. I am more than glad to work with QE on changing the test so that it does work.
I would like to close this bug as WORKSFORME (or WONTFIX or NOTABUG?), since this is a client side issue. Users simply need to configure the ObjectMapper in their code to correctly deserialize the JSON objects received from the REST API. I will add documentation describing this. Ivo, would it be okay to close this bug?
Hi Marco, I agree with you. You can close the bug, after you document it, so we could refer to it when somebody has the same problem. Thank you
Currently, the output of the /rest/deployment/{depId}/deploy operation looks like this: {"identifier":4,"operation":"DEPLOY","deploymentUnit":{"groupId":"org.test","artifactId":"kjar","version":"1.0","kbaseName":null,"ksessionName":null,"strategy":"SINGLETON","status":"ACCEPTED"},"success":true,"explanation":"deploy job accepted."} and I'm able to deserialize it with this code: JaxbDeploymentJobResult res = new ObjectMapper().readValue(responseBody, JaxbDeploymentJobResult.class); I don't think that this needs documentation. If this does need documentation, please reopen the bugzilla.