Hello again JB,
Did you check whether it is possible to use system properties in
config.properties?
I've been experimenting a bit more with our custom Karaf distribution and I
think that the combination of:
a) Being able to use system properties in config.properties
b) Being able to specify optional includes in ${includes} (KARAF-1014)
Would benefit us a lot. Most of the things that need to be installation
specific can then be extracted into one or several property files that can
optionally be overridden per installation. We can then have one custom
distribution instead of several different ones.
I'm a bit anxious to be able to use this possibility.
/Bengt
2011/11/15 Bengt Rodehav <be...@rodehav.com>
> Thanks for your answers JB. I created the following JIRA:
>
> https://issues.apache.org/jira/browse/KARAF-1014
>
> /Bengt
>
>
> 2011/11/15 Jean-Baptiste Onofré <j...@nanthrax.net>
>
>> Hi Bengt,
>>
>> My comments inline:
>>
>>
>> I guess it's some kind of catch 22 going on here. I would really like to
>>> be able to use system properties at this point. Can I create a JIRA for
>>> this?
>>>
>>
>> It should work already. Let me take a look, I will raise a Jira if the
>> system variables are not used.
>>
>>
>>
>>> I can get it to work by using a relative path to specify where my
>>> custom.properties file reside. However, it appears that the "current
>>> directory" is not "karaf.home" but the "etc" directory under the Karaf
>>> installation. Is this by design?
>>>
>>
>> Yes, it's the default behavior. But it could make sense to be able to put
>> any absolute path here. Let me think about that.
>>
>>
>>
>>> Out of curiosity I also wonder why the property is called "${includes}"
>>> and not just "includes". I assume some "cleverness" is gong on here...
>>>
>>
>> It's because it's used and populated by others scripts.
>>
>>
>>
>>> Finally, I would like to have the possibility to not have to create my
>>> "custom" custom.properties. If I specify its location in the ${includes}
>>> property then Karaf fails to start if the file doesn't exist. I would
>>> like Karaf to pick up the file if it exists, otherwise, I would like
>>> Karaf to ignore it and just continue. That would allow us to provide
>>> custom variables if we wanted to but it wouldn't require each
>>> installation to have a custom.properties.
>>>
>>
>> It makes sense, Karaf should check if the file exists before trying to
>> load it. Could you raise a Jira for that ?
>>
>> Thanks
>> Regards
>> JB
>>
>>
>>> /Bengt
>>>
>>>
>>>
>>> 2011/11/11 Bengt Rodehav <be...@rodehav.com <mailto:be...@rodehav.com>>
>>>
>>>
>>> Perfect!
>>>
>>> I didn't know about the ${includes}. Will try it out as soon as
>>> possible.
>>>
>>> Thanks a lot,
>>>
>>> /Bengt
>>>
>>> 2011/11/11 Jean-Baptiste Onofré <j...@nanthrax.net
>>> <mailto:j...@nanthrax.net>>
>>>
>>>
>>> Hi Bengt,
>>>
>>> it's exactly the purpose of custom.properties.
>>>
>>> Basically:
>>> - system.properties is "reserved" for Karaf itself.
>>> - config.properties is "reserved" for "application"
>>> - custom.properties is "reserved" for your usage
>>>
>>> You can put the custom.properties where you want. You just need
>>> to update the ${includes} property in the etc/system.properties.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>>>
>>> Thanks for your reply JB,
>>>
>>> Yes, if I put the variables in custom.properties they can
>>> reference each
>>> other directly. Given these lines in custom.properties:
>>>
>>> /MyRootDir=C:/Temp/
>>> /MySubDir=${MyRootDir}/Sub/
>>>
>>>
>>> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>>>
>>> Thanks!
>>>
>>> I guess then that best practice is to use custom.properties
>>> for this?
>>> This is good since it doesn't (should not) contain any
>>> configuration
>>> out-of-the-box. I noticed that the
>>> karaf.systemBundlesStartLevel is
>>> defined there. I think that should be removed.
>>>
>>> Now if there was a way to specify that the custom.properties
>>> file should
>>> reside somewhere else then I would be very happy. The reason
>>> is that we
>>> do not want to put installation specific configuration in
>>> the Karaf
>>> installation. Do you have an update regarding this?
>>>
>>> /Bengt
>>>
>>>
>>> 2011/11/11 Jean-Baptiste Onofré <j...@nanthrax.net
>>> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net
>>>
>>> <mailto:j...@nanthrax.net>>>
>>>
>>>
>>> Hi Bengt,
>>>
>>> the system.properties is not directly evaluate.
>>>
>>> Could you try to define your variable in the
>>> custom.properties ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>>>
>>> Hi,
>>>
>>> I'm using Karaf 2.2.3. We're using Karaf+Camel as
>>> the basis for an
>>> integration platform. We use config admin
>>> extensively in order
>>> to define
>>> camel routes. As a convenience we define variables (in
>>> system.properties) that can be used in the different
>>> configurations. E g
>>> defining a "dataRoot" variable that the specifies a
>>> root
>>> directory in
>>> the file system that routes can relate to.
>>>
>>> If I, in system.properties specify the following:
>>>
>>> dataRoot = D:/data
>>> customer1Root = ${dataRoot}/customer1
>>>
>>> Then the value of "customer1Root" will be
>>> "/customer1". The
>>> "${dataRoot}" evaluates to an empty string. Why is that? If I
>>> instead
>>> define "dataRoot" as a real system property (using
>>> the -D option
>>> to the
>>> JVM) then it works.
>>>
>>> In my configuration files (parsed by fileinstall) it
>>> works to
>>> use the
>>> ${...} notation to refer to variables in
>>> system.properties. What
>>> then
>>> does not seem to work is if I in system.properties
>>> try to refer to
>>> another variable defined in system.properties.
>>>
>>> This seems like a bug to me.
>>>
>>> I would also like to find out what the status is on
>>> the redesign of
>>> system.properties. I would very much like the
>>> possibility to add my
>>> specific variables outside of the Karaf
>>> installation. I already
>>> create a
>>> custom distribution but the variables need to be
>>> added on a per
>>> installation basis. The customer himself decides
>>> what convenience
>>> variables are needed and I don't want the customer
>>> to fiddle
>>> with the
>>> Karaf installation.
>>>
>>> The functionality I'm looking for is something like
>>> this:
>>> Somewhere in
>>> the Karaf configuration I would like to specify that
>>> Karaf
>>> should read
>>> variable definitions from a file (or list of files)
>>> that I
>>> specify. I
>>> can then separate my, installation specific,
>>> variables from the
>>> standard
>>> Karaf installation. I have brought this up before
>>> and was under the
>>> impression that something like this was in scope for
>>> Karaf 3 (or
>>> even
>>> earlier). What is the status of this kind of
>>> customisation?
>>>
>>> /Bengt
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org <mailto:jbono...@apache.org>
>>> <mailto:jbono...@apache.org <mailto:jbono...@apache.org>>
>>>
>>>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org <mailto:jbono...@apache.org>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
