@ConfigurationProperty I suggested is used only for documentation. Note
how @ConfigurationProperty does not have value, only name attribute. It
is because we already know how to populate corresponding beans. We
already have methods on those beans setProperties and so on. We only
need to document what are the valid property options for those beans....
On 6/22/09 10:02 AM, Mircea Markus wrote:
This approach is nice and very effective, but I'm not sure will
work
for "property" tags.
that's because these property tags depend on the object they configure.
E.g.:
1) file cache store:
<loader class="org.infinispan.loaders.jdbc.binary.FileCacheStore">
<properties>
<property name="location" value="/tmp"/>
</properties>
<loader>
2) JDBC cache store:
<loader class="org.infinispan.loaders.file.FileCacheStore">
<properties>
<property name="dropTableOnExit" value="false"/>
<property name="bucketTableName" value="jdb_table_name"/>
<property name="idColumnType" value="id_column_type"/>
</properties>
<loader>
As per this example, possible 'propery' tags within loader element
depend on the value supplied to class, and that's what I was referring
to.
Now logically, these properties are only present for extension points.
By extension point I mean something that is pluggable in ispn, e.g.
CacheStore interface is an extension point as it can be implemented
and plugged in.
What I was trying to define is a way to also document existing
implementations of these extension points.