[infinispan-dev] Re: property tags in configuration files

[Vladimir Blagojevic]

Mircea,

I use this annotation to denote property:

@Retention(RetentionPolicy.RUNTIME)
@Target( { ElementType.METHOD, ElementType.FIELD })
public @interface ConfigurationProperty {
    String parentElement();
    String name();
    String description() default "";
}

So you can annotate any method to denote a certain property. If you need 
to annotate more than one property you can use


@Retention(RetentionPolicy.RUNTIME)
@Target( { ElementType.METHOD})
public @interface ConfigurationProperties {
    ConfigurationProperty [] elements();
}


We can annotate those methods with multiple properties

    @ConfigurationProperties(elements = {
             @ConfigurationProperty(name = "maxThreads", parentElement = 
"asyncListenerExecutor"),
             @ConfigurationProperty(name = "threadNamePrefix", 
parentElement = "asyncListenerExecutor") })
    public void setAsyncListenerExecutorProperties(Properties 
asyncListenerExecutorProperties) {
       testImmutability("asyncListenerExecutorProperties");
       this.asyncListenerExecutorProperties = 
toTypedProperties(asyncListenerExecutorProperties);
    }

and any of those simple ones as well....


Anything wrong with this simple approach?




On 6/19/09 11:58 AM, Mircea Markus wrote:
> Continuing a conversation Vladimir and I had on irc, about how 
> <property> tags can be be listed in the documentation.
>
> <property> are a way to configure extension points (e.g. CacheStore 
> implementations, ScheduledExecutorFactory implemetations etc), e.g:
>
> <replicationQueueScheduledExecutor 
> factory="org.infinispan.executors.DefaultScheduledExecutorFactory">
> <property name="threadNamePrefix" value="ReplicationQueueThread"/>
> </replicationQueueScheduledExecutor>
>
> "threadNamePrefix" property is specific to 
> DefaultScheduledExecutorFactory, other implementations of 
> ScheduledExecutorFactory would not recognize it, and/or use different 
> properties.
> So there's no way to handle "property" tags as the other 'regular' 
> attributes that map to fixed configuration elements: e.g. 
> transportClass maps to GlobalConfiguration#transportClass etc.
> Even more, in some situations these properties are not being used to 
> call setters on the target objects, but are being passed all together 
> through a java.util.Properties: which makes them impossible/harder to 
> annotate.
>
> On the other hand it would be very nice to have all the properties of 
> default extension points (e.g. FileCacheStore, 
> JdbcStringBasedCacheStore etc) having all the documentation exposed 
> through annotations.
> A possible way I see to make this working is:
> 1) create a new annotation to denote an extension point, 
> @ExtenssionPoint(defaultImplementations={ClassName1, ClassName2, 
> ClassName3})
> e.g.
>
> CacheLoaderConfig {     
> @ExtenssionPoint(defaultImplementations={FileCacheStore.class, 
> JdbcStringBasedCacheStore.class}) //this will break module dependency, 
> guess strings should be used
>    void setCacheLoaderClassName(String s);
> }
>
> 2) For all existing extension points the tool will create a different 
> table containing all its specific properties, obtained by parsing 
> class's @Property tags
>
> 3) Make all the current extension points that use java.util.Property 
> are replace by setters that can be annotated: this way we would remain 
> consistent in all code, and IMHO the code would be more readable
>
> wdyt?
> Cheers,
> Mircea
>