On 4/7/2010 9:34 AM, Bill Shannon wrote:
> Jerome Dochez wrote on 4/8/10 1:59 AM:
>
>> I can see 2 disadvantages :
>>
>> 1. the default-config.xml was separated from the domain.xml meaning it
>> was surviving the domain deletion or supporting the multi domain
>> situations.
>>
> Also meaning that you couldn't customize it per-domain, like you could
> in v2. Unless it's copied into each domain, which means it wouldn't
> survive domain deletions.
>
right because the default-config.xml becomes part of the domain.xml, it
is still customizable per domain, however it won't survive the domain
deletion.
at the end, we remove one level of indirection by doing this, with all
the consequences it has.
>
>> 2. the deep copy of config element is not implemented, that might be
>> more work than adding the support for --target to CLI commands.
>>
> Support for --target has to be added no matter what, so that's not a
> relevant comparison.
>
>
ok I meant to be able to use --target to target the default-config.xml
> Why is it difficult to copy the config elements?
>
>
>
I just said it's not done. I don't expecting it to be very difficult,
it's just a recursive deepCopy but this is work that we did not have to
do so far and needs to be well tested.
>> as for the GUI, it we can make them switch to REST, they might still be
>> able to use set those default-config.xml
>>
> That would mean opening and managing another file, separately from domain.xml.
> Of course it can be done, but we're trying to understand why it's so
> difficult to copy xml elements such that we should consider a different
> and less compatible approach.
>
the compatible approach is not copy and keep the default-config.xml
separated. Am I misunderstanding something here ?
the resources URL would be different for managing that file versus
managing the domain.xml directly (just a 5 minutes design assumption I
am making here).