Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Fix resource population to DB.
Change-Id: Iae25ce2f15fa121a45a55559458fcbbd217f2c7d
Issue-ID: SO-624
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Issue-ID: SO-628
Change-Id: I6e9e44d453a72b4e9ec1a0abe99eb8028aa5ba1a
Signed-off-by: Marcus G K Williams <marcus.williams@intel.com>
|
|
Issue-ID: SO-628
Change-Id: I3bd802fc966f466b12556d19e347a130e152a51d
Signed-off-by: Marcus G K Williams <marcus.williams@intel.com>
|
|
Update release notes.
Change-Id: Ie353abb910c752557a99944528a9157c45ce8073
Issue-ID: SO-627
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
|
|
Change-Id: I41bf2c4d12345d46d8bf008f79d6610592e3b645
Issue-ID: SO-625
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Change-Id: I526d79d602d27c7c734bd1e38a4733176bd55f15
Issue-ID: SO-619
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Issue-ID: SO-622
Change-Id: If8260ee70d3c632325939affcbd80258b2602c99
Signed-off-by: Brian Freeman <bf1936@att.com>
|
|
This commit adds some robustness to the interface between the
API-H and BPMN, specifically, in how the response is handled.
I don't have proof, but there appears to be some randomness to
the json provider behavior when used with the jax-rs. Sometimes,
the serializer is adding the root element, and sometimes it
is not. Maybe there's something wrong with the configuration.
Maybe we have competing json providers. I couldn't pin this
down.
I'm almost certain it is the presence of the root element in
the content that causes the API-H code to fail parsing of the
BPMN response. This doesn't kill the request, as you might
expect, but rather, the API-H passes the BPMN response through
to the client (VID, or policy, or whatever).
The original problem (SO-586) was "fixed" by "removing the
wrapper". This "wrapper" is a needed feature of the interface
between BPMN and the API-H. We shouldn't have removed it.
The fact that the "fix" appeared to work is due to the
behavior I described in the previous paragraph. The API-H
chokes on the message, and it passes it through unchanged.
Not really what we want.
So, I don't know why the jackson/json behavior is flaky and
different now, but I can (and did) modify the API-H so it can
parse a json message whether or not it has a root element.
Note that WorkflowResponse.java (in BPMN) and CamundaResponse.java
(in the API-H) are basically the same bean representing the
message format. Seems less than ideal to have two different
classes.
Also note that I changed the name of the "response" attribute
of the WorkflowResponse and CamundaResponse classes to "content".
Got tired of seeing this nonsense everywhere in the code:
response.getResponse()
Change-Id: Icaf70f8457de99e493cf882170fe778c620308c9
Issue-ID: SO-586
Issue-ID: SO-618
Signed-off-by: Rob Daugherty <rd472p@att.com>
|
|
Change-Id: I04144bbd22773dfda08d7b13f16080930b7edb3a
Issue-ID: SO-621
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Change-Id: I7b28cc713929400b03b7e567bf9823d82631a1e9
Issue-ID: SO-617
Signed-off-by: Lukasz Muszkieta <lukasz.muszkieta@nokia.com>
|
|
Change-Id: I57525e367ddf5bdbbc13f9efa9e93fda4fb6748e
Issue-ID: SO-372
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
|
|
|
|
csar files:
1. resource_Extvl.csar
2. service-ServiceFdnt-csar-0904-2.csar
3. service-ServiceFdnt-with-allotted.csar
4. service_Rg516VmmscSrvc_csar.csar
Change-Id: I9e56bf3beaeeb858d91c4e9928789458ed9ba75f
Issue-ID: SO-611
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
|
|
Fix bugs reported by sonar
Change-Id: I0d3445856eb45533d904443b60d75c8aa03e5881
Issue-ID: SO-580
Signed-off-by: Ethan Lynn <ethanlynnl@vmware.com>
|
|
csar files:
1. resource_Extvl.csar
2. service-ServiceFdnt-csar-0904-2.csar
3. service-ServiceFdnt-with-allotted.csar
4. service_Rg516VmmscSrvc_csar.csar
Change-Id: I8688a8a29508c9332eaa8a0130ff2f79db5308dd
Issue-ID: SO-611
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
Use new variable in convertJsonToCloudOrchestrationRequest,
fix bug reported by sonar.
Change-Id: I3f95bd410d950d4661584c1510a66ce90d6785d5
Issue-ID: SO-580
Signed-off-by: Ethan Lynn <ethanlynnl@vmware.com>
|
|
Invenroty and MultiVIM APIs updated
Change-Id: Ia72eaae208f94f2dff59a833661b181b6df1768b
Issue-ID: SO-413
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
|
|
When the workflow response succeeds, the requestReferences object is being wrapped by "WorkflowResponse": {"response": {... and all the other fields from the WorkflowResponse object are being included as well. Adding a WorkflowResponseSerializer didn't seem to work since the root node was still included and there was no ObjectMapper in which to set WrapRootValue to false. So this is the next best thing.
Patch 2 fixes most of the broken unit tests.
Change-Id: Ifa5bd02e70b23f41c9042ac207848c8ade77313a
Issue-ID: SO-586
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
UUI APIs, SDC APIs updated
Change-Id: I77a245217197b95b1735e75c8ff0bb09c2772d70
Issue-ID: SO-413
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
This is related to recent CloudConfig fixes. One change was apparently
not submitted in the last batch.
Change-Id: I8dcc49f7d808e0d842af3f568f5815fb48870acc
Issue-ID: SO-584
Signed-off-by: Rob Daugherty <rd472p@att.com>
|
|
|
|
|
|
|
|
|
|
Remove over 100 whitespaces from logger filename which causes the unit
tests to fail in some development environments.
Change-Id: I068f4d4562b635b19889c3537282949665348c21
Issue-ID: SO-604
Signed-off-by: Michal Kabaj <michal.kabaj@nokia.com>
|
|
VFC APIs, Policy APIs updated
Change-Id: I492cc817f57d6f6410ba5ae3cdef6c9f3db1786d
Issue-ID: SO-413
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
Use tosca parser without resolving GetInput.
Change-Id: I964464dd76c0bdd096e67ce78ab4cc7c2e76a167
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Fix progress update for VFC resources.
Change-Id: Ibd7d8fb3a399ae2b40ca82e459a7e47c05cbac6a
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Set operation type value, to reflect in DB entries.
Change-Id: I2f56bf5f33912645d17bbed2fc759f9354a0ba7b
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Fix warning in DoDeleteE2E bpmn file.
Change-Id: I50b1ad5502fc08692775d2f5d9050c3796dd32b1
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Change-Id: I0a166b867dcacad4133c8fc679606c381cb5389a
Issue-ID: SO-602
Signed-off-by: Bancala, Ben (bb3476) <bb3476@att.com>
|
|
Change-Id: I3e27ec0d1487eb68e8c54d27508b58233bf49808
Issue-ID: SO-602
Signed-off-by: Bancala, Ben (bb3476) <bb3476@att.com>
|
|
...for some definition of the word "fix". There is still a lot
that's less than ideal about how CloudConfig is handled, and with
how the unit tests are written.
Change-Id: Ic8c66c64d336f22c141687cf41a4828810bf1aec
Issue-ID: SO-584
Signed-off-by: Rob Daugherty <rd472p@att.com>
|
|
To prevent appc snapshot problem
Also change appc version to SNAPSHOT
Change-Id: Ifce05b7f44ccc70a2d654526d67da873dd325dcd
Issue-ID: SO-605
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Change-Id: I05f4648ff898a54e7a00d899d97129746172cdb4
Issue-ID: SO-603
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Somebody changed some variables from static to non-static, and this
broke the CloudConfig loading logic.
I changed them back.
Change-Id: Id7dca76a4f0af0209ebd6cef8f3e0209c3f7a022
Issue-ID: SO-584
Signed-off-by: Rob Daugherty <rd472p@att.com>
|
|
|
|
|
|
|
|
deleteResource bugs fix
Change-Id: Idaa55084f5ecb0dd3636c232cebc14fa5f06430a
Issue-ID: SO-578
Signed-off-by: Yulian Han <elaine.hanyulian@huawei.com>
|
|
Change-Id: Idc5ee56660da31f08fd8ed3a67b7cd28f9844f43
Issue-ID: SO-596
Signed-off-by: Lukasz Muszkieta <lukasz.muszkieta@nokia.com>
|
|
Fix null attribute for aai relationship.
Change-Id: Ifa3a7ec7101c1564be68d97a70d0cafd40d581fe
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Change to sdncadapter for service call
Change-Id: I9011e69fba20d4d0f83705455791b7357e2f5bb0
Issue-ID: SO-587
Signed-off-by: c00149107 <chenchuanyu@huawei.com>
|
|
|
|
|