I think that having a whole series of separate override files is a bad
design, and it would be better to be able to say:

KARAF_ETC=/my/override-directory:/the/directory/with/the/usual/files

If JB ever accepts my first patch, I'd be willing to take a run at coding
this :-)


On Fri, Aug 21, 2015 at 10:13 AM, Andreas Kuhtz <[email protected]>
wrote:

> Hi JB,
>
> I had the same requirement some weeks ago and would be happy if
> systemoverride.properties would be available in the future.
>
> Regards,
> Andreas
>
> 2015-08-21 16:06 GMT+02:00 Jean-Baptiste Onofré <[email protected]>:
>
>> Why don't you provision bin/setenv with your System properties ?
>>
>> I can add a systemoverride.properties file, but it's basically the same
>> as bin/setenv.
>>
>> Regards
>> JB
>>
>>
>> On 08/21/2015 04:01 PM, maggu2810 wrote:
>>
>>> JB, BM explained it correctly.
>>> If I extend the standard file I have to merge the upstream changes all
>>> the time.
>>> I just want to add a file with my system properties that are necessary
>>> for my assembly.
>>>
>>> config.properties could be extended and entries could be overwritten
>>> by custom.properties entries.
>>> system.properties could be extended and entries could be overwritten
>>> by ??? entries.
>>>
>>> 2015-08-21 15:56 GMT+02:00 Benson Margulies [via Karaf]
>>> <[email protected]>:
>>>
>>>> JB, someone might feel squeamish about the process of:
>>>>
>>>> 1) copy file from standard distro
>>>> 2) edit
>>>> 3) include in assembly
>>>>
>>>> . They might be trying to find a way to just put the content they want
>>>> into
>>>> a separate file. I'm a bit confused here, because I could have sworn
>>>> that
>>>> things I put into custom.properties did indeed work as if they were
>>>> system
>>>> properties, but I guess I might have fooled myself somehow. The sequence
>>>> above is certainly the reliable solution that I think you are referring
>>>> to.
>>>>
>>>>
>>>> On Fri, Aug 21, 2015 at 9:47 AM, Jean-Baptiste Onofré <[hidden email]>
>>>> wrote:
>>>>
>>>>>
>>>>> It's the same: custom.properties is the "override" of the
>>>>> config.properties, it's not for System properties.
>>>>>
>>>>> @maggu, I'm not sure to understand what you want to do.
>>>>>
>>>>> You want to override or add system.properties ? Why not just updating
>>>>> the
>>>>> system.properties ? Not sure to follow you.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 08/21/2015 03:44 PM, Benson Margulies wrote:
>>>>>
>>>>>>
>>>>>> Wait, don't use 'overrides.properties',  use 'custom.properties'.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 21, 2015 at 9:41 AM, maggu2810 <[hidden email]
>>>>>> <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>      2015-08-21 15:25 GMT+02:00 Benson Margulies [via Karaf]
>>>>>>      <[hidden email]
>>>>>>      <mailto:[hidden email]>>:
>>>>>>
>>>>>>      > It is read at startup. The important question is whether it
>>>>>> ends up
>>>>>> in the
>>>>>>      > etc directory. Have you looked at the generated assembly to
>>>>>> see if
>>>>>> the file
>>>>>>      > is in the right place? Perhaps it's not travelling from
>>>>>> src/main/resources
>>>>>>      > to etc correctly.
>>>>>>
>>>>>>      Tried that one:
>>>>>>
>>>>>>      ===
>>>>>>
>>>>>>      $ cat etc/overrides.properties
>>>>>>      test_overrides=true
>>>>>>
>>>>>>      The file overrides.properties must not be used for this, Karaf
>>>>>> cannot
>>>>>>      be started:
>>>>>>
>>>>>>      2015-08-21 15:37:50,481 | ERROR | pool-1-thread-1  |
>>>>>>      BootFeaturesInstaller            | 8 -
>>>>>> org.apache.karaf.features.core
>>>>>>      - 4.0.0 | Error installing boot features
>>>>>>      java.lang.IllegalArgumentException: No path specified on clause:
>>>>>>      test_overrides = true
>>>>>>               at
>>>>>>
>>>>>>
>>>>>> org.apache.felix.utils.manifest.Parser.parseClauses(Parser.java:73)[8:org.apache.karaf.features.core:4.0.0]
>>>>>>
>>>>>>      ===
>>>>>>
>>>>>>      $ cat etc/override.properties
>>>>>>      test_override=true
>>>>>>
>>>>>>      karaf@root()> system:property | grep test
>>>>>>      karaf@root()>
>>>>>>
>>>>>>      So, the file is not evaluated and the content is not set as
>>>>>> system
>>>>>>      properties.
>>>>>>
>>>>>>      ===
>>>>>>
>>>>>>      $ tail -n 1 etc/system.properties
>>>>>>      test_system=true
>>>>>>
>>>>>>      karaf@root()> system:property | grep test
>>>>>>      test_system=true
>>>>>>
>>>>>>      That was expected.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>      --
>>>>>>      View this message in context:
>>>>>>
>>>>>>
>>>>>> http://karaf.922171.n3.nabble.com/system-properties-file-multiple-ones-tp4041994p4042001.html
>>>>>>      Sent from the Karaf - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> [hidden email]
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> If you reply to this email, your message will be added to the discussion
>>>> below:
>>>>
>>>> http://karaf.922171.n3.nabble.com/system-properties-file-multiple-ones-tp4041994p4042004.html
>>>> To unsubscribe from system properties file (multiple ones), click here.
>>>> NAML
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/system-properties-file-multiple-ones-tp4041994p4042006.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> [email protected]
>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>

Reply via email to