On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder@redhat.com> wrote:

On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism@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.

 
^ 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...



 

Cheers,

>
> On Aug 14, 2013, at 14:58, Mircea Markus <mmarkus@redhat.com> wrote:
>
>>
>> On 14 Aug 2013, at 18:48, Dennis Reed <dereed@redhat.com> wrote:
>>
>>>> I've written such parser on Friday, basically just copying and rewriting
>>>> the SingleFileCacheStore stuff (adding my own properties instead). It
>>>> took me about an hour and I don't hate anyone from infinispan team :)
>>>> Maybe I am already advanced ISPN user, but I don't consider it as a
>>>> complicated task as long as there is some template (simple cache-store
>>>> implementation) I can use for reference.
>>>
>>> If it took you an hour as an advanced user that's intimately familiar
>>> with Infinispan to implement it and get it working,
>>> that means for many of our customers it could take days, and quite a few
>>> interactions with support.
>>>
>>> Compare that to the current implementation where ISPN does the XML
>>> parsing and calls setters, which takes 0 time no matter the competence
>>> of the user.
>>>
>>> I'm 100% *against* forcing customers to write their own XML parsing.
>>
>> +1
>> The current parsing-free approach will be kept. Just that we'll add a template for writing stores that would contain a sample optional parser.
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder@redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev