[infinispan-dev] property tags in configuration files

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