[
https://issues.apache.org/jira/browse/DOSGI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689444#comment-13689444
]
Amichai Rothman commented on DOSGI-108:
---------------------------------------
Answering Sergey's previous question, the main things that triggered me to
raise this discussion, and which should be taken into consideration, are:
- This issue was opened not due to lacking functionality or an implementation
error, but simply due to overlooking how to configure things by the book (it
happens.) There was no real issue with DOSGi that needed solving, just a
friendly pointer to an external spec (which I've added above for anyone who
might stumble upon this). To the best of my knowledge a multi-valued property
is supported in DS/SCR, Blueprint, direct coding - what is the use case where
this extension is useful?
- I honestly don't know why the DOSGi website said the service property can be
comma separated (when at the time it was not supported in practice). Maybe
there was demand for this elsewhere, which should be considered. Maybe it was
just a documentation bug.
- I'm of the opinion that non-compliance with specs, and complexity in general,
should not be encouraged unless there is a significant benefit. Otherwise it
just ends up wasting people's time (whether devs or users).
- This is not just an extension of the spec, it actually breaks it. String+
properties are not limited in what strings they contain, and commas are valid
characters within them, so splitting them around commas is inviting a new bug.
The specific property discussed here contains interface/class names, so that's
safe for commas, but this is implemented as a general-purpose method that is
and will be used for other properties as well. I was considering adding a
boolean parameter specifying this, with an appropriate warning in its javadoc,
and doing the extra parsing only for this one property. Then again, supporting
this syntax in some properties and not in others is even more confusing to
users and complicates documentation.
- My guess is that this is functionality that is rarely used in any case (and
as mentioned before, not sure it even works - if not, then nobody uses it, and
even backwards compatibility is not needed). Most users just export one
interface.
So all things considered, I'm not convinced that it's useful enough (or at all)
to be worth the added complexity, implementation, documentation, non-compliance
and risks. Thus I recommended to just kill the feature, leaving only minimal
backwards-compatibility (support only for this particular property, with a
deprecated notice, and correcting the docs so this doesn't continue being used).
Of course, I may be wrong :-)
> 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
