Check MetaTypeProvider.getObjectClassDefinition(String, String) specification
compliance
----------------------------------------------------------------------------------------
Key: FELIX-2096
URL: https://issues.apache.org/jira/browse/FELIX-2096
Project: Felix
Issue Type: Task
Components: Metatype Service, Specification compliance
Affects Versions: metatype-1.0.4
Reporter: Felix Meschberger
Assignee: Felix Meschberger
I have been running the Apache Felix Metatype Service implementation through
the OSGi CT and found an issue with the
MetaTypeProvider.getObjectClassDefinition(String id, String locale) method as
used in the testMetaTypeProvider test.
The method is defined in Section 105.13.4.2 in the R4.2 Compendium
specification to:
* either return an ObjectClassDefinition for the requested id and locale
* or throw an IllegalArgumentException if either id or the locale is invalid
THe CT test calls the getObjectClassDefinition three times:
(1) getObjectClassDefinition("", "du");
> Expects null, but the id here is definitely invalid (empty string) and not
> defined, thus an exception might be more appropriate
> Our implementation returns null (which is presumably wrong) but passes the
> test
(2) getObjectClassDefinition("com.acme.23456789", "abc");
> Expects an exception due to the locale "abc" not provided as a file
> Our implementation returns null because the id "com.acme.23456789" is not
> declared
Here an exception is probably really expected because the id is not declared.
It may be expected due to the missing locale.
(3) getObjectClassDefinition("com.acme.foo", "du")
This test should pass as expected
A question regarding invalidity is in place:
* What does "invalid" mean for the id ? Empty string ? Undefined/Undeclared
ObjectClassDefinition ?
* What does "invalid" mean for the locale ? This is tricky, since locales
form an implicit inheritance hierarchy and even though
translations for an exact locale may not be provided, such
translations may be provided by the parent. And the default
definitions should probably be the root of this tree. E.g. given the
locale is de_CH and translations exist for de, it
is IMHO expected to get a translation for de instead of de_CH.
NB: Returning null as our implementation does is probably definitely wrong
according to the spec, since null is not defined to be a valid result.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
