[
https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681050#comment-13681050
]
Amichai Rothman commented on DOSGI-108:
---------------------------------------
I think this fix is problematic:
* It changed a String+ property parsing method (normalizeStringPlus) to accept
a single comma-separated string and split it into an array of strings, while I
can't find any indication in the specs that this is a valid interpretation of a
String+ property value. If I am correct, then we are actually encouraging users
to use a non-compliant (and thus non-portable) configuration, and possibly
propagating the error to other properties which are parsed using the same
method.
* The two properties in the link above are said to be of type String, while the
specs say they are in fact of type String+. Our doc seems incorrect, which
caused us to fix something that wasn't broken in the code. We should probably
just fix the docs (change the property type, and remove the 'comma separated'
part).
* To my understanding of section 112.4.5 of the OSGi 4.2 compendium spec about
Declerative Services properties, under the bullet 'element body', a String[]
value for a property can be defined by omitting the value attribute from an
element, and instead putting the values on separate lines in the element body.
So in our case we would replace e.g.
{code:xml}
<property name="service.exported.interfaces" value="interface1,interface2" />
{code}
with
{code:xml}
<property name="service.exported.interfaces">
interface1
interface2
</property>
{code}
(disclaimer: I didn't try this - I'm just reading the spec).
I think the proper fix is to revert the code changes, fix the documentation,
and let users change their configuration into a valid one. As a bonus, this
would also allow us to consolidate the 4 different String+ parsing utility
methods in our codebase into one.
Any thoughts? Did I miss anything?
Also, how should we handle backward compatibility on this? Put a bold warning
in the docs? Make comma-separated values deprecated but still work for another
version or two? Just fix it and write about it in the release notes?
> service.exported.interfaces doesn't support comma-seperated String value
> ------------------------------------------------------------------------
>
> Key: DOSGI-108
> URL: https://issues.apache.org/jira/browse/DOSGI-108
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Affects Versions: 1.2
> Reporter: Bert Jacobs
> Assignee: Sergey Beryozkin
> Priority: Minor
> Fix For: 1.3
>
>
> I've got a Declarative Service component which has more than one interface. I
> declare the *service.exported.interfaces* property as "interface1,interface2"
> and the default type String (I cannot specify String[] per the SCR spec).
> According to
> http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiReference-ServiceProviderpropertiesForConfiguringSOAPbasedservicesandconsumers
> this String can be split on comma's.
> The service won't deploy because the *RemoteServiceAdminCore* class _doesn't_
> split this String and hence won't recognize the interfaces.
> Tested with 1.3-SNAPSHOT, built on 2012-01-23.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
