cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amichai Rothman (JIRA)" <>
Subject [jira] [Commented] (DOSGI-108) service.exported.interfaces doesn't support comma-seperated String value
Date Thu, 20 Jun 2013 17:50:24 GMT


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:
>             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
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:

View raw message