[infinispan-dev] Configuration reference - final solution
Vladimir Blagojevic
vblagoje at redhat.com
Wed Aug 26 09:12:46 EDT 2009
Hey guys,
I've committed a massive change that removed all our annotations that
were previously used for configuration. A new solution and a more
permanent one is in place. It is described below.
In the next day or so I'll complete a few minor remaining tasks along
with documentation Manik outlined below.
Regards,
Vladimir
On 21/08/09 12:33 PM, Manik Surtani wrote:
> Yeah, looks good to me. :-)
>
> Could you also pls create a wiki page - perhaps linked to
> http://www.jboss.org/community/wiki/InfinispanQuickStartGuideforDevelopers -
> on how to create new configuration elements.
>
> Basically, creating a new configuration variable should entail:
>
> 1. Adding setter and getter to the Configuration bean? What else?
> 2. Annotating accordingly - which annotations? Where? On setter?
> 3. Javadoc accordingly - any custom tags to use?
> 4. Unit tests and sample cfg files to ship? Where are these?
>
> Also, you should blog about this - and link to this wiki page in your
> blog!
>
> Thanks!
> Manik
>
> On 21 Aug 2009, at 11:28, Vladimir Blagojevic wrote:
>
>> On 21/08/09 12:18 PM, Manik Surtani wrote:
>>> I would say this should be on the infinispan-dev list - but the list
>>> is broken at the moment! :P
>>>
>>> On 21 Aug 2009, at 11:14, Vladimir Blagojevic wrote:
>>>
>>>> Hey,
>>>>
>>>> We have two options for the final HTML configuration reference
>>>> solution:
>>>>
>>>> - keep things as they are and maintain our documentation
>>>> annotations (CofigurationElement, ConfigurationAttribute etc)
>>>> - implement a new solution based on XML Schema and javadoc comments
>>>>
>>>> Since you are familiar with the first let me explain the second.
>>>> The new solution loads created XML Schema using XSOM library and
>>>> creates in-memory tree representation of that schema. Once that is
>>>> done it is very simple to create exact same reference as it is
>>>> today, however, the content would be coming from source file
>>>> javadoc, not annotations as it is today. We would simply document
>>>> our Java classes that correspond to XML schema elements with
>>>> special @ tags. All documentation related to attributes, general
>>>> element description in configuration reference would be coming from
>>>> our own javadoc @tags.
>>>>
>>>> One shortcoming of the new solution is that not all types of
>>>> loaders would be documented. Recall, how different loaders allow
>>>> special properties and how these are documented in configuration
>>>> reference. Proposed new solution would not contain these but as a
>>>> trade-off we would get rid of all these ConfigurationElement
>>>> annotations. Hmmm, now that I am writing this email I realize that
>>>> it would be still possible to do document all these different
>>>> loaders but it would require a bit more effort - an extra day or
>>>> two. It is doable.
>>>
>>> What does the 2nd solution entail by way of dependencies? I assume
>>> we already have all of the JSXB deps we need?
>> There extra two dependencies: xsom.jar and relaxngDatatype.jar
>>
>>> Perhaps a few more deps for the generation tool, but nothing more
>>> for the distro/runtime?
>>
>> Yes, strictly in tools project. These would not go into distro.
>>>
>>> Also, is there any impact (performance-wise or anything else) on the
>>> runtime?
>>
>> Maybe on tools execution time but infinispan runtime absolutely not.
>>
>>>
>>> Finally, what are these extra Javadoc tags going to look like?
>>> Could you show us a short sample?
>>
>> /**
>> *
>> * @configElementRef locking
>> * @configElementDoc any documentation here
>> */
>> @XmlAccessorType(XmlAccessType.PROPERTY)
>> private static class LockingType extends
>> AbstractNamedCacheConfigurationBean{
>>
>>
>> /** The serialVersionUID */
>> private static final long serialVersionUID = 8142143187082119506L;
>>
>> @Dynamic
>> private Long lockAcquisitionTimeout = 10000L;
>>
>> private IsolationLevel isolationLevel =
>> IsolationLevel.READ_COMMITTED;
>>
>> private Boolean writeSkewCheck = false;
>>
>> private Boolean useLockStriping = true;
>>
>> private Integer concurrencyLevel = 500;
>>
>> /**
>> * @configElementDoc reference documentation here
>> */
>> @XmlAttribute
>> public void setLockAcquisitionTimeout(Long
>> lockAcquisitionTimeout) {
>> testImmutability("lockAcquisitionTimeout");
>> this.lockAcquisitionTimeout = lockAcquisitionTimeout;
>> }
>>
>> /**
>> * @configElementDoc reference documentation here
>> */
>> @XmlAttribute
>> public void setIsolationLevel(IsolationLevel isolationLevel) {
>> testImmutability("isolationLevel");
>> this.isolationLevel = isolationLevel;
>> }
>>
>> /**
>> * @configElementDoc reference documentation here
>> */
>> @XmlAttribute
>> public void setWriteSkewCheck(Boolean writeSkewCheck) {
>> testImmutability("writeSkewCheck");
>> this.writeSkewCheck = writeSkewCheck;
>> }
>>
>> /**
>> * @configElementDoc reference documentation here
>> */
>> @XmlAttribute
>> public void setUseLockStriping(Boolean useLockStriping) {
>> testImmutability("useLockStriping");
>> this.useLockStriping = useLockStriping;
>> }
>>
>> @XmlAttribute
>> public void setConcurrencyLevel(Integer concurrencyLevel) {
>> testImmutability("concurrencyLevel");
>> this.concurrencyLevel = concurrencyLevel;
>> }
>> }
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
More information about the infinispan-dev
mailing list