Since there was no opposition, I committed the proposed changes.
Mathieu Lirzin writes:
> Hello Michael,
>
> Michael Brohl writes:
>
>> sorry for the late reply. I meant the loaders configuration attribute
>> and corresponding loading code:
>>
>> > loaders="main,rmi,load-data,test"
>>
Hello Michael,
Michael Brohl writes:
> sorry for the late reply. I meant the loaders configuration attribute
> and corresponding loading code:
>
> loaders="main,rmi,load-data,test"
> class="org.apache.ofbiz.base.container.ComponentContainer"/>
Ah I see what you meant. To my understanding,
Hi Mathieu,
sorry for the late reply. I meant the loaders configuration attribute
and corresponding loading code:
class="org.apache.ofbiz.base.container.ComponentContainer"/>
Best regards,
Michael
Am 14.06.19 um 21:30 schrieb Mathieu Lirzin:
Hello Michael,
Michael Brohl writes:
Hello Michael,
Michael Brohl writes:
> thanks for your proposal. Just a few questions to get the whole picture:
>
> 1. do we really have a complexity problem here? The removed code seems
> not too complicated or long.
I would claim that we have a complexity problem in OFBiz in
general. Some is
Hi Mathieu,
thanks for your proposal. Just a few questions to get the whole picture:
1. do we really have a complexity problem here? The removed code seems
not too complicated or long.
2. what do we lose with the removal? I see one can not only configure
the ComponentContainer class but
Hello,
To extend the containers loaded on startup, it is possible define a
container element either in the global “ofbiz-containers.xml” file or in
the “ofbiz-component.xml” file from each component.
This redundancy adds extra complexity in the startup process for no good
extensibility reason.
