You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Bengt Rodehav <be...@rodehav.com> on 2011/11/11 15:51:15 UTC
Problems with system.properties
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
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by Willem Jiang <wi...@gmail.com>.
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 <fr...@gmail.com>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 [mailto:freeman.fang@gmail.com<fr...@gmail.com>
> ]
> *Sent:* Wednesday, November 23, 2011 11:52 AM
> *To:* user@karaf.apache.org
> *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****
> Email:f <de...@fusesource.com>fang@fusesource.com****
> Web: fusesource.com****
> Twitter: freemanfang****
> Blog: http://freemanfang.blogspot.com****
> ** **
> ** **
> ** **
> ** **
> ** **
> ** **
> ** **
> ** **
> ** **
>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:f <de...@fusesource.com>fang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by David Jencks <da...@yahoo.com>.
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:freeman.fang@gmail.com]
> Sent: Wednesday, November 23, 2011 1:37 PM
> To: user@karaf.apache.org
> 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 [mailto:freeman.fang@gmail.com]
> Sent: Wednesday, November 23, 2011 11:52 AM
> To: user@karaf.apache.org
> 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
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------
> Freeman Fang
>
> FuseSource
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
RE: Package uses conflict: Import-Package:
org.osgi.service.blueprint
Posted by XiLai Dai <xl...@talend.com>.
Oops! My fault about this exception!
But for the error of “Package uses conflict: Import-Package: org.osgi.service.blueprint”, I’m not sure if it still happens because now I’m using a clean Karaf 2.2.4 container for testing this sample. In the former case, we used the Karaf 2.2.4 container with many installed bundles (Spring, CXF, Servicemix, … ), I can’t attach the whole container in the mail ☺
Thanks.
Xilai
From: Freeman Fang [mailto:freeman.fang@gmail.com]
Sent: Thursday, November 24, 2011 12:12 PM
To: user@karaf.apache.org
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Hi,
So no error like Package uses conflict: Import-Package: org.osgi.service.blueprint at all now, right?
The exception like
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to find a matching constructor on class test.blueprint.UIAPIServlet for arguments [] when instanciating bean #recipe-1
indicate that the IOC container(blueprint in this case) can't initialize your class test.blueprint.UIAPIServlet, this is comes from that your UIAPIServlet has protected constructor,
change it to public like
public UIAPIServlet() {
}
then it works.
Freeman
On Thu, Nov 24, 2011 at 11:13 AM, XiLai Dai <xl...@talend.com>> wrote:
Hi, Freeman,
Please find the attachment which is a simple bundle with blueprint.
1. Deploy geronimo-servlet_2.5_spec-1.1.2.jar into $Karaf2.2.4/deploy
2. Deploy test-blueprint-0.1.jar into $Karaf2.2.4/deploy
The source project also attached.
ID State Blueprint Level Name
[ 50] [Active ] [ ] [ 60] geronimo-servlet_2.5_spec (1.1.2)
[ 52] [Active ] [Failure ] [ 60] test :: blueprint (0.1.0)
The blueprint still failure, and now got this exception in the karaf.log:
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to find a matching constructor on class test.blueprint.UIAPIServlet for arguments [] when instanciating bean #recipe-1
at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:272)[9:org.apache.aries.blueprint:0.3.1]
Thanks.
Xilai
From: Freeman Fang [mailto:freeman.fang@gmail.com<ma...@gmail.com>]
Sent: Wednesday, November 23, 2011 6:30 PM
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Hi,
Is it possible that you append a src project which we can build and deploy to reproduce it?
Freeman
On Wed, Nov 23, 2011 at 3:53 PM, XiLai Dai <xl...@talend.com>> wrote:
Thanks much!
But unfortunately, seems there is only Aries implementation for blueprint in my Karaf container ☹
-----------------------------------------------
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:freeman.fang@gmail.com<ma...@gmail.com>]
Sent: Wednesday, November 23, 2011 3:27 PM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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 <xl...@talend.com>> 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:freeman.fang@gmail.com<ma...@gmail.com>]
Sent: Wednesday, November 23, 2011 1:37 PM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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 [mailto:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 11:52 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
---------------------------------------------
Freeman Fang
FuseSource
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
So no error like Package uses conflict: Import-Package:
org.osgi.service.blueprint at all now, right?
The exception like
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
to find a matching constructor on class test.blueprint.UIAPIServlet for
arguments [] when instanciating bean #recipe-1
indicate that the IOC container(blueprint in this case) can't initialize
your class test.blueprint.UIAPIServlet, this is comes from that your
UIAPIServlet has protected constructor,
change it to public like
public UIAPIServlet() {
}
then it works.
Freeman
On Thu, Nov 24, 2011 at 11:13 AM, XiLai Dai <xl...@talend.com> wrote:
> Hi, Freeman,****
>
> ** **
>
> Please find the attachment which is a simple bundle with blueprint.****
>
> **1. **Deploy geronimo-servlet_2.5_spec-1.1.2.jar into
> $Karaf2.2.4/deploy****
>
> **2. **Deploy test-blueprint-0.1.jar into $Karaf2.2.4/deploy****
>
> ** **
>
> The source project also attached.****
>
> ** **
>
> ID State Blueprint Level Name****
>
> [ 50] [Active ] [ ] [ 60] geronimo-servlet_2.5_spec
> (1.1.2)****
>
> [ 52] [Active ] [Failure ] [ 60] test :: blueprint (0.1.0)****
>
> ** **
>
> The blueprint still failure, and now got this exception in the karaf.log:*
> ***
>
> ** **
>
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
> to find a matching constructor on class test.blueprint.UIAPIServlet for
> arguments [] when instanciating bean #recipe-1****
>
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:272)[9:org.apache.aries.blueprint:0.3.1]
> ****
>
> ** **
>
> Thanks.****
>
> Xilai****
>
> *From:* Freeman Fang [mailto:freeman.fang@gmail.com]
> *Sent:* Wednesday, November 23, 2011 6:30 PM
>
> *To:* user@karaf.apache.org
> *Subject:* Re: Package uses conflict: Import-Package:
> org.osgi.service.blueprint****
>
> ** **
>
> Hi,
>
> Is it possible that you append a src project which we can build and deploy
> to reproduce it?
>
> Freeman****
>
> On Wed, Nov 23, 2011 at 3:53 PM, XiLai Dai <xl...@talend.com> wrote:****
>
> 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:freeman.fang@gmail.com]
> *Sent:* Wednesday, November 23, 2011 3:27 PM****
>
>
> *To:* user@karaf.apache.org
> *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 <xl...@talend.com> 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:freeman.fang@gmail.com]
> *Sent:* Wednesday, November 23, 2011 1:37 PM****
>
>
> *To:* user@karaf.apache.org
> *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 [mailto:freeman.fang@gmail.com<fr...@gmail.com>
> ]
> *Sent:* Wednesday, November 23, 2011 11:52 AM
> *To:* user@karaf.apache.org
> *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****
>
> Email:f <de...@fusesource.com>fang@fusesource.com****
>
> Web: fusesource.com****
>
> Twitter: freemanfang****
>
> Blog: http://freemanfang.blogspot.com****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ---------------------------------------------****
>
> Freeman Fang****
>
> ****
>
> FuseSource****
>
> Email:f <de...@fusesource.com>fang@fusesource.com****
>
> Web: fusesource.com****
>
> Twitter: freemanfang****
>
> Blog: http://freemanfang.blogspot.com****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ** **
>
RE: Package uses conflict: Import-Package:
org.osgi.service.blueprint
Posted by XiLai Dai <xl...@talend.com>.
Hi, Freeman,
Please find the attachment which is a simple bundle with blueprint.
1. Deploy geronimo-servlet_2.5_spec-1.1.2.jar into $Karaf2.2.4/deploy
2. Deploy test-blueprint-0.1.jar into $Karaf2.2.4/deploy
The source project also attached.
ID State Blueprint Level Name
[ 50] [Active ] [ ] [ 60] geronimo-servlet_2.5_spec (1.1.2)
[ 52] [Active ] [Failure ] [ 60] test :: blueprint (0.1.0)
The blueprint still failure, and now got this exception in the karaf.log:
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to find a matching constructor on class test.blueprint.UIAPIServlet for arguments [] when instanciating bean #recipe-1
at org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:272)[9:org.apache.aries.blueprint:0.3.1]
Thanks.
Xilai
From: Freeman Fang [mailto:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 6:30 PM
To: user@karaf.apache.org
Subject: Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Hi,
Is it possible that you append a src project which we can build and deploy to reproduce it?
Freeman
On Wed, Nov 23, 2011 at 3:53 PM, XiLai Dai <xl...@talend.com>> wrote:
Thanks much!
But unfortunately, seems there is only Aries implementation for blueprint in my Karaf container ☹
-----------------------------------------------
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:freeman.fang@gmail.com<ma...@gmail.com>]
Sent: Wednesday, November 23, 2011 3:27 PM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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 <xl...@talend.com>> 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:freeman.fang@gmail.com<ma...@gmail.com>]
Sent: Wednesday, November 23, 2011 1:37 PM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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 [mailto:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 11:52 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
---------------------------------------------
Freeman Fang
FuseSource
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
Is it possible that you append a src project which we can build and deploy
to reproduce it?
Freeman
On Wed, Nov 23, 2011 at 3:53 PM, XiLai Dai <xl...@talend.com> wrote:
> 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:freeman.fang@gmail.com]
> *Sent:* Wednesday, November 23, 2011 3:27 PM
>
> *To:* user@karaf.apache.org
> *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 <xl...@talend.com> 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:freeman.fang@gmail.com]
> *Sent:* Wednesday, November 23, 2011 1:37 PM****
>
>
> *To:* user@karaf.apache.org
> *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 [mailto:freeman.fang@gmail.com<fr...@gmail.com>
> ]
> *Sent:* Wednesday, November 23, 2011 11:52 AM
> *To:* user@karaf.apache.org
> *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****
>
> Email:f <de...@fusesource.com>fang@fusesource.com****
>
> Web: fusesource.com****
>
> Twitter: freemanfang****
>
> Blog: http://freemanfang.blogspot.com****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ---------------------------------------------****
>
> Freeman Fang****
>
> ****
>
> FuseSource****
>
> Email:f <de...@fusesource.com>fang@fusesource.com****
>
> Web: fusesource.com****
>
> Twitter: freemanfang****
>
> Blog: http://freemanfang.blogspot.com****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ** **
>
RE: Package uses conflict: Import-Package:
org.osgi.service.blueprint
Posted by XiLai Dai <xl...@talend.com>.
Thanks much!
But unfortunately, seems there is only Aries implementation for blueprint in my Karaf container ☹
-----------------------------------------------
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:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 3:27 PM
To: user@karaf.apache.org
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 <xl...@talend.com>> 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:freeman.fang@gmail.com<ma...@gmail.com>]
Sent: Wednesday, November 23, 2011 1:37 PM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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 [mailto:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 11:52 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
---------------------------------------------
Freeman Fang
FuseSource
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by Freeman Fang <fr...@gmail.com>.
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 <xl...@talend.com> 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:freeman.fang@gmail.com]
> *Sent:* Wednesday, November 23, 2011 1:37 PM
>
> *To:* user@karaf.apache.org
> *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 [mailto:freeman.fang@gmail.com<fr...@gmail.com>
> ]
> *Sent:* Wednesday, November 23, 2011 11:52 AM
> *To:* user@karaf.apache.org
> *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****
>
> Email:f <de...@fusesource.com>fang@fusesource.com****
>
> Web: fusesource.com****
>
> Twitter: freemanfang****
>
> Blog: http://freemanfang.blogspot.com****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ****
>
> ** **
>
> ---------------------------------------------****
>
> Freeman Fang****
>
> ** **
>
> FuseSource****
>
> Email:f <de...@fusesource.com>fang@fusesource.com****
>
> Web: fusesource.com****
>
> Twitter: freemanfang****
>
> Blog: http://freemanfang.blogspot.com****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
RE: Package uses conflict: Import-Package:
org.osgi.service.blueprint
Posted by XiLai Dai <xl...@talend.com>.
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:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 1:37 PM
To: user@karaf.apache.org
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 [mailto:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 11:52 AM
To: user@karaf.apache.org<ma...@karaf.apache.org>
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
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
---------------------------------------------
Freeman Fang
FuseSource
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by Freeman Fang <fr...@gmail.com>.
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 [mailto:freeman.fang@gmail.com]
> Sent: Wednesday, November 23, 2011 11:52 AM
> To: user@karaf.apache.org
> 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
> Email:ffang@fusesource.com
> Web: fusesource.com
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
>
>
>
>
>
>
>
>
>
---------------------------------------------
Freeman Fang
FuseSource
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
RE: Package uses conflict: Import-Package:
org.osgi.service.blueprint
Posted by XiLai Dai <xl...@talend.com>.
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:freeman.fang@gmail.com]
Sent: Wednesday, November 23, 2011 11:52 AM
To: user@karaf.apache.org
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
Email:f<ma...@fusesource.com>
Web: fusesource.com<http://fusesource.com/>
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Re: Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by Freeman Fang <fr...@gmail.com>.
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
Email:ffang@fusesource.com
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
Package uses conflict: Import-Package: org.osgi.service.blueprint
Posted by XiLai Dai <xl...@talend.com>.
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
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
JB,
Just wanted to check if you did get the time to look into this.
/Bengt
2011/11/22 Bengt Rodehav <be...@rodehav.com>
> Do you think my two wishes could be included in Karaf 2.2.5? That would be
> terrific.
>
> /Bengt
>
> Den 22 nov 2011 10:16 skrev "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
>
> >
> > Hi Bengt,
> >
> > sorry, I was busy on another project yesterday. I will check it this
> afternoon.
> >
> > Regards
> > JB
> >
> >
> > On 11/22/2011 10:04 AM, Bengt Rodehav wrote:
> >>
> >> Hello again JB,
> >>
> >> Did you check whether it is possible to use system properties in
> >> config.properties?
> >>
> >> I've been experimenting a bit more with our custom Karaf distribution
> >> and I think that the combination of:
> >>
> >> a) Being able to use system properties in config.properties
> >> b) Being able to specify optional includes in ${includes} (KARAF-1014)
> >>
> >> Would benefit us a lot. Most of the things that need to be installation
> >> specific can then be extracted into one or several property files that
> >> can optionally be overridden per installation. We can then have one
> >> custom distribution instead of several different ones.
> >>
> >> I'm a bit anxious to be able to use this possibility.
> >>
> >> /Bengt
> >>
> >> 2011/11/15 Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
> >>
> >>
> >> Thanks for your answers JB. I created the following JIRA:
> >>
> >> https://issues.apache.org/jira/browse/KARAF-1014
> >>
> >> /Bengt
> >>
> >>
> >> 2011/11/15 Jean-Baptiste Onofré <jb@nanthrax.net
> >> <ma...@nanthrax.net>>
> >>
> >>
> >> Hi Bengt,
> >>
> >> My comments inline:
> >>
> >>
> >> I guess it's some kind of catch 22 going on here. I would
> >> really like to
> >> be able to use system properties at this point. Can I create
> >> a JIRA for
> >> this?
> >>
> >>
> >> It should work already. Let me take a look, I will raise a Jira
> >> if the system variables are not used.
> >>
> >>
> >>
> >> I can get it to work by using a relative path to specify
> >> where my
> >> custom.properties file reside. However, it appears that the
> >> "current
> >> directory" is not "karaf.home" but the "etc" directory under
> >> the Karaf
> >> installation. Is this by design?
> >>
> >>
> >> Yes, it's the default behavior. But it could make sense to be
> >> able to put any absolute path here. Let me think about that.
> >>
> >>
> >>
> >> Out of curiosity I also wonder why the property is called
> >> "${includes}"
> >> and not just "includes". I assume some "cleverness" is gong
> >> on here...
> >>
> >>
> >> It's because it's used and populated by others scripts.
> >>
> >>
> >>
> >> Finally, I would like to have the possibility to not have to
> >> create my
> >> "custom" custom.properties. If I specify its location in the
> >> ${includes}
> >> property then Karaf fails to start if the file doesn't
> >> exist. I would
> >> like Karaf to pick up the file if it exists, otherwise, I
> >> would like
> >> Karaf to ignore it and just continue. That would allow us to
> >> provide
> >> custom variables if we wanted to but it wouldn't require each
> >> installation to have a custom.properties.
> >>
> >>
> >> It makes sense, Karaf should check if the file exists before
> >> trying to load it. Could you raise a Jira for that ?
> >>
> >> Thanks
> >> Regards
> >> JB
> >>
> >>
> >> /Bengt
> >>
> >>
> >>
> >> 2011/11/11 Bengt Rodehav <bengt@rodehav.com
> >> <ma...@rodehav.com> <mailto:bengt@rodehav.com
> >>
> >> <ma...@rodehav.com>>>
> >>
> >>
> >> Perfect!
> >>
> >> I didn't know about the ${includes}. Will try it out as
> >> soon as
> >> possible.
> >>
> >> Thanks a lot,
> >>
> >> /Bengt
> >>
> >> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
> >> <ma...@nanthrax.net>
> >> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>
> >>
> >>
> >> Hi Bengt,
> >>
> >> it's exactly the purpose of custom.properties.
> >>
> >> Basically:
> >> - system.properties is "reserved" for Karaf itself.
> >> - config.properties is "reserved" for "application"
> >> - custom.properties is "reserved" for your usage
> >>
> >> You can put the custom.properties where you want.
> >> You just need
> >> to update the ${includes} property in the
> >> etc/system.properties.
> >>
> >> Regards
> >> JB
> >>
> >>
> >> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
> >>
> >> Thanks for your reply JB,
> >>
> >> Yes, if I put the variables in custom.properties
> >> they can
> >> reference each
> >> other directly. Given these lines in
> >> custom.properties:
> >>
> >> /MyRootDir=C:/Temp/
> >> /MySubDir=${MyRootDir}/Sub/
> >>
> >>
> >> Gives the value "C:/Temp/Sub" for the variable
> >> "MySubDir".
> >>
> >> Thanks!
> >>
> >> I guess then that best practice is to use
> >> custom.properties
> >> for this?
> >> This is good since it doesn't (should not)
> >> contain any
> >> configuration
> >> out-of-the-box. I noticed that the
> >> karaf.systemBundlesStartLevel is
> >> defined there. I think that should be removed.
> >>
> >> Now if there was a way to specify that the
> >> custom.properties
> >> file should
> >> reside somewhere else then I would be very
> >> happy. The reason
> >> is that we
> >> do not want to put installation specific
> >> configuration in
> >> the Karaf
> >> installation. Do you have an update regarding
> this?
> >>
> >> /Bengt
> >>
> >>
> >> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
> >> <ma...@nanthrax.net>
> >> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>
> >> <mailto:jb@nanthrax.net <ma...@nanthrax.net>
> >>
> >> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>>
> >>
> >>
> >>
> >> Hi Bengt,
> >>
> >> the system.properties is not directly
> evaluate.
> >>
> >> Could you try to define your variable in the
> >> custom.properties ?
> >>
> >> Regards
> >> JB
> >>
> >>
> >> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
> >>
> >> Hi,
> >>
> >> I'm using Karaf 2.2.3. We're using
> >> Karaf+Camel as
> >> the basis for an
> >> integration platform. We use config admin
> >> extensively in order
> >> to define
> >> camel routes. As a convenience we define
> >> variables (in
> >> system.properties) that can be used in
> >> the different
> >> configurations. E g
> >> defining a "dataRoot" variable that the
> >> specifies a root
> >> directory in
> >> the file system that routes can relate
> to.
> >>
> >> If I, in system.properties specify the
> >> following:
> >>
> >> dataRoot = D:/data
> >> customer1Root = ${dataRoot}/customer1
> >>
> >> Then the value of "customer1Root" will be
> >> "/customer1". The
> >> "${dataRoot}" evaluates to an empty string. Why is that? If I
> >> instead
> >> define "dataRoot" as a real system
> >> property (using
> >> the -D option
> >> to the
> >> JVM) then it works.
> >>
> >> In my configuration files (parsed by
> >> fileinstall) it
> >> works to
> >> use the
> >> ${...} notation to refer to variables in
> >> system.properties. What
> >> then
> >> does not seem to work is if I in
> >> system.properties
> >> try to refer to
> >> another variable defined in
> >> system.properties.
> >>
> >> This seems like a bug to me.
> >>
> >> I would also like to find out what the
> >> status is on
> >> the redesign of
> >> system.properties. I would very much
> >> like the
> >> possibility to add my
> >> specific variables outside of the Karaf
> >> installation. I already
> >> create a
> >> custom distribution but the variables
> >> need to be
> >> added on a per
> >> installation basis. The customer himself
> >> decides
> >> what convenience
> >> variables are needed and I don't want
> >> the customer
> >> to fiddle
> >> with the
> >> Karaf installation.
> >>
> >> The functionality I'm looking for is
> >> something like
> >> this:
> >> Somewhere in
> >> the Karaf configuration I would like to
> >> specify that
> >> Karaf
> >> should read
> >> variable definitions from a file (or
> >> list of files)
> >> that I
> >> specify. I
> >> can then separate my, installation
> specific,
> >> variables from the
> >> standard
> >> Karaf installation. I have brought this
> >> up before
> >> and was under the
> >> impression that something like this was
> >> in scope for
> >> Karaf 3 (or
> >> even
> >> earlier). What is the status of this
> kind of
> >> customisation?
> >>
> >> /Bengt
> >>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org <ma...@apache.org>
> >> <mailto:jbonofre@apache.org <ma...@apache.org>>
> >> <mailto:jbonofre@apache.org <ma...@apache.org>
> >> <mailto:jbonofre@apache.org <ma...@apache.org>>>
> >>
> >>
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org <ma...@apache.org>
> >> <mailto:jbonofre@apache.org <ma...@apache.org>>
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >>
> >>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org <ma...@apache.org>
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >>
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
>
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
Do you think my two wishes could be included in Karaf 2.2.5? That would be
terrific.
/Bengt
Den 22 nov 2011 10:16 skrev "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
>
> Hi Bengt,
>
> sorry, I was busy on another project yesterday. I will check it this
afternoon.
>
> Regards
> JB
>
>
> On 11/22/2011 10:04 AM, Bengt Rodehav wrote:
>>
>> Hello again JB,
>>
>> Did you check whether it is possible to use system properties in
>> config.properties?
>>
>> I've been experimenting a bit more with our custom Karaf distribution
>> and I think that the combination of:
>>
>> a) Being able to use system properties in config.properties
>> b) Being able to specify optional includes in ${includes} (KARAF-1014)
>>
>> Would benefit us a lot. Most of the things that need to be installation
>> specific can then be extracted into one or several property files that
>> can optionally be overridden per installation. We can then have one
>> custom distribution instead of several different ones.
>>
>> I'm a bit anxious to be able to use this possibility.
>>
>> /Bengt
>>
>> 2011/11/15 Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
>>
>>
>> Thanks for your answers JB. I created the following JIRA:
>>
>> https://issues.apache.org/jira/browse/KARAF-1014
>>
>> /Bengt
>>
>>
>> 2011/11/15 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>
>>
>>
>> Hi Bengt,
>>
>> My comments inline:
>>
>>
>> I guess it's some kind of catch 22 going on here. I would
>> really like to
>> be able to use system properties at this point. Can I create
>> a JIRA for
>> this?
>>
>>
>> It should work already. Let me take a look, I will raise a Jira
>> if the system variables are not used.
>>
>>
>>
>> I can get it to work by using a relative path to specify
>> where my
>> custom.properties file reside. However, it appears that the
>> "current
>> directory" is not "karaf.home" but the "etc" directory under
>> the Karaf
>> installation. Is this by design?
>>
>>
>> Yes, it's the default behavior. But it could make sense to be
>> able to put any absolute path here. Let me think about that.
>>
>>
>>
>> Out of curiosity I also wonder why the property is called
>> "${includes}"
>> and not just "includes". I assume some "cleverness" is gong
>> on here...
>>
>>
>> It's because it's used and populated by others scripts.
>>
>>
>>
>> Finally, I would like to have the possibility to not have to
>> create my
>> "custom" custom.properties. If I specify its location in the
>> ${includes}
>> property then Karaf fails to start if the file doesn't
>> exist. I would
>> like Karaf to pick up the file if it exists, otherwise, I
>> would like
>> Karaf to ignore it and just continue. That would allow us to
>> provide
>> custom variables if we wanted to but it wouldn't require each
>> installation to have a custom.properties.
>>
>>
>> It makes sense, Karaf should check if the file exists before
>> trying to load it. Could you raise a Jira for that ?
>>
>> Thanks
>> Regards
>> JB
>>
>>
>> /Bengt
>>
>>
>>
>> 2011/11/11 Bengt Rodehav <bengt@rodehav.com
>> <ma...@rodehav.com> <mailto:bengt@rodehav.com
>>
>> <ma...@rodehav.com>>>
>>
>>
>> Perfect!
>>
>> I didn't know about the ${includes}. Will try it out as
>> soon as
>> possible.
>>
>> Thanks a lot,
>>
>> /Bengt
>>
>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>
>>
>>
>> Hi Bengt,
>>
>> it's exactly the purpose of custom.properties.
>>
>> Basically:
>> - system.properties is "reserved" for Karaf itself.
>> - config.properties is "reserved" for "application"
>> - custom.properties is "reserved" for your usage
>>
>> You can put the custom.properties where you want.
>> You just need
>> to update the ${includes} property in the
>> etc/system.properties.
>>
>> Regards
>> JB
>>
>>
>> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>>
>> Thanks for your reply JB,
>>
>> Yes, if I put the variables in custom.properties
>> they can
>> reference each
>> other directly. Given these lines in
>> custom.properties:
>>
>> /MyRootDir=C:/Temp/
>> /MySubDir=${MyRootDir}/Sub/
>>
>>
>> Gives the value "C:/Temp/Sub" for the variable
>> "MySubDir".
>>
>> Thanks!
>>
>> I guess then that best practice is to use
>> custom.properties
>> for this?
>> This is good since it doesn't (should not)
>> contain any
>> configuration
>> out-of-the-box. I noticed that the
>> karaf.systemBundlesStartLevel is
>> defined there. I think that should be removed.
>>
>> Now if there was a way to specify that the
>> custom.properties
>> file should
>> reside somewhere else then I would be very
>> happy. The reason
>> is that we
>> do not want to put installation specific
>> configuration in
>> the Karaf
>> installation. Do you have an update regarding
this?
>>
>> /Bengt
>>
>>
>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>
>>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>>
>>
>>
>>
>> Hi Bengt,
>>
>> the system.properties is not directly
evaluate.
>>
>> Could you try to define your variable in the
>> custom.properties ?
>>
>> Regards
>> JB
>>
>>
>> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>>
>> Hi,
>>
>> I'm using Karaf 2.2.3. We're using
>> Karaf+Camel as
>> the basis for an
>> integration platform. We use config admin
>> extensively in order
>> to define
>> camel routes. As a convenience we define
>> variables (in
>> system.properties) that can be used in
>> the different
>> configurations. E g
>> defining a "dataRoot" variable that the
>> specifies a root
>> directory in
>> the file system that routes can relate to.
>>
>> If I, in system.properties specify the
>> following:
>>
>> dataRoot = D:/data
>> customer1Root = ${dataRoot}/customer1
>>
>> Then the value of "customer1Root" will be
>> "/customer1". The
>> "${dataRoot}" evaluates to an empty string. Why is that? If I
>> instead
>> define "dataRoot" as a real system
>> property (using
>> the -D option
>> to the
>> JVM) then it works.
>>
>> In my configuration files (parsed by
>> fileinstall) it
>> works to
>> use the
>> ${...} notation to refer to variables in
>> system.properties. What
>> then
>> does not seem to work is if I in
>> system.properties
>> try to refer to
>> another variable defined in
>> system.properties.
>>
>> This seems like a bug to me.
>>
>> I would also like to find out what the
>> status is on
>> the redesign of
>> system.properties. I would very much
>> like the
>> possibility to add my
>> specific variables outside of the Karaf
>> installation. I already
>> create a
>> custom distribution but the variables
>> need to be
>> added on a per
>> installation basis. The customer himself
>> decides
>> what convenience
>> variables are needed and I don't want
>> the customer
>> to fiddle
>> with the
>> Karaf installation.
>>
>> The functionality I'm looking for is
>> something like
>> this:
>> Somewhere in
>> the Karaf configuration I would like to
>> specify that
>> Karaf
>> should read
>> variable definitions from a file (or
>> list of files)
>> that I
>> specify. I
>> can then separate my, installation
specific,
>> variables from the
>> standard
>> Karaf installation. I have brought this
>> up before
>> and was under the
>> impression that something like this was
>> in scope for
>> Karaf 3 (or
>> even
>> earlier). What is the status of this kind
of
>> customisation?
>>
>> /Bengt
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> <mailto:jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>>
>>
>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Problems with system.properties
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Bengt,
sorry, I was busy on another project yesterday. I will check it this
afternoon.
Regards
JB
On 11/22/2011 10:04 AM, Bengt Rodehav wrote:
> Hello again JB,
>
> Did you check whether it is possible to use system properties in
> config.properties?
>
> I've been experimenting a bit more with our custom Karaf distribution
> and I think that the combination of:
>
> a) Being able to use system properties in config.properties
> b) Being able to specify optional includes in ${includes} (KARAF-1014)
>
> Would benefit us a lot. Most of the things that need to be installation
> specific can then be extracted into one or several property files that
> can optionally be overridden per installation. We can then have one
> custom distribution instead of several different ones.
>
> I'm a bit anxious to be able to use this possibility.
>
> /Bengt
>
> 2011/11/15 Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
>
> Thanks for your answers JB. I created the following JIRA:
>
> https://issues.apache.org/jira/browse/KARAF-1014
>
> /Bengt
>
>
> 2011/11/15 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>
>
> Hi Bengt,
>
> My comments inline:
>
>
> I guess it's some kind of catch 22 going on here. I would
> really like to
> be able to use system properties at this point. Can I create
> a JIRA for
> this?
>
>
> It should work already. Let me take a look, I will raise a Jira
> if the system variables are not used.
>
>
>
> I can get it to work by using a relative path to specify
> where my
> custom.properties file reside. However, it appears that the
> "current
> directory" is not "karaf.home" but the "etc" directory under
> the Karaf
> installation. Is this by design?
>
>
> Yes, it's the default behavior. But it could make sense to be
> able to put any absolute path here. Let me think about that.
>
>
>
> Out of curiosity I also wonder why the property is called
> "${includes}"
> and not just "includes". I assume some "cleverness" is gong
> on here...
>
>
> It's because it's used and populated by others scripts.
>
>
>
> Finally, I would like to have the possibility to not have to
> create my
> "custom" custom.properties. If I specify its location in the
> ${includes}
> property then Karaf fails to start if the file doesn't
> exist. I would
> like Karaf to pick up the file if it exists, otherwise, I
> would like
> Karaf to ignore it and just continue. That would allow us to
> provide
> custom variables if we wanted to but it wouldn't require each
> installation to have a custom.properties.
>
>
> It makes sense, Karaf should check if the file exists before
> trying to load it. Could you raise a Jira for that ?
>
> Thanks
> Regards
> JB
>
>
> /Bengt
>
>
>
> 2011/11/11 Bengt Rodehav <bengt@rodehav.com
> <ma...@rodehav.com> <mailto:bengt@rodehav.com
> <ma...@rodehav.com>>>
>
>
> Perfect!
>
> I didn't know about the ${includes}. Will try it out as
> soon as
> possible.
>
> Thanks a lot,
>
> /Bengt
>
> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>
>
>
> Hi Bengt,
>
> it's exactly the purpose of custom.properties.
>
> Basically:
> - system.properties is "reserved" for Karaf itself.
> - config.properties is "reserved" for "application"
> - custom.properties is "reserved" for your usage
>
> You can put the custom.properties where you want.
> You just need
> to update the ${includes} property in the
> etc/system.properties.
>
> Regards
> JB
>
>
> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>
> Thanks for your reply JB,
>
> Yes, if I put the variables in custom.properties
> they can
> reference each
> other directly. Given these lines in
> custom.properties:
>
> /MyRootDir=C:/Temp/
> /MySubDir=${MyRootDir}/Sub/
>
>
> Gives the value "C:/Temp/Sub" for the variable
> "MySubDir".
>
> Thanks!
>
> I guess then that best practice is to use
> custom.properties
> for this?
> This is good since it doesn't (should not)
> contain any
> configuration
> out-of-the-box. I noticed that the
> karaf.systemBundlesStartLevel is
> defined there. I think that should be removed.
>
> Now if there was a way to specify that the
> custom.properties
> file should
> reside somewhere else then I would be very
> happy. The reason
> is that we
> do not want to put installation specific
> configuration in
> the Karaf
> installation. Do you have an update regarding this?
>
> /Bengt
>
>
> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>
>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>>
>
>
> Hi Bengt,
>
> the system.properties is not directly evaluate.
>
> Could you try to define your variable in the
> custom.properties ?
>
> Regards
> JB
>
>
> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>
> Hi,
>
> I'm using Karaf 2.2.3. We're using
> Karaf+Camel as
> the basis for an
> integration platform. We use config admin
> extensively in order
> to define
> camel routes. As a convenience we define
> variables (in
> system.properties) that can be used in
> the different
> configurations. E g
> defining a "dataRoot" variable that the
> specifies a root
> directory in
> the file system that routes can relate to.
>
> If I, in system.properties specify the
> following:
>
> dataRoot = D:/data
> customer1Root = ${dataRoot}/customer1
>
> Then the value of "customer1Root" will be
> "/customer1". The
> "${dataRoot}" evaluates to an empty string. Why is that? If I
> instead
> define "dataRoot" as a real system
> property (using
> the -D option
> to the
> JVM) then it works.
>
> In my configuration files (parsed by
> fileinstall) it
> works to
> use the
> ${...} notation to refer to variables in
> system.properties. What
> then
> does not seem to work is if I in
> system.properties
> try to refer to
> another variable defined in
> system.properties.
>
> This seems like a bug to me.
>
> I would also like to find out what the
> status is on
> the redesign of
> system.properties. I would very much
> like the
> possibility to add my
> specific variables outside of the Karaf
> installation. I already
> create a
> custom distribution but the variables
> need to be
> added on a per
> installation basis. The customer himself
> decides
> what convenience
> variables are needed and I don't want
> the customer
> to fiddle
> with the
> Karaf installation.
>
> The functionality I'm looking for is
> something like
> this:
> Somewhere in
> the Karaf configuration I would like to
> specify that
> Karaf
> should read
> variable definitions from a file (or
> list of files)
> that I
> specify. I
> can then separate my, installation specific,
> variables from the
> standard
> Karaf installation. I have brought this
> up before
> and was under the
> impression that something like this was
> in scope for
> Karaf 3 (or
> even
> earlier). What is the status of this kind of
> customisation?
>
> /Bengt
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
> <mailto:jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>>
>
>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
Hello again JB,
Did you check whether it is possible to use system properties in
config.properties?
I've been experimenting a bit more with our custom Karaf distribution and I
think that the combination of:
a) Being able to use system properties in config.properties
b) Being able to specify optional includes in ${includes} (KARAF-1014)
Would benefit us a lot. Most of the things that need to be installation
specific can then be extracted into one or several property files that can
optionally be overridden per installation. We can then have one custom
distribution instead of several different ones.
I'm a bit anxious to be able to use this possibility.
/Bengt
2011/11/15 Bengt Rodehav <be...@rodehav.com>
> Thanks for your answers JB. I created the following JIRA:
>
> https://issues.apache.org/jira/browse/KARAF-1014
>
> /Bengt
>
>
> 2011/11/15 Jean-Baptiste Onofré <jb...@nanthrax.net>
>
>> Hi Bengt,
>>
>> My comments inline:
>>
>>
>> I guess it's some kind of catch 22 going on here. I would really like to
>>> be able to use system properties at this point. Can I create a JIRA for
>>> this?
>>>
>>
>> It should work already. Let me take a look, I will raise a Jira if the
>> system variables are not used.
>>
>>
>>
>>> I can get it to work by using a relative path to specify where my
>>> custom.properties file reside. However, it appears that the "current
>>> directory" is not "karaf.home" but the "etc" directory under the Karaf
>>> installation. Is this by design?
>>>
>>
>> Yes, it's the default behavior. But it could make sense to be able to put
>> any absolute path here. Let me think about that.
>>
>>
>>
>>> Out of curiosity I also wonder why the property is called "${includes}"
>>> and not just "includes". I assume some "cleverness" is gong on here...
>>>
>>
>> It's because it's used and populated by others scripts.
>>
>>
>>
>>> Finally, I would like to have the possibility to not have to create my
>>> "custom" custom.properties. If I specify its location in the ${includes}
>>> property then Karaf fails to start if the file doesn't exist. I would
>>> like Karaf to pick up the file if it exists, otherwise, I would like
>>> Karaf to ignore it and just continue. That would allow us to provide
>>> custom variables if we wanted to but it wouldn't require each
>>> installation to have a custom.properties.
>>>
>>
>> It makes sense, Karaf should check if the file exists before trying to
>> load it. Could you raise a Jira for that ?
>>
>> Thanks
>> Regards
>> JB
>>
>>
>>> /Bengt
>>>
>>>
>>>
>>> 2011/11/11 Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
>>>
>>>
>>> Perfect!
>>>
>>> I didn't know about the ${includes}. Will try it out as soon as
>>> possible.
>>>
>>> Thanks a lot,
>>>
>>> /Bengt
>>>
>>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
>>> <ma...@nanthrax.net>>
>>>
>>>
>>> Hi Bengt,
>>>
>>> it's exactly the purpose of custom.properties.
>>>
>>> Basically:
>>> - system.properties is "reserved" for Karaf itself.
>>> - config.properties is "reserved" for "application"
>>> - custom.properties is "reserved" for your usage
>>>
>>> You can put the custom.properties where you want. You just need
>>> to update the ${includes} property in the etc/system.properties.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>>>
>>> Thanks for your reply JB,
>>>
>>> Yes, if I put the variables in custom.properties they can
>>> reference each
>>> other directly. Given these lines in custom.properties:
>>>
>>> /MyRootDir=C:/Temp/
>>> /MySubDir=${MyRootDir}/Sub/
>>>
>>>
>>> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>>>
>>> Thanks!
>>>
>>> I guess then that best practice is to use custom.properties
>>> for this?
>>> This is good since it doesn't (should not) contain any
>>> configuration
>>> out-of-the-box. I noticed that the
>>> karaf.systemBundlesStartLevel is
>>> defined there. I think that should be removed.
>>>
>>> Now if there was a way to specify that the custom.properties
>>> file should
>>> reside somewhere else then I would be very happy. The reason
>>> is that we
>>> do not want to put installation specific configuration in
>>> the Karaf
>>> installation. Do you have an update regarding this?
>>>
>>> /Bengt
>>>
>>>
>>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
>>> <ma...@nanthrax.net> <mailto:jb@nanthrax.net
>>>
>>> <ma...@nanthrax.net>>>
>>>
>>>
>>> Hi Bengt,
>>>
>>> the system.properties is not directly evaluate.
>>>
>>> Could you try to define your variable in the
>>> custom.properties ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>>>
>>> Hi,
>>>
>>> I'm using Karaf 2.2.3. We're using Karaf+Camel as
>>> the basis for an
>>> integration platform. We use config admin
>>> extensively in order
>>> to define
>>> camel routes. As a convenience we define variables (in
>>> system.properties) that can be used in the different
>>> configurations. E g
>>> defining a "dataRoot" variable that the specifies a
>>> root
>>> directory in
>>> the file system that routes can relate to.
>>>
>>> If I, in system.properties specify the following:
>>>
>>> dataRoot = D:/data
>>> customer1Root = ${dataRoot}/customer1
>>>
>>> Then the value of "customer1Root" will be
>>> "/customer1". The
>>> "${dataRoot}" evaluates to an empty string. Why is that? If I
>>> instead
>>> define "dataRoot" as a real system property (using
>>> the -D option
>>> to the
>>> JVM) then it works.
>>>
>>> In my configuration files (parsed by fileinstall) it
>>> works to
>>> use the
>>> ${...} notation to refer to variables in
>>> system.properties. What
>>> then
>>> does not seem to work is if I in system.properties
>>> try to refer to
>>> another variable defined in system.properties.
>>>
>>> This seems like a bug to me.
>>>
>>> I would also like to find out what the status is on
>>> the redesign of
>>> system.properties. I would very much like the
>>> possibility to add my
>>> specific variables outside of the Karaf
>>> installation. I already
>>> create a
>>> custom distribution but the variables need to be
>>> added on a per
>>> installation basis. The customer himself decides
>>> what convenience
>>> variables are needed and I don't want the customer
>>> to fiddle
>>> with the
>>> Karaf installation.
>>>
>>> The functionality I'm looking for is something like
>>> this:
>>> Somewhere in
>>> the Karaf configuration I would like to specify that
>>> Karaf
>>> should read
>>> variable definitions from a file (or list of files)
>>> that I
>>> specify. I
>>> can then separate my, installation specific,
>>> variables from the
>>> standard
>>> Karaf installation. I have brought this up before
>>> and was under the
>>> impression that something like this was in scope for
>>> Karaf 3 (or
>>> even
>>> earlier). What is the status of this kind of
>>> customisation?
>>>
>>> /Bengt
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>>>
>>>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks for your answers JB. I created the following JIRA:
https://issues.apache.org/jira/browse/KARAF-1014
/Bengt
2011/11/15 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi Bengt,
>
> My comments inline:
>
>
> I guess it's some kind of catch 22 going on here. I would really like to
>> be able to use system properties at this point. Can I create a JIRA for
>> this?
>>
>
> It should work already. Let me take a look, I will raise a Jira if the
> system variables are not used.
>
>
>
>> I can get it to work by using a relative path to specify where my
>> custom.properties file reside. However, it appears that the "current
>> directory" is not "karaf.home" but the "etc" directory under the Karaf
>> installation. Is this by design?
>>
>
> Yes, it's the default behavior. But it could make sense to be able to put
> any absolute path here. Let me think about that.
>
>
>
>> Out of curiosity I also wonder why the property is called "${includes}"
>> and not just "includes". I assume some "cleverness" is gong on here...
>>
>
> It's because it's used and populated by others scripts.
>
>
>
>> Finally, I would like to have the possibility to not have to create my
>> "custom" custom.properties. If I specify its location in the ${includes}
>> property then Karaf fails to start if the file doesn't exist. I would
>> like Karaf to pick up the file if it exists, otherwise, I would like
>> Karaf to ignore it and just continue. That would allow us to provide
>> custom variables if we wanted to but it wouldn't require each
>> installation to have a custom.properties.
>>
>
> It makes sense, Karaf should check if the file exists before trying to
> load it. Could you raise a Jira for that ?
>
> Thanks
> Regards
> JB
>
>
>> /Bengt
>>
>>
>>
>> 2011/11/11 Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
>>
>>
>> Perfect!
>>
>> I didn't know about the ${includes}. Will try it out as soon as
>> possible.
>>
>> Thanks a lot,
>>
>> /Bengt
>>
>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>
>>
>>
>> Hi Bengt,
>>
>> it's exactly the purpose of custom.properties.
>>
>> Basically:
>> - system.properties is "reserved" for Karaf itself.
>> - config.properties is "reserved" for "application"
>> - custom.properties is "reserved" for your usage
>>
>> You can put the custom.properties where you want. You just need
>> to update the ${includes} property in the etc/system.properties.
>>
>> Regards
>> JB
>>
>>
>> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>>
>> Thanks for your reply JB,
>>
>> Yes, if I put the variables in custom.properties they can
>> reference each
>> other directly. Given these lines in custom.properties:
>>
>> /MyRootDir=C:/Temp/
>> /MySubDir=${MyRootDir}/Sub/
>>
>>
>> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>>
>> Thanks!
>>
>> I guess then that best practice is to use custom.properties
>> for this?
>> This is good since it doesn't (should not) contain any
>> configuration
>> out-of-the-box. I noticed that the
>> karaf.systemBundlesStartLevel is
>> defined there. I think that should be removed.
>>
>> Now if there was a way to specify that the custom.properties
>> file should
>> reside somewhere else then I would be very happy. The reason
>> is that we
>> do not want to put installation specific configuration in
>> the Karaf
>> installation. Do you have an update regarding this?
>>
>> /Bengt
>>
>>
>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net> <mailto:jb@nanthrax.net
>>
>> <ma...@nanthrax.net>>>
>>
>>
>> Hi Bengt,
>>
>> the system.properties is not directly evaluate.
>>
>> Could you try to define your variable in the
>> custom.properties ?
>>
>> Regards
>> JB
>>
>>
>> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>>
>> Hi,
>>
>> I'm using Karaf 2.2.3. We're using Karaf+Camel as
>> the basis for an
>> integration platform. We use config admin
>> extensively in order
>> to define
>> camel routes. As a convenience we define variables (in
>> system.properties) that can be used in the different
>> configurations. E g
>> defining a "dataRoot" variable that the specifies a
>> root
>> directory in
>> the file system that routes can relate to.
>>
>> If I, in system.properties specify the following:
>>
>> dataRoot = D:/data
>> customer1Root = ${dataRoot}/customer1
>>
>> Then the value of "customer1Root" will be
>> "/customer1". The
>> "${dataRoot}" evaluates to an empty string. Why is that? If I
>> instead
>> define "dataRoot" as a real system property (using
>> the -D option
>> to the
>> JVM) then it works.
>>
>> In my configuration files (parsed by fileinstall) it
>> works to
>> use the
>> ${...} notation to refer to variables in
>> system.properties. What
>> then
>> does not seem to work is if I in system.properties
>> try to refer to
>> another variable defined in system.properties.
>>
>> This seems like a bug to me.
>>
>> I would also like to find out what the status is on
>> the redesign of
>> system.properties. I would very much like the
>> possibility to add my
>> specific variables outside of the Karaf
>> installation. I already
>> create a
>> custom distribution but the variables need to be
>> added on a per
>> installation basis. The customer himself decides
>> what convenience
>> variables are needed and I don't want the customer
>> to fiddle
>> with the
>> Karaf installation.
>>
>> The functionality I'm looking for is something like
>> this:
>> Somewhere in
>> the Karaf configuration I would like to specify that
>> Karaf
>> should read
>> variable definitions from a file (or list of files)
>> that I
>> specify. I
>> can then separate my, installation specific,
>> variables from the
>> standard
>> Karaf installation. I have brought this up before
>> and was under the
>> impression that something like this was in scope for
>> Karaf 3 (or
>> even
>> earlier). What is the status of this kind of
>> customisation?
>>
>> /Bengt
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>>
>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with system.properties
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Bengt,
My comments inline:
> I guess it's some kind of catch 22 going on here. I would really like to
> be able to use system properties at this point. Can I create a JIRA for
> this?
It should work already. Let me take a look, I will raise a Jira if the
system variables are not used.
>
> I can get it to work by using a relative path to specify where my
> custom.properties file reside. However, it appears that the "current
> directory" is not "karaf.home" but the "etc" directory under the Karaf
> installation. Is this by design?
Yes, it's the default behavior. But it could make sense to be able to
put any absolute path here. Let me think about that.
>
> Out of curiosity I also wonder why the property is called "${includes}"
> and not just "includes". I assume some "cleverness" is gong on here...
It's because it's used and populated by others scripts.
>
> Finally, I would like to have the possibility to not have to create my
> "custom" custom.properties. If I specify its location in the ${includes}
> property then Karaf fails to start if the file doesn't exist. I would
> like Karaf to pick up the file if it exists, otherwise, I would like
> Karaf to ignore it and just continue. That would allow us to provide
> custom variables if we wanted to but it wouldn't require each
> installation to have a custom.properties.
It makes sense, Karaf should check if the file exists before trying to
load it. Could you raise a Jira for that ?
Thanks
Regards
JB
>
> /Bengt
>
>
>
> 2011/11/11 Bengt Rodehav <bengt@rodehav.com <ma...@rodehav.com>>
>
> Perfect!
>
> I didn't know about the ${includes}. Will try it out as soon as
> possible.
>
> Thanks a lot,
>
> /Bengt
>
> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>
>
> Hi Bengt,
>
> it's exactly the purpose of custom.properties.
>
> Basically:
> - system.properties is "reserved" for Karaf itself.
> - config.properties is "reserved" for "application"
> - custom.properties is "reserved" for your usage
>
> You can put the custom.properties where you want. You just need
> to update the ${includes} property in the etc/system.properties.
>
> Regards
> JB
>
>
> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>
> Thanks for your reply JB,
>
> Yes, if I put the variables in custom.properties they can
> reference each
> other directly. Given these lines in custom.properties:
>
> /MyRootDir=C:/Temp/
> /MySubDir=${MyRootDir}/Sub/
>
>
> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>
> Thanks!
>
> I guess then that best practice is to use custom.properties
> for this?
> This is good since it doesn't (should not) contain any
> configuration
> out-of-the-box. I noticed that the
> karaf.systemBundlesStartLevel is
> defined there. I think that should be removed.
>
> Now if there was a way to specify that the custom.properties
> file should
> reside somewhere else then I would be very happy. The reason
> is that we
> do not want to put installation specific configuration in
> the Karaf
> installation. Do you have an update regarding this?
>
> /Bengt
>
>
> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net> <mailto:jb@nanthrax.net
> <ma...@nanthrax.net>>>
>
>
> Hi Bengt,
>
> the system.properties is not directly evaluate.
>
> Could you try to define your variable in the
> custom.properties ?
>
> Regards
> JB
>
>
> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>
> Hi,
>
> I'm using Karaf 2.2.3. We're using Karaf+Camel as
> the basis for an
> integration platform. We use config admin
> extensively in order
> to define
> camel routes. As a convenience we define variables (in
> system.properties) that can be used in the different
> configurations. E g
> defining a "dataRoot" variable that the specifies a root
> directory in
> the file system that routes can relate to.
>
> If I, in system.properties specify the following:
>
> dataRoot = D:/data
> customer1Root = ${dataRoot}/customer1
>
> Then the value of "customer1Root" will be
> "/customer1". The
> "${dataRoot}" evaluates to an empty string. Why is that? If I
> instead
> define "dataRoot" as a real system property (using
> the -D option
> to the
> JVM) then it works.
>
> In my configuration files (parsed by fileinstall) it
> works to
> use the
> ${...} notation to refer to variables in
> system.properties. What
> then
> does not seem to work is if I in system.properties
> try to refer to
> another variable defined in system.properties.
>
> This seems like a bug to me.
>
> I would also like to find out what the status is on
> the redesign of
> system.properties. I would very much like the
> possibility to add my
> specific variables outside of the Karaf
> installation. I already
> create a
> custom distribution but the variables need to be
> added on a per
> installation basis. The customer himself decides
> what convenience
> variables are needed and I don't want the customer
> to fiddle
> with the
> Karaf installation.
>
> The functionality I'm looking for is something like
> this:
> Somewhere in
> the Karaf configuration I would like to specify that
> Karaf
> should read
> variable definitions from a file (or list of files)
> that I
> specify. I
> can then separate my, installation specific,
> variables from the
> standard
> Karaf installation. I have brought this up before
> and was under the
> impression that something like this was in scope for
> Karaf 3 (or
> even
> earlier). What is the status of this kind of
> customisation?
>
> /Bengt
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
JB,
Did try out your suggestion and I got it to work but I have a question (and
perhaps a request for change). This is what I did:
I modified config.properties and changed the ${includes} property as
follows:
*${includes} = jre.properties custom.properties ${confdir}/custom.properties
*
"confdir" is a system property that I set using the "-D" option to the JVM.
It points out a directory outside the Karaf installation where we keep our
application's specific configuration. By keeping it outside of the Karaf
installation we can easily upgrade Karaf without having to recreate all the
application specific configuration. We use an environment variable to point
out this directory and we then set a system property that can be used to
find this location. However, ${confdir} is not evaluated by Karaf. I get an
error mesage saying:
*java.io.FileNotFoundException:
C:\dev\Karaf\stsweb\apache-karaf-2.2.3\etc\${confdir}\custom.properties
(The system cannot find the path specified)*
I guess it's some kind of catch 22 going on here. I would really like to be
able to use system properties at this point. Can I create a JIRA for this?
I can get it to work by using a relative path to specify where my
custom.properties file reside. However, it appears that the "current
directory" is not "karaf.home" but the "etc" directory under the Karaf
installation. Is this by design?
Out of curiosity I also wonder why the property is called "${includes}" and
not just "includes". I assume some "cleverness" is gong on here...
Finally, I would like to have the possibility to not have to create my
"custom" custom.properties. If I specify its location in the ${includes}
property then Karaf fails to start if the file doesn't exist. I would like
Karaf to pick up the file if it exists, otherwise, I would like Karaf to
ignore it and just continue. That would allow us to provide custom
variables if we wanted to but it wouldn't require each installation to have
a custom.properties.
/Bengt
2011/11/11 Bengt Rodehav <be...@rodehav.com>
> Perfect!
>
> I didn't know about the ${includes}. Will try it out as soon as possible.
>
> Thanks a lot,
>
> /Bengt
>
> 2011/11/11 Jean-Baptiste Onofré <jb...@nanthrax.net>
>
>> Hi Bengt,
>>
>> it's exactly the purpose of custom.properties.
>>
>> Basically:
>> - system.properties is "reserved" for Karaf itself.
>> - config.properties is "reserved" for "application"
>> - custom.properties is "reserved" for your usage
>>
>> You can put the custom.properties where you want. You just need to update
>> the ${includes} property in the etc/system.properties.
>>
>> Regards
>> JB
>>
>>
>> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>>
>>> Thanks for your reply JB,
>>>
>>> Yes, if I put the variables in custom.properties they can reference each
>>> other directly. Given these lines in custom.properties:
>>>
>>> /MyRootDir=C:/Temp/
>>> /MySubDir=${MyRootDir}/Sub/
>>>
>>>
>>> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>>>
>>> Thanks!
>>>
>>> I guess then that best practice is to use custom.properties for this?
>>> This is good since it doesn't (should not) contain any configuration
>>> out-of-the-box. I noticed that the karaf.systemBundlesStartLevel is
>>> defined there. I think that should be removed.
>>>
>>> Now if there was a way to specify that the custom.properties file should
>>> reside somewhere else then I would be very happy. The reason is that we
>>> do not want to put installation specific configuration in the Karaf
>>> installation. Do you have an update regarding this?
>>>
>>> /Bengt
>>>
>>>
>>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net <mailto:jb@nanthrax.net
>>> >>
>>>
>>>
>>> Hi Bengt,
>>>
>>> the system.properties is not directly evaluate.
>>>
>>> Could you try to define your variable in the custom.properties ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>>>
>>> Hi,
>>>
>>> I'm using Karaf 2.2.3. We're using Karaf+Camel as the basis for an
>>> integration platform. We use config admin extensively in order
>>> to define
>>> camel routes. As a convenience we define variables (in
>>> system.properties) that can be used in the different
>>> configurations. E g
>>> defining a "dataRoot" variable that the specifies a root
>>> directory in
>>> the file system that routes can relate to.
>>>
>>> If I, in system.properties specify the following:
>>>
>>> dataRoot = D:/data
>>> customer1Root = ${dataRoot}/customer1
>>>
>>> Then the value of "customer1Root" will be "/customer1". The
>>> "${dataRoot}" evaluates to an empty string. Why is that? If I
>>> instead
>>> define "dataRoot" as a real system property (using the -D option
>>> to the
>>> JVM) then it works.
>>>
>>> In my configuration files (parsed by fileinstall) it works to
>>> use the
>>> ${...} notation to refer to variables in system.properties. What
>>> then
>>> does not seem to work is if I in system.properties try to refer to
>>> another variable defined in system.properties.
>>>
>>> This seems like a bug to me.
>>>
>>> I would also like to find out what the status is on the redesign
>>> of
>>> system.properties. I would very much like the possibility to add
>>> my
>>> specific variables outside of the Karaf installation. I already
>>> create a
>>> custom distribution but the variables need to be added on a per
>>> installation basis. The customer himself decides what convenience
>>> variables are needed and I don't want the customer to fiddle
>>> with the
>>> Karaf installation.
>>>
>>> The functionality I'm looking for is something like this:
>>> Somewhere in
>>> the Karaf configuration I would like to specify that Karaf
>>> should read
>>> variable definitions from a file (or list of files) that I
>>> specify. I
>>> can then separate my, installation specific, variables from the
>>> standard
>>> Karaf installation. I have brought this up before and was under
>>> the
>>> impression that something like this was in scope for Karaf 3 (or
>>> even
>>> earlier). What is the status of this kind of customisation?
>>>
>>> /Bengt
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
Perfect!
I didn't know about the ${includes}. Will try it out as soon as possible.
Thanks a lot,
/Bengt
2011/11/11 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi Bengt,
>
> it's exactly the purpose of custom.properties.
>
> Basically:
> - system.properties is "reserved" for Karaf itself.
> - config.properties is "reserved" for "application"
> - custom.properties is "reserved" for your usage
>
> You can put the custom.properties where you want. You just need to update
> the ${includes} property in the etc/system.properties.
>
> Regards
> JB
>
>
> On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
>
>> Thanks for your reply JB,
>>
>> Yes, if I put the variables in custom.properties they can reference each
>> other directly. Given these lines in custom.properties:
>>
>> /MyRootDir=C:/Temp/
>> /MySubDir=${MyRootDir}/Sub/
>>
>>
>> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>>
>> Thanks!
>>
>> I guess then that best practice is to use custom.properties for this?
>> This is good since it doesn't (should not) contain any configuration
>> out-of-the-box. I noticed that the karaf.systemBundlesStartLevel is
>> defined there. I think that should be removed.
>>
>> Now if there was a way to specify that the custom.properties file should
>> reside somewhere else then I would be very happy. The reason is that we
>> do not want to put installation specific configuration in the Karaf
>> installation. Do you have an update regarding this?
>>
>> /Bengt
>>
>>
>> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net <mailto:jb@nanthrax.net
>> >>
>>
>>
>> Hi Bengt,
>>
>> the system.properties is not directly evaluate.
>>
>> Could you try to define your variable in the custom.properties ?
>>
>> Regards
>> JB
>>
>>
>> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>>
>> Hi,
>>
>> I'm using Karaf 2.2.3. We're using Karaf+Camel as the basis for an
>> integration platform. We use config admin extensively in order
>> to define
>> camel routes. As a convenience we define variables (in
>> system.properties) that can be used in the different
>> configurations. E g
>> defining a "dataRoot" variable that the specifies a root
>> directory in
>> the file system that routes can relate to.
>>
>> If I, in system.properties specify the following:
>>
>> dataRoot = D:/data
>> customer1Root = ${dataRoot}/customer1
>>
>> Then the value of "customer1Root" will be "/customer1". The
>> "${dataRoot}" evaluates to an empty string. Why is that? If I
>> instead
>> define "dataRoot" as a real system property (using the -D option
>> to the
>> JVM) then it works.
>>
>> In my configuration files (parsed by fileinstall) it works to
>> use the
>> ${...} notation to refer to variables in system.properties. What
>> then
>> does not seem to work is if I in system.properties try to refer to
>> another variable defined in system.properties.
>>
>> This seems like a bug to me.
>>
>> I would also like to find out what the status is on the redesign of
>> system.properties. I would very much like the possibility to add my
>> specific variables outside of the Karaf installation. I already
>> create a
>> custom distribution but the variables need to be added on a per
>> installation basis. The customer himself decides what convenience
>> variables are needed and I don't want the customer to fiddle
>> with the
>> Karaf installation.
>>
>> The functionality I'm looking for is something like this:
>> Somewhere in
>> the Karaf configuration I would like to specify that Karaf
>> should read
>> variable definitions from a file (or list of files) that I
>> specify. I
>> can then separate my, installation specific, variables from the
>> standard
>> Karaf installation. I have brought this up before and was under the
>> impression that something like this was in scope for Karaf 3 (or
>> even
>> earlier). What is the status of this kind of customisation?
>>
>> /Bengt
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with system.properties
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Bengt,
it's exactly the purpose of custom.properties.
Basically:
- system.properties is "reserved" for Karaf itself.
- config.properties is "reserved" for "application"
- custom.properties is "reserved" for your usage
You can put the custom.properties where you want. You just need to
update the ${includes} property in the etc/system.properties.
Regards
JB
On 11/11/2011 05:15 PM, Bengt Rodehav wrote:
> Thanks for your reply JB,
>
> Yes, if I put the variables in custom.properties they can reference each
> other directly. Given these lines in custom.properties:
>
> /MyRootDir=C:/Temp/
> /MySubDir=${MyRootDir}/Sub/
>
> Gives the value "C:/Temp/Sub" for the variable "MySubDir".
>
> Thanks!
>
> I guess then that best practice is to use custom.properties for this?
> This is good since it doesn't (should not) contain any configuration
> out-of-the-box. I noticed that the karaf.systemBundlesStartLevel is
> defined there. I think that should be removed.
>
> Now if there was a way to specify that the custom.properties file should
> reside somewhere else then I would be very happy. The reason is that we
> do not want to put installation specific configuration in the Karaf
> installation. Do you have an update regarding this?
>
> /Bengt
>
>
> 2011/11/11 Jean-Baptiste Onofré <jb@nanthrax.net <ma...@nanthrax.net>>
>
> Hi Bengt,
>
> the system.properties is not directly evaluate.
>
> Could you try to define your variable in the custom.properties ?
>
> Regards
> JB
>
>
> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>
> Hi,
>
> I'm using Karaf 2.2.3. We're using Karaf+Camel as the basis for an
> integration platform. We use config admin extensively in order
> to define
> camel routes. As a convenience we define variables (in
> system.properties) that can be used in the different
> configurations. E g
> defining a "dataRoot" variable that the specifies a root
> directory in
> the file system that routes can relate to.
>
> If I, in system.properties specify the following:
>
> dataRoot = D:/data
> customer1Root = ${dataRoot}/customer1
>
> Then the value of "customer1Root" will be "/customer1". The
> "${dataRoot}" evaluates to an empty string. Why is that? If I
> instead
> define "dataRoot" as a real system property (using the -D option
> to the
> JVM) then it works.
>
> In my configuration files (parsed by fileinstall) it works to
> use the
> ${...} notation to refer to variables in system.properties. What
> then
> does not seem to work is if I in system.properties try to refer to
> another variable defined in system.properties.
>
> This seems like a bug to me.
>
> I would also like to find out what the status is on the redesign of
> system.properties. I would very much like the possibility to add my
> specific variables outside of the Karaf installation. I already
> create a
> custom distribution but the variables need to be added on a per
> installation basis. The customer himself decides what convenience
> variables are needed and I don't want the customer to fiddle
> with the
> Karaf installation.
>
> The functionality I'm looking for is something like this:
> Somewhere in
> the Karaf configuration I would like to specify that Karaf
> should read
> variable definitions from a file (or list of files) that I
> specify. I
> can then separate my, installation specific, variables from the
> standard
> Karaf installation. I have brought this up before and was under the
> impression that something like this was in scope for Karaf 3 (or
> even
> earlier). What is the status of this kind of customisation?
>
> /Bengt
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems with system.properties
Posted by Bengt Rodehav <be...@rodehav.com>.
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é <jb...@nanthrax.net>
> Hi Bengt,
>
> the system.properties is not directly evaluate.
>
> Could you try to define your variable in the custom.properties ?
>
> Regards
> JB
>
>
> On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
>
>> Hi,
>>
>> I'm using Karaf 2.2.3. We're using Karaf+Camel as the basis for an
>> integration platform. We use config admin extensively in order to define
>> camel routes. As a convenience we define variables (in
>> system.properties) that can be used in the different configurations. E g
>> defining a "dataRoot" variable that the specifies a root directory in
>> the file system that routes can relate to.
>>
>> If I, in system.properties specify the following:
>>
>> dataRoot = D:/data
>> customer1Root = ${dataRoot}/customer1
>>
>> Then the value of "customer1Root" will be "/customer1". The
>> "${dataRoot}" evaluates to an empty string. Why is that? If I instead
>> define "dataRoot" as a real system property (using the -D option to the
>> JVM) then it works.
>>
>> In my configuration files (parsed by fileinstall) it works to use the
>> ${...} notation to refer to variables in system.properties. What then
>> does not seem to work is if I in system.properties try to refer to
>> another variable defined in system.properties.
>>
>> This seems like a bug to me.
>>
>> I would also like to find out what the status is on the redesign of
>> system.properties. I would very much like the possibility to add my
>> specific variables outside of the Karaf installation. I already create a
>> custom distribution but the variables need to be added on a per
>> installation basis. The customer himself decides what convenience
>> variables are needed and I don't want the customer to fiddle with the
>> Karaf installation.
>>
>> The functionality I'm looking for is something like this: Somewhere in
>> the Karaf configuration I would like to specify that Karaf should read
>> variable definitions from a file (or list of files) that I specify. I
>> can then separate my, installation specific, variables from the standard
>> Karaf installation. I have brought this up before and was under the
>> impression that something like this was in scope for Karaf 3 (or even
>> earlier). What is the status of this kind of customisation?
>>
>> /Bengt
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Problems with system.properties
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Bengt,
the system.properties is not directly evaluate.
Could you try to define your variable in the custom.properties ?
Regards
JB
On 11/11/2011 03:51 PM, Bengt Rodehav wrote:
> Hi,
>
> I'm using Karaf 2.2.3. We're using Karaf+Camel as the basis for an
> integration platform. We use config admin extensively in order to define
> camel routes. As a convenience we define variables (in
> system.properties) that can be used in the different configurations. E g
> defining a "dataRoot" variable that the specifies a root directory in
> the file system that routes can relate to.
>
> If I, in system.properties specify the following:
>
> dataRoot = D:/data
> customer1Root = ${dataRoot}/customer1
>
> Then the value of "customer1Root" will be "/customer1". The
> "${dataRoot}" evaluates to an empty string. Why is that? If I instead
> define "dataRoot" as a real system property (using the -D option to the
> JVM) then it works.
>
> In my configuration files (parsed by fileinstall) it works to use the
> ${...} notation to refer to variables in system.properties. What then
> does not seem to work is if I in system.properties try to refer to
> another variable defined in system.properties.
>
> This seems like a bug to me.
>
> I would also like to find out what the status is on the redesign of
> system.properties. I would very much like the possibility to add my
> specific variables outside of the Karaf installation. I already create a
> custom distribution but the variables need to be added on a per
> installation basis. The customer himself decides what convenience
> variables are needed and I don't want the customer to fiddle with the
> Karaf installation.
>
> The functionality I'm looking for is something like this: Somewhere in
> the Karaf configuration I would like to specify that Karaf should read
> variable definitions from a file (or list of files) that I specify. I
> can then separate my, installation specific, variables from the standard
> Karaf installation. I have brought this up before and was under the
> impression that something like this was in scope for Karaf 3 (or even
> earlier). What is the status of this kind of customisation?
>
> /Bengt
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com