[infinispan-dev] CacheLoader and CacheStore

Radim Vansa rvansa at redhat.com
Thu Aug 15 11:45:11 EDT 2013


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 
> <mailto:galder at redhat.com>> wrote:
>
>
>     On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism at gmail.com
>     <mailto: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.

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


More information about the infinispan-dev mailing list