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
