Bug 1280231 - lack of information to deploy kjar on WLS by REST API
Summary: lack of information to deploy kjar on WLS by REST API
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BPMS Platform 6
Classification: Retired
Component: Documentation
Version: 6.1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: 6.2.0
Assignee: brms-docs@redhat.com
QA Contact: Lukáš Petrovický
URL: https://access.redhat.com/documentati...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-11 09:50 UTC by Hiroko Miura
Modified: 2020-03-27 19:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Build Name: 22824, Development Guide-6.1 Build Date: 30-07-2015 16:46:35 Topic ID: 26707-753596 [Latest]
Last Closed: 2020-03-27 19:11:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Hiroko Miura 2015-11-11 09:50:26 UTC
Title: Deployment calls

Describe the issue:

When deploying kjar to business central on WLS by the following REST request fails with error 415(Unsupported Media Type) even though this is works against business central on EAP.

curl -v -H 'Accept: application/json' -u bpmsAdmin -X POST 'ldapj:7001/business-central/rest/deployment/com.sample:bpmstest:1.1:process:ksession-process/deploy'


Beacuse: 

 - header must be Content-Type as it the defines what type of data is coming in with the request, Accept is for what client can accept as response
 - WLS seems to be more strict to the content which in general is options 


The following REST request works for WLS then.

curl -v -H 'Content-Type: application/xml' -u bpmsAdmin --data "<deployment-descriptor/>"  -X POST 'ldapj:7001/business-central/rest/deployment/com.sample:bpmstest:1.1:process:ksession-process/deploy'

i.e.

-H 'Content-Type: application/xml'  is specified instead of Accept header

--data "<deployment-descriptor/>"  is specified as empty deployment structure which does not affect deployment structure in kjar (if any).
  


Suggestions for improvement:

Please clearly document about this requirement for REST API command  of 'deploy' against WLS.


Additional information:

Comment 1 Hiroko Miura 2015-11-12 08:46:17 UTC
Previous problem description is not good. Let me recap here.

Describe the issue:

Deploying kjar to business central on WLS by the following REST request fails with error 415 (Unsupported Media Type) even though same command works against business central on EAP.

curl -v -H 'Accept: application/json' 
        -u bpmsAdmin 
        -X POST 'ldapj:7001/business-central/rest/deployment/com.sample:bpmstest:1.1:process:ksession-process/deploy'


Error in WLS server log.

####<Nov 4, 2015 6:28:11 PM JST> <Error> <com.sun.jersey.spi.container.ContainerRequest> <xxx.redhat.com> <AdminServer> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <bpmsAdmin> <> <> <1446629291589> <BEA-000000> <A message body reader for Java class org.kie.services.client.serialization.jaxb.impl.deploy.JaxbDeploymentDescriptor, and Java type class org.kie.services.client.serialization.jaxb.impl.deploy.JaxbDeploymentDescriptor, and MIME media type application/octet-stream was not found. The registered message body readers compatible with the MIME media type are: application/octet-stream -> com.sun.jersey.core.impl.provider.entity.ByteArrayProvider com.sun.jersey.core.impl.provider.entity.FileProvider com.sun.jersey.core.impl.provider.entity.InputStreamProvider com.sun.jersey.core.impl.provider.entity.DataSourceProvider com.sun.jersey.core.impl.provider.entity.RenderedImageProvider */* -> com.sun.jersey.core.impl.provider.entity.FormProvider com.sun.jersey.core.impl.provider.entity.MimeMultipartProvider com.sun.jersey.core.impl.provider.entity.StringProvider com.sun.jersey.core.impl.provider.entity.ByteArrayProvider com.sun.jersey.core.impl.provider.entity.FileProvider com.sun.jersey.core.impl.provider.entity.InputStreamProvider com.sun.jersey.core.impl.provider.entity.DataSourceProvider com.sun.jersey.core.impl.provider.entity.XMLJAXBElementProvider$General com.sun.jersey.core.impl.provider.entity.ReaderProvider com.sun.jersey.core.impl.provider.entity.DocumentProvider com.sun.jersey.core.impl.provider.entity.SourceProvider$StreamSourceReader com.sun.jersey.core.impl.provider.entity.SourceProvider$SAXSourceReader com.sun.jersey.core.impl.provider.entity.SourceProvider$DOMSourceReader com.sun.jersey.json.impl.provider.entity.JSONJAXBElementProvider$General com.sun.jersey.json.impl.provider.entity.JSONArrayProvider$General com.sun.jersey.json.impl.provider.entity.JSONObjectProvider$General com.sun.jersey.core.impl.provider.entity.XMLRootElementProvider$General com.sun.jersey.core.impl.provider.entity.XMLListElementProvider$General com.sun.jersey.core.impl.provider.entity.XMLRootObjectProvider$General com.sun.jersey.core.impl.provider.entity.EntityHolderReader com.sun.jersey.json.impl.provider.entity.JSONRootElementProvider$General com.sun.jersey.json.impl.provider.entity.JSONListElementProvider$General com.sun.jersey.json.impl.provider.entity.JacksonProviderProxy >

This is because: 

 - header must be Content-Type as it the defines what type of data is coming in with the request, Accept is for what client can accept as response.

 - WLS seems to be more strict to the content which in general is options 

Therefore, the following REST request works for both WLS and EAP.

curl -v 
 -H 'Content-Type: application/xml' 
 -u bpmsAdmin 
 --data "<deployment-descriptor/>"  
 -X POST 'ldapj:7001/business-central/rest/deployment/com.sample:bpmstest:1.1:process:ksession-process/deploy'

i.e.

-H 'Content-Type: application/xml'  
==================================
  =>This specified instead of Accept header(-H "Accept:...).
    Specifying both should not be an problem

--data "<deployment-descriptor/>"  
=================================
  =>This specified as empty deployment structure which does not affect deployment descriptor in kjar (if any).


Suggestions for improvement:

Please clearly document about this mandatory requirement of REST API command  to 'deploy' kjar against WLS.


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