[infinispan-dev] CacheLoader and CacheStore

[Sanne Grinovero]

Could we generate the parser and/or XSD as JGroups does with
org.jgroups.annotations.Property ?


On 15 August 2013 16:52, Ray Tsang <saturnism at gmail.com> wrote:
>
>
>
> On Thu, Aug 15, 2013 at 11:45 AM, Radim Vansa <rvansa at redhat.com> wrote:
>>
>> On 08/15/2013 03:57 PM, Ray Tsang wrote:
>>
>>
>>
>>
>> On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder at redhat.com>
>> wrote:
>>>
>>>
>>> On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism at gmail.com> wrote:
>>>
>>> > I actually did not enjoy writing parsers and config builders etc…
>>>
>>
>> i felt that writing the parsers are error prone - there are many places to
>> touch when adding a property - maybe I just didn't follow the best
>> example...
>>
>> i'm just thinking out loud but perhaps there is a way to consolidate the
>> configuration builder, configuration, configuration parser, and xsd with a
>> single set of metadata - after all, I think they are all trying to set the
>> same set of properties.
>>
>>
>> Well, it's true that the Maven build process could generate at least the
>> XSD automatically, and automatic parsing is not that complicated - in fact
>> I've done this in RadarGun, changing Mircea's original setter-way.
>> But in order to be able to use the programmatic configuration, you have
>> either write the builder yourself or generate it with some tool (I don't
>> think it would be right to generate further Java sources during the Maven
>> build, even if it is possible). And using tool for generation of some Java
>> code based on another code seems to me as another nasty complication.
>> Alltogether, writing *Configuration and *ConfigurationBuilder should be
>> enough, all the rest can be managed by runtime/build.
>>
>
> +1.  It just feel very redundant the way it is now.  condensing into
> Configuration and ConfigurationBuilder sounds great too, at least it's
> completely typesafe at this point.
>
> Otherwise, the way it is now, we have to keep property names in sync, and
> documentation in sync, and default values in sync, etc.. and 52 parser vs
> as7 parser? =(
>
>>
>>
>>
>>
>>>
>>> ^ Why not? Too verbose? Too many classes?
>>>
>>> I'd rather improve this than carry on supporting property-based
>>> configuration (any other type safety advocates?)
>>
>>
>> +1, the fact that I had to test both was a nuance...
>>
>> +1 as well
>>
>> Radim
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev