Ø As for why you don’t get the default - your configuration explicitly contains a mapping to the empty string. Defaults only apply when the key isn’t present, if it is present then you get the supplied value.
I can get that for String properties I guess and figured that was the answer, but for discrete properties, where a mapping without a value will give you an error even if a default is specified, it seems that getting the default may be more appropriate. Perhaps an annotation could be added that specified whether defaulting would occur in this case or not. I suspect that in most cases, this would be the preferred behavior. A similar approach might be desirable for trimming behavior but having too many annotations can make things ugly in a hurry. Does anybody have a use case where maintaining trailing white space in this sort of scenario (I do realize that java.util.properties behaves this way) is desirable? I honestly don’t think I’ve ever run into a case where I wanted the whitespace maintained. Just sayin’ :-) Regards, Scott From: Tim Ward [mailto:[email protected]] Sent: Monday, February 26, 2018 7:13 AM To: [email protected] Subject: Re: Regarding Configuration Types Scott, Those two issues are actually different things. The first one is to do with the defaulting of configuration, the second is to do with how File Install interprets property values with trailing spaces. As for why you don’t get the default - your configuration explicitly contains a mapping to the empty string. Defaults only apply when the key isn’t present, if it is present then you get the supplied value. Best Regards, Tim On 25 Feb 2018, at 21:14, Ryan Moquin <[email protected]<mailto:[email protected]>> wrote: If trimming was performed by default on tproperties, wouldn't that place a little extra performance overhead into OSGi vs developers just making sure there isn't trailing whitespace if they don't want it? It wouldn't be much, but it adds up... Ryan On Thu, Feb 22, 2018 at 12:52 PM Leschke, Scott <[email protected]<mailto:[email protected]>> wrote: I have a configuration type that has a fragment in it as shown below. @ProviderType @ObjectClassDefinition(name = "Provider Configuration") public @interface MetricProviderConfig { String schedule() default "0"; } If the associated property in a .cfg file exists but has no value, as in: schedule = I get the null string “” as opposed to the default which is what I would expect. While this is preferable to a null, which I got at some on some earlier Karaf release, I would think that you’d get the default whether the property didn’t exist or existed with no value. Another comment, which perhaps is more general to OSGi in this area, is that properties aren’t trimmed. I honestly can’t think of a use case where somebody would want trailing white space passed in. Also, if the configuration type exposes an enumeration, an error occurs. @ProviderType @ObjectClassDefinition(name = "Provider Configuration") public @interface MetricProviderConfig { MyEnum enumValue() default MyEnum.ENUM_VALUE; } So the first property below works, but the second one doesn’t. Is this by design? enumValue = ENUM_VALUE enumValue = ENUM_VALUE Regards, Scott
