You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2008/09/10 11:10:53 UTC
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a stable
version)
Thorsten Scherler wrote:
> On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
...
> The first solution is fast to implement and seems quite clean. The
> downside is that we cannot use xml anymore. Which actually IMO is not
> that bad since maybe we start to use the actual forrest.properties.xml
> to configure contracts.
>
> The second solution is more complicated to implement since the
> aggregation has to be done in the DispatcherTransformer which does not
> feel right but we could use xml in the properties.
>
> Personally the cleaner solution is 1 but that would break downward
> compatible by a couple of contracts.
>
> WDYT?
I haven't thought long and hard about this. I'm going on your assessment
and my gut reaction.
I'd say go for option 1 because:
a) I like that it brings more configuration into the new properties system
b) you said it is easier to implement
c) we currently have no use case for using XML in the properties
d) if we find a use case for XML we can deal with it at that point (and
maybe implement the second solution by adapting the properties system to
allow XML)
Ross
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a stable
version)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2008-09-10 at 10:10 +0100, Ross Gardler wrote:
>> Thorsten Scherler wrote:
>>> On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
>> ...
>>
>>> The first solution is fast to implement and seems quite clean. The
>>> downside is that we cannot use xml anymore. Which actually IMO is not
>>> that bad since maybe we start to use the actual forrest.properties.xml
>>> to configure contracts.
>>>
>>> The second solution is more complicated to implement since the
>>> aggregation has to be done in the DispatcherTransformer which does not
>>> feel right but we could use xml in the properties.
>>>
>>> Personally the cleaner solution is 1 but that would break downward
>>> compatible by a couple of contracts.
>>>
>>> WDYT?
>> I haven't thought long and hard about this. I'm going on your assessment
>> and my gut reaction.
>>
>> I'd say go for option 1 because:
>>
>> a) I like that it brings more configuration into the new properties system
>>
>> b) you said it is easier to implement
>>
>> c) we currently have no use case for using XML in the properties
>>
>> d) if we find a use case for XML we can deal with it at that point (and
>> maybe implement the second solution by adapting the properties system to
>> allow XML)
>>
>
> To not break downward compatibility I will implement the option 1 but
> with a flag "allowXmlProperties". I added the javadoc that setting this
> properties to true will be paid by performance but this let our current
> dispatcher user decide when to update their contracts and structurer.
>
Perfect.
Ross
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a
stable version)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-09-10 at 10:10 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
>
> ...
>
> > The first solution is fast to implement and seems quite clean. The
> > downside is that we cannot use xml anymore. Which actually IMO is not
> > that bad since maybe we start to use the actual forrest.properties.xml
> > to configure contracts.
> >
> > The second solution is more complicated to implement since the
> > aggregation has to be done in the DispatcherTransformer which does not
> > feel right but we could use xml in the properties.
> >
> > Personally the cleaner solution is 1 but that would break downward
> > compatible by a couple of contracts.
> >
> > WDYT?
>
> I haven't thought long and hard about this. I'm going on your assessment
> and my gut reaction.
>
> I'd say go for option 1 because:
>
> a) I like that it brings more configuration into the new properties system
>
> b) you said it is easier to implement
>
> c) we currently have no use case for using XML in the properties
>
> d) if we find a use case for XML we can deal with it at that point (and
> maybe implement the second solution by adapting the properties system to
> allow XML)
>
To not break downward compatibility I will implement the option 1 but
with a flag "allowXmlProperties". I added the javadoc that setting this
properties to true will be paid by performance but this let our current
dispatcher user decide when to update their contracts and structurer.
Thanks for your feedback, Ross.
salu2
> Ross
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions