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

[Mircea Markus]

This approach is nice and very effective, but I'm not sure will work for 
"property" tags.
that's because these property tags depend on the object they configure.
E.g.:
1) file cache store:
<loader 
class="org.infinispan.loaders.jdbc.binary.FileCacheStore">          
            <properties>
               <property name="location" value="/tmp"/>
            </properties>
<loader>

2) JDBC cache store:
<loader class="org.infinispan.loaders.file.FileCacheStore">          
            <properties>
               <property name="dropTableOnExit" value="false"/>
                <property name="bucketTableName" value="jdb_table_name"/>
                <property name="idColumnType" value="id_column_type"/> 
              
            </properties>
<loader>

As per this example, possible 'propery' tags within loader element 
depend on the value supplied to class, and that's what I was referring to.
Now logically, these properties are only present for extension points.
By extension point I mean something that is pluggable in ispn, e.g. 
CacheStore interface is an extension point as it can be implemented and 
plugged in.
What I was trying to define is a way to also document existing 
implementations of these extension points.


Vladimir Blagojevic wrote:
> 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
>>
>