JB,
Did try out your suggestion and I got it to work but I have a question (and
perhaps a request for change). This is what I did:
I modified config.properties and changed the ${includes} property as
follows:
*${includes} = jre.properties custom.properties ${confdir}/custom.properties
*
"confdir" is a system property that I set using the "-D" option to the JVM.
It points out a directory outside the Karaf installation where we keep our
application's specific configuration. By keeping it outside of the Karaf
installation we can easily upgrade Karaf without having to recreate all the
application specific configuration. We use an environment variable to point
out this directory and we then set a system property that can be used to
find this location. However, ${confdir} is not evaluated by Karaf. I get an
error mesage saying:
*java.io.FileNotFoundException:
C:\dev\Karaf\stsweb\apache-karaf-2.2.3\etc\${confdir}\custom.properties
(The system cannot find the path specified)*
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?
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?
Out of curiosity I also wonder why the property is called "${includes}" and
not just "includes". I assume some "cleverness" is gong on here...
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.
/Bengt
2011/11/11 Bengt Rodehav <[email protected]>
> 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é <[email protected]>
>
>> 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é <[email protected] <mailto:[email protected]
>>> >>
>>>
>>>
>>> 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é
>>> [email protected] <mailto:[email protected]>
>>>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> [email protected]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
