Do you think my two wishes could be included in Karaf 2.2.5? That would be
terrific.
/Bengt
Den 22 nov 2011 10:16 skrev "Jean-Baptiste Onofré" <j...@nanthrax.net>:
>
> Hi Bengt,
>
> sorry, I was busy on another project yesterday. I will check it this
afternoon.
>
> Regards
> JB
>
>
> On 11/22/2011 10:04 AM, Bengt Rodehav wrote:
>>
>> 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 <mailto: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
>> <mailto: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> <mailto: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>
>> <mailto: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>>
>> <mailto: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>>
>> <mailto: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>
>> <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
