[infinispan-dev] Re: property tags in configuration files
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