RE: Regarding Configuration Types

[Leschke, Scott]

Ø  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:tim.w...@paremus.com]
Sent: Monday, February 26, 2018 7:13 AM
To: user@karaf.apache.org
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 
<fragility...@gmail.com<mailto:fragility...@gmail.com>> 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 
<slesc...@medline.com<mailto:slesc...@medline.com>> 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

Re: Regarding Configuration Types

[Tim Ward]

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

Re: Regarding Configuration Types

[Ryan Moquin]

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

Regarding Configuration Types

[Leschke, Scott]

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