felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (FELIX-2096) Check MetaTypeProvider.getObjectClassDefinition(String, String) specification compliance
Date Sat, 22 Oct 2011 13:40:32 GMT

     [ https://issues.apache.org/jira/browse/FELIX-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Felix Meschberger resolved FELIX-2096.
--------------------------------------

       Resolution: Fixed
    Fix Version/s:  metatype-1.0.6

I think throwing if an ObjectClassDefinition cannot be returned is ok. So I resolve this issue
                
> 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
>             Fix For:  metatype-1.0.6
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message