Bug 1050894 - A deployment unit in JaxbDeploymentJobResult is wrongly marshalled into JSON
Summary: A deployment unit in JaxbDeploymentJobResult is wrongly marshalled into JSON
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Business Central
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Marco Rietveld
QA Contact: Ivo Bek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-09 10:04 UTC by Ivo Bek
Modified: 2016-09-20 05:05 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Using the REST API to create a new deployment unit causes the response to be incorrectly marshalled into a JSON object rather than the expected XML. The response cannot be unmarshalled and the deployment is not successful. Cause: Consequence: Fix: Result:
Clone Of:
Environment:
Last Closed: 2014-10-31 14:07:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ivo Bek 2014-01-09 10:04:17 UTC
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:

Comment 1 Ivo Bek 2014-01-29 14:01:44 UTC
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.

Comment 2 Vikram Goyal 2014-01-30 03:04:07 UTC
(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.

Comment 4 Lukáš Petrovický 2014-02-07 16:19:55 UTC
This no longer has a target release of 6.0.0.

Comment 5 Ivo Bek 2014-02-24 09:37:34 UTC
Verified in BPMS 6.0.1.ER1

Comment 6 Ivo Bek 2014-02-26 08:31:01 UTC
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.

Comment 9 Ivo Bek 2014-03-10 12:21:12 UTC
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)

Comment 10 Marco Rietveld 2014-03-10 17:03:36 UTC
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?

Comment 11 Ivo Bek 2014-03-11 15:46:44 UTC
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.

Comment 12 Marek Baluch 2014-03-11 16:30:18 UTC
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.

Comment 14 Marco Rietveld 2014-03-14 05:28:05 UTC
I've tested this backwards and forwards and I can't reproduce this problem at the moment.

Comment 17 Marco Rietveld 2014-03-26 21:41:43 UTC
I've been able to set up the test that Ivo uses and can reproduce the problem.

Comment 19 Marco Rietveld 2014-03-27 16:51:07 UTC
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.

Comment 20 Ivo Bek 2014-04-29 14:10:44 UTC
Verified in BPMS 6.0.2.ER2

Additionally I filed BZ 1092588.

Comment 21 Marco Rietveld 2014-05-01 07:33:52 UTC
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.

Comment 22 Marco Rietveld 2014-07-17 07:58:52 UTC
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?

Comment 23 Ivo Bek 2014-07-17 08:38:21 UTC
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

Comment 24 Marco Rietveld 2014-10-31 14:07:10 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.