Problems with system.properties

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Problems with system.properties

Bengt Rodehav
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
Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

jbonofre
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

Bengt Rodehav
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é <[hidden email]>
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é
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

jbonofre
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é <[hidden email] <mailto:[hidden email]>>
>
>     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é
>     [hidden email] <mailto:[hidden email]>
>     http://blog.nanthrax.net
>     Talend - http://www.talend.com
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

Bengt Rodehav
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é <[hidden email]>
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é <[hidden email] <mailto:[hidden email]>>


   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é
   [hidden email] <mailto:[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

Bengt Rodehav
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 <[hidden email]>
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é <[hidden email]>
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é <[hidden email] <mailto:[hidden email]>>


   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é
   [hidden email] <mailto:[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

jbonofre
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 <[hidden email] <mailto:[hidden email]>>
>
>     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é <[hidden email]
>     <mailto:[hidden email]>>
>
>         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é <[hidden email]
>             <mailto:[hidden email]> <mailto:[hidden email]
>             <mailto:[hidden email]>>>
>
>
>                 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é
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>
>             http://blog.nanthrax.net
>                 Talend - http://www.talend.com
>
>
>
>         --
>         Jean-Baptiste Onofré
>         [hidden email] <mailto:[hidden email]>
>         http://blog.nanthrax.net
>         Talend - http://www.talend.com
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

Bengt Rodehav
Thanks for your answers JB. I created the following JIRA:


/Bengt

2011/11/15 Jean-Baptiste Onofré <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>


   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é <[hidden email]
   <mailto:[hidden email]>>


       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é <[hidden email]
           <mailto:[hidden email]> <mailto:[hidden email]

           <mailto:[hidden email]>>>


               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é
           [hidden email] <mailto:[hidden email]>
           <mailto:[hidden email] <mailto:[hidden email]>>


           http://blog.nanthrax.net
               Talend - http://www.talend.com



       --
       Jean-Baptiste Onofré
       [hidden email] <mailto:[hidden email]>
       http://blog.nanthrax.net
       Talend - http://www.talend.com




Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

Bengt Rodehav
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 <[hidden email]>
Thanks for your answers JB. I created the following JIRA:


/Bengt


2011/11/15 Jean-Baptiste Onofré <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>


   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é <[hidden email]
   <mailto:[hidden email]>>


       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é <[hidden email]
           <mailto:[hidden email]> <mailto:[hidden email]

           <mailto:[hidden email]>>>


               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é
           [hidden email] <mailto:[hidden email]>
           <mailto:[hidden email] <mailto:[hidden email]>>


           http://blog.nanthrax.net
               Talend - http://www.talend.com



       --
       Jean-Baptiste Onofré
       [hidden email] <mailto:[hidden email]>
       http://blog.nanthrax.net
       Talend - http://www.talend.com





Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

jbonofre
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 <[hidden email] <mailto:[hidden email]>>
>
>     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é <[hidden email]
>     <mailto:[hidden email]>>
>
>         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 <[hidden email]
>             <mailto:[hidden email]> <mailto:[hidden email]
>             <mailto:[hidden email]>>>
>
>
>                 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é <[hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>>
>
>
>                     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é <[hidden email]
>             <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>             <mailto:[hidden email] <mailto:[hidden email]>
>
>             <mailto:[hidden email] <mailto:[hidden email]>>>>
>
>
>                             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é
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>             <mailto:[hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>>
>
>
>             http://blog.nanthrax.net
>                             Talend - http://www.talend.com
>
>
>
>                     --
>                     Jean-Baptiste Onofré
>             [hidden email] <mailto:[hidden email]>
>             <mailto:[hidden email] <mailto:[hidden email]>>
>             http://blog.nanthrax.net
>                     Talend - http://www.talend.com
>
>
>
>
>         --
>         Jean-Baptiste Onofré
>         [hidden email] <mailto:[hidden email]>
>         http://blog.nanthrax.net
>         Talend - http://www.talend.com
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Problems with system.properties

Bengt Rodehav

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é" <[hidden email]>:
>
> 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 <[hidden email] <mailto:[hidden email]>>
>>
>>
>>    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é <[hidden email]
>>    <mailto:[hidden email]>>
>>
>>
>>        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 <[hidden email]
>>            <mailto:[hidden email]> <mailto:[hidden email]
>>
>>            <mailto:[hidden email]>>>
>>
>>
>>                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é <[hidden email]
>>            <mailto:[hidden email]>
>>            <mailto:[hidden email] <mailto:[hidden email]>>>
>>
>>
>>                    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é <[hidden email]
>>            <mailto:[hidden email]>
>>            <mailto:[hidden email] <mailto:[hidden email]>>
>>            <mailto:[hidden email] <mailto:[hidden email]>
>>
>>            <mailto:[hidden email] <mailto:[hidden email]>>>>
>>
>>
>>
>>                            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é
>>            [hidden email] <mailto:[hidden email]>
>>            <mailto:[hidden email] <mailto:[hidden email]>>
>>            <mailto:[hidden email] <mailto:[hidden email]>
>>            <mailto:[hidden email] <mailto:[hidden email]>>>
>>
>>
>>            http://blog.nanthrax.net
>>                            Talend - http://www.talend.com
>>
>>
>>
>>                    --
>>                    Jean-Baptiste Onofré
>>            [hidden email] <mailto:[hidden email]>
>>            <mailto:[hidden email] <mailto:[hidden email]>>
>>            http://blog.nanthrax.net
>>                    Talend - http://www.talend.com
>>
>>
>>
>>
>>        --
>>        Jean-Baptiste Onofré
>>        [hidden email] <mailto:[hidden email]>
>>        http://blog.nanthrax.net
>>        Talend - http://www.talend.com
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Reply | Threaded
Open this post in threaded view
|

Package uses conflict: Import-Package: org.osgi.service.blueprint

XiLai Dai
In reply to this post by jbonofre
Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin.
The META-INF/ MANIFEST.MF contains:
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error:
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict?

Thanks.
Xilai
Reply | Threaded
Open this post in threaded view
|

Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

Freeman-2
Hi,

This kind of "Package uses conflict" comes from the scenario like, let's say, 
bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z
bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 
Let's say bundle B already get resolved and started.
When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.

The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.

Freeman
On 2011-11-23, at 上午11:36, XiLai Dai wrote:

Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin.
The META-INF/ MANIFEST.MF contains:
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error:
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict?

Thanks.
Xilai

---------------------------------------------
Freeman Fang

FuseSource
Twitter: freemanfang









Reply | Threaded
Open this post in threaded view
|

RE: Package uses conflict: Import-Package: org.osgi.service.blueprint

XiLai Dai

Thanks Freeman for your clear reply!

 

BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.

So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.

 

Thanks.

Xilai

From: Freeman Fang [mailto:[hidden email]]
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

This kind of "Package uses conflict" comes from the scenario like, let's say, 

bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z

bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 

Let's say bundle B already get resolved and started.

When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.

 

The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.

 

Freeman

On 2011-11-23, at 上午11:36, XiLai Dai wrote:



Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin.
The META-INF/ MANIFEST.MF contains:
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error:
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict?

Thanks.
Xilai

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

Freeman-2
Hi,

maven-bundle-plugin basically just analyze the dependency in pom.xml and generate OSGi meta-data header in MANIFEST.MF accordingly, you need check if your dependency introduce this package import.
Btw, you can configure the maven-bundle-plugin to totally control the OSGi meta-data header.

Freeman

On 2011-11-23, at 下午1:27, XiLai Dai wrote:

Thanks Freeman for your clear reply!
 
BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.
So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.
 
Thanks.
Xilai
From: Freeman Fang [[hidden email]] 
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
 
Hi,
 
This kind of "Package uses conflict" comes from the scenario like, let's say, 
bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z
bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 
Let's say bundle B already get resolved and started.
When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.
 
The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.
 
Freeman
On 2011-11-23, at 上午11:36, XiLai Dai wrote:


Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin. 
The META-INF/ MANIFEST.MF contains: 
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error: 
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict? 

Thanks.
Xilai
 
---------------------------------------------
Freeman Fang
 
FuseSource
Twitter: freemanfang
 
 
 
 
 
 
 
 
 

---------------------------------------------
Freeman Fang

FuseSource
Twitter: freemanfang









Reply | Threaded
Open this post in threaded view
|

Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

Willem
yes, the maven-bundle-plugin will read the MANIFEST.MF of the third party bundle, if it exports the package with some kind version number like 1.2.1.  maven-bundle-plugin will generated the import package with the version rang of [1.2, 2).
You can override it by specify the import package version rang in the maven-bundle-plugin.

Willem

On Wed, Nov 23, 2011 at 1:36 PM, Freeman Fang <[hidden email]> wrote:
Hi,

maven-bundle-plugin basically just analyze the dependency in pom.xml and generate OSGi meta-data header in MANIFEST.MF accordingly, you need check if your dependency introduce this package import.
Btw, you can configure the maven-bundle-plugin to totally control the OSGi meta-data header.

Freeman

On 2011-11-23, at 下午1:27, XiLai Dai wrote:

Thanks Freeman for your clear reply!
 
BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.
So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.
 
Thanks.
Xilai
From: Freeman Fang [[hidden email]] 
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
 
Hi,
 
This kind of "Package uses conflict" comes from the scenario like, let's say, 
bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z
bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 
Let's say bundle B already get resolved and started.
When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.
 
The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.
 
Freeman
On 2011-11-23, at 上午11:36, XiLai Dai wrote:


Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin. 
The META-INF/ MANIFEST.MF contains: 
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error: 
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict? 

Thanks.
Xilai
 
---------------------------------------------
Freeman Fang
 
FuseSource
Twitter: freemanfang
 
 
 
 
 
 
 
 
 

---------------------------------------------
Freeman Fang

FuseSource
Twitter: freemanfang










Reply | Threaded
Open this post in threaded view
|

RE: Package uses conflict: Import-Package: org.osgi.service.blueprint

XiLai Dai
In reply to this post by Freeman-2

Hello,

There is no any osgi dependencies in the pom.xml file!  If OSGI-INF/blueprint/*.xml included into bundle, the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” will be generated; if remove OSGI-INF/blueprint/*.xml, then “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” was gone.

 

How to control this meta info?

I’ve tried adding this into the pom.xml

<!--Import-Package>

!org.osgi.service.blueprint

          </Import-Package-->

But not works.

 

Thanks.

Xilai

From: Freeman Fang [mailto:[hidden email]]
Sent: Wednesday, November 23, 2011 1:37 PM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

maven-bundle-plugin basically just analyze the dependency in pom.xml and generate OSGi meta-data header in MANIFEST.MF accordingly, you need check if your dependency introduce this package import.

Btw, you can configure the maven-bundle-plugin to totally control the OSGi meta-data header.

 

Freeman

 

On 2011-11-23, at 下午1:27, XiLai Dai wrote:



Thanks Freeman for your clear reply!

 

BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.

So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.

 

Thanks.

Xilai

From: Freeman Fang [[hidden email]] 
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

This kind of "Package uses conflict" comes from the scenario like, let's say, 

bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z

bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 

Let's say bundle B already get resolved and started.

When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.

 

The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.

 

Freeman

On 2011-11-23, at 上午11:36, XiLai Dai wrote:




Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin. 
The META-INF/ MANIFEST.MF contains: 
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error: 
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict? 

Thanks.
Xilai

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

David Jencks
<base href="x-msg://490/">This import-package is reguired by the blueprint spec so that only one blueprint implementation can process the blueprint plan.  The only way I can imagine to get this uses conflict is if you have two blueprint implementations running in karaf.  Do you?  Do you need both?

thanks
david jencks

On Nov 22, 2011, at 10:36 PM, XiLai Dai wrote:

Hello,
There is no any osgi dependencies in the pom.xml file!  If OSGI-INF/blueprint/*.xml included into bundle, the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” will be generated; if remove OSGI-INF/blueprint/*.xml, then “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” was gone.
 
How to control this meta info?
I’ve tried adding this into the pom.xml
<!--Import-Package>
!org.osgi.service.blueprint
          </Import-Package-->
But not works.
 
Thanks.
Xilai
From: Freeman Fang [mailto:[hidden email]] 
Sent: Wednesday, November 23, 2011 1:37 PM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
 
Hi,
 
maven-bundle-plugin basically just analyze the dependency in pom.xml and generate OSGi meta-data header in MANIFEST.MF accordingly, you need check if your dependency introduce this package import.
Btw, you can configure the maven-bundle-plugin to totally control the OSGi meta-data header.
 
Freeman
 
On 2011-11-23, at 下午1:27, XiLai Dai wrote:


Thanks Freeman for your clear reply!
 
BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.
So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.
 
Thanks.
Xilai
From: Freeman Fang [[hidden email]] 
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
 
Hi,
 
This kind of "Package uses conflict" comes from the scenario like, let's say, 
bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z
bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 
Let's say bundle B already get resolved and started.
When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.
 
The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.
 
Freeman
On 2011-11-23, at 上午11:36, XiLai Dai wrote:



Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin. 
The META-INF/ MANIFEST.MF contains: 
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error: 
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict? 

Thanks.
Xilai
 
---------------------------------------------
Freeman Fang
 
FuseSource
Twitter: freemanfang
 
 
 
 
 
 
 
 
 
 
---------------------------------------------
Freeman Fang
 
FuseSource
Twitter: freemanfang
 
 
 
 
 
 
 
 
 

Reply | Threaded
Open this post in threaded view
|

Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

Freeman-2
In reply to this post by XiLai Dai
Hi,
I've run a quick test on a blueprint bundle.
The configuration like
         <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <configuration>
                    <instructions>
                        ...
                           <Import-Package>!org.osgi.service.blueprint</Import-Package>
                     </instructions>
                </configuration>
            </plugin>
works for me.

Notice in your configuration you just comment out the Import-Package, so that configuration won't take effect.

However, I don't think you should change this OSGi header of this bundle, as it's correct behavior to generate org.osgi.service.blueprint;version="[1.0.0,2.0.0)" header when it's a blueprint bundle. As I mentioned previously you need figure out other bundles which wrongly export/import other version of org.osgi.service.blueprint.
From karaf console
packages:imports |grep org.osgi.service.blueprint
or
packages:exports |grep org.osgi.service.blueprint
may give you more hints. I guess most likely you install other blueprint implementation other than the aries one.

Freeman

On Wed, Nov 23, 2011 at 2:36 PM, XiLai Dai <[hidden email]> wrote:

Hello,

There is no any osgi dependencies in the pom.xml file!  If OSGI-INF/blueprint/*.xml included into bundle, the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” will be generated; if remove OSGI-INF/blueprint/*.xml, then “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” was gone.

 

How to control this meta info?

I’ve tried adding this into the pom.xml

<!--Import-Package>

!org.osgi.service.blueprint

          </Import-Package-->

But not works.

 

Thanks.

Xilai

From: Freeman Fang [mailto:[hidden email]]
Sent: Wednesday, November 23, 2011 1:37 PM


To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

maven-bundle-plugin basically just analyze the dependency in pom.xml and generate OSGi meta-data header in MANIFEST.MF accordingly, you need check if your dependency introduce this package import.

Btw, you can configure the maven-bundle-plugin to totally control the OSGi meta-data header.

 

Freeman

 

On 2011-11-23, at 下午1:27, XiLai Dai wrote:



Thanks Freeman for your clear reply!

 

BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.

So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.

 

Thanks.

Xilai

From: Freeman Fang [[hidden email]] 
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

This kind of "Package uses conflict" comes from the scenario like, let's say, 

bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z

bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 

Let's say bundle B already get resolved and started.

When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.

 

The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.

 

Freeman

On 2011-11-23, at 上午11:36, XiLai Dai wrote:




Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin. 
The META-INF/ MANIFEST.MF contains: 
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error: 
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict? 

Thanks.
Xilai

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 


Reply | Threaded
Open this post in threaded view
|

RE: Package uses conflict: Import-Package: org.osgi.service.blueprint

XiLai Dai

Thanks much!

But unfortunately, seems there is only Aries implementation for blueprint in my Karaf container  L

-----------------------------------------------

karaf@trun> packages:imports | grep org.osgi.service.blueprint

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.reflect; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.reflect; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.reflect; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.reflect; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.reflect; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.container; version="1.0.1"

Apache Aries Blueprint Bundle (9): org.osgi.service.blueprint.reflect; version="1.0.1"

karaf@trun> packages:exports |grep org.osgi.service.blueprint

     9 org.osgi.service.blueprint; version="1.0.1"

     9 org.osgi.service.blueprint.container; version="1.0.1"

     9 org.osgi.service.blueprint.reflect; version="1.0.1"

----------------------------------------------------

 

Thanks.

Xilai

From: Freeman Fang [mailto:[hidden email]]
Sent: Wednesday, November 23, 2011 3:27 PM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,
I've run a quick test on a blueprint bundle.
The configuration like
         <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <configuration>
                    <instructions>
                        ...
                           <Import-Package>!org.osgi.service.blueprint</Import-Package>
                     </instructions>
                </configuration>
            </plugin>
works for me.

Notice in your configuration you just comment out the Import-Package, so that configuration won't take effect.

However, I don't think you should change this OSGi header of this bundle, as it's correct behavior to generate org.osgi.service.blueprint;version="[1.0.0,2.0.0)" header when it's a blueprint bundle. As I mentioned previously you need figure out other bundles which wrongly export/import other version of org.osgi.service.blueprint.
From karaf console
packages:imports |grep org.osgi.service.blueprint
or
packages:exports |grep org.osgi.service.blueprint
may give you more hints. I guess most likely you install other blueprint implementation other than the aries one.

Freeman

On Wed, Nov 23, 2011 at 2:36 PM, XiLai Dai <[hidden email]> wrote:

Hello,

There is no any osgi dependencies in the pom.xml file!  If OSGI-INF/blueprint/*.xml included into bundle, the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” will be generated; if remove OSGI-INF/blueprint/*.xml, then “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” was gone.

 

How to control this meta info?

I’ve tried adding this into the pom.xml

<!--Import-Package>

!org.osgi.service.blueprint

          </Import-Package-->

But not works.

 

Thanks.

Xilai

From: Freeman Fang [mailto:[hidden email]]
Sent: Wednesday, November 23, 2011 1:37 PM


To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

maven-bundle-plugin basically just analyze the dependency in pom.xml and generate OSGi meta-data header in MANIFEST.MF accordingly, you need check if your dependency introduce this package import.

Btw, you can configure the maven-bundle-plugin to totally control the OSGi meta-data header.

 

Freeman

 

On 2011-11-23, at 下午1:27, XiLai Dai wrote:

 

Thanks Freeman for your clear reply!

 

BTW, I’ve run another test with the same bundle which just removed the “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” from MANIFEST.MF, then, it has been installed into Karaf successfully.

So, maybe it’s a problem from maven-bundle-plugin, it should not generate the unexpected “org.osgi.service.blueprint;version="[1.0.0,2.0.0)” into MANIFEST.MF.

 

Thanks.

Xilai

From: Freeman Fang [[hidden email]
Sent: Wednesday, November 23, 2011 11:52 AM
To: [hidden email]
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint

 

Hi,

 

This kind of "Package uses conflict" comes from the scenario like, let's say, 

bundle A import-package org.osgi.service.blueprint; version="[1.0.0,2.0.0)", bundle A also import-package x.y.z

bunde B export-package  x.y.z with "use" directive like uses:="org.osgi.service.blueprint; version="[2.0.0,3.0.0)"" 

Let's say bundle B already get resolved and started.

When resolve bundle A, it will use export-package x.y.z from bundle B, but  as bundle B export-package  x.y.z uses:="oorg.osgi.service.blueprint; version="[2.0.0,3.0.0)" and bundle B get resolved to import org.osgi.service.blueprint; version="[2.0.0,3.0.0), so it's not meet bundle A's restriction which need org.osgi.service.blueprint; version="[1.0.0,2.0.0)(notice the version mismatch between the two), then you see such exception.

 

The root cause is that you install some bundles which need different org.osgi.service.blueprint versions, also those bundles has dependency with each other, you need figure it out from your bundles and fix it.

 

Freeman

On 2011-11-23, at 上午11:36, XiLai Dai wrote:



Hello,

We have a bundle with blueprint (OSGI-INF/blueprint/xxx.xml) and build with maven-bundle-plugin. 
The META-INF/ MANIFEST.MF contains: 
......
Import-Package: ...,org.osgi.service.blueprint;version="[1.0.0,2.0.0)",...

When install this bundle into Karaf 2.2.4, got error: 
Reason: Package uses conflict: Im port-Package: org.osgi.service.blueprint; version="[1.0.0,2.0.0)"

Why it complains there has conflict? 

Thanks.
Xilai

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 

 

---------------------------------------------

Freeman Fang

 

FuseSource

Twitter: freemanfang

 

 

 

 

 

 

 

 

 

 

12