Re: Problems with system.properties
JB, Just wanted to check if you did get the time to look into this. /Bengt 2011/11/22 Bengt Rodehav be...@rodehav.com 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/
Re: Problems with system.properties
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?
Re: Problems with system.properties
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
Re: Problems with system.properties
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
Re: Problems with system.properties
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 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 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 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
Re: Problems with system.properties
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 http://blog.nanthrax.net Talend - http://www.talend.com
Re: Problems with system.properties
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 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 http://blog.nanthrax.net Talend - http://www.talend.com
Re: Problems with system.properties
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 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 http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com