search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[REST] Incorrect service property representation in XML format #2730

Closed bjhargrave closed 9 years ago

bjhargrave commented 9 years ago

Original bug ID: BZ#2862 From: Petia Sotirova <p.sotirova@prosyst.bg> Reported version: R6

bjhargrave commented 9 years ago

Comment author: Petia Sotirova <p.sotirova@prosyst.bg>

Service properties with array values are represented as single value, with accumulated all array elements.

e.g. JSON representation: "protocol":["bundleentry","bundleresource"]

XML representation:

In specification array values are not explicitly mentioned:

... ... ...

Now in the CT I'm expecting this representation, but it also could be incorrect:

...
bjhargrave commented 9 years ago

Comment author: Jan Rellermeyer <rellermeyer@us.ibm.com>

The handling of array values is indirectly specified by the following paragraph in the spec: "Note: service properties are represented using the same method as used for the property XML element in the Declarative Services specification, see Property and Properties Elements on page 195." BJ pointed me to this as I also did not notice it before. In DS, arrays are serialized as newline-separated content of the property tag.

I think my implementation is correct and the TCK needs to be changed.

bjhargrave commented 9 years ago

Comment author: Petia Sotirova <p.sotirova@prosyst.bg>

In my opinion, according to Declarative Services properties specification, our example for "protocol" property with value String[]{"bundleentry", "bundleresource"} must be returned as:

bundleentry bundleresource

And both - RI and CT need to be changed, because now XML representation is

bjhargrave commented 9 years ago

Comment author: Jan Rellermeyer <rellermeyer@us.ibm.com>

Are you sure you are running on the head of the repo? Arrays are definitely not transmitted as a value attribute anymore but while checking the code I noticed a bug that I fixed and that could have lead to the n-1 argument of an array not being newline-separated correctly.

bjhargrave commented 9 years ago

Comment author: Petia Sotirova <p.sotirova@prosyst.bg>

I changed the test and it passes now. Maybe I didn't worked with the last version of the RI.

bjhargrave commented 9 years ago

Comment author: @bjhargrave

(In reply to Petia Sotirova from comment BZ#2)

In my opinion, according to Declarative Services properties specification, our example for "protocol" property with value String[]{"bundleentry", "bundleresource"} must be returned as:

bundleentry bundleresource

This is the correct XML representation for a String[] value.

bjhargrave commented 9 years ago

Comment author: @bjhargrave

(In reply to BJ Hargrave from comment BZ#5)

(In reply to Petia Sotirova from comment BZ#2)

In my opinion, according to Declarative Services properties specification, our example for "protocol" property with value String[]{"bundleentry", "bundleresource"} must be returned as:

bundleentry bundleresource

This is the correct XML representation for a String[] value.

bundleentry bundleresource

is also valid and the CT should allow this. The key thing is that the values are in the text of the property element (not the value attribute) and that newlines separate them.

bjhargrave commented 9 years ago

Comment author: @bjhargrave

I updated the test with https://osgi.org/gitweb/build.git/commit/1501328b30455325130ceb3897a203c1c5f15217.

Closing as fixed.