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

[Emmanuel Bernard]

You mean people could actually populate beans themselves to  
programmatically create the InfiniSpan config?

On  Jun 22, 2009, at 09:25, Vladimir Blagojevic wrote:

> Hey,
>
> We want to use these annotations to create infinispan configuration  
> option documentation directly from the source code as well as to  
> read XML config files and populate corresponding configuration beans  
> with xml data.
>
> If we go with expressive annotations we would end up with many many  
> annotations....
>
>
> On 6/20/09 1:11 PM, Emmanuel Bernard wrote:
>> Guys, String based parameters are as much XML than well XML.
>> Can't you create nice clean expressive annotations
>>
>> @InfinispanConfig
>> public @interface ListenerExecutor {
>>  int maxThread() default 5;
>>  String theadNamePrefix() default "";
>> }
>>
>> etc
>>
>> On  Jun 19, 2009, at 13: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
>>
>