[infinispan-dev] CacheLoader and CacheStore

[Ray Tsang]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130815/cb95a482/attachment.html