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

[Manik Surtani]

Hmm, this won't work - the allowed and documented properties would  
have to be linked to a specific implementation of a service.  E.g., in  
the case of asyncListenerExecutor, maxThreads and threadNamePrefix are  
only valid if you use a DefaultExecutorFactory.  A custom  
ExecutorFactory may have a different set of properties.

And in the case where we ship more than 1 impl (e.g., CacheStores)  
we'd need to document which properties pertain to which cache store  
impl.

Perhaps a better way about this - since this is for documentation only  
- is to simply have a @ConfigurationProperties (parentElement = "",  
linkedInterface = ExecutorFactory.class) where the docs would suggest  
that these elements/setter takes arbitrary properties, as expected by  
the implementation of <linkedInterface> specified.  And a link to  
<linkedInterface> javadocs, so that each impl would document the  
properties it expects in its javadocs (as we already do).


On 19 Jun 2009, at 12:31, 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
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org