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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org