Re: integration test, startup time for karaf 2.3.1
Do you already use the EagerSingleStagedReactorStrategy ? See https://ops4j1.jira.com/wiki/display/paxexam/Reactor+Strategies It does not help for the startup time but reduces the number of starts. Christian Am 14.06.2013 15:37 schrieb Marcos Mendez mar...@jitisoft.com: Hi, Maven only checks the version in the build, as after the first build, that zip is already in my local .m2. The time I'm quoting is the actual container (start method) startup time (after creating the exam system and container). That's what I'm trying to minimize. I did plan to look at the repos that I'm using, to limit them to the local only - as I know what I will be installing. But was wondering if there's anything else I can do. Regards, Marcos On Jun 14, 2013, at 12:44 AM, Andreas Pieber wrote: Do you reference the apache karaf artifact in your pom files? This is the only problem I can imagine making plain karaf tests so slow for you. If you dont enter the karaf distribution in your pom file as a dependency the test framework doesnt copy it into your .m2 directory and therefore freshly download it for each test. Kind regards, Andreas On Thu, Jun 13, 2013 at 10:36 PM, Marcos Mendez mar...@jitisoft.comwrote: Hi, I'm trying to improve the startup time for our integration tests. I'm using the vanilla maven distribution zip, the exam tooling, and cut down the featuresBoot to config. Is there anything else I can do to cut down the startup time? It's taking around 20-30s to start with no additional configuration. Any ideas? Regards, Marcos
Re: integration test, startup time for karaf 2.3.1
I don't think it will help. I think that Marcos' pom.xml doesn't contain the Karaf dependency/ and so it downloads and bootstraps for each test method. Regards JB On 06/17/2013 11:24 AM, Christian Schneider wrote: Do you already use the EagerSingleStagedReactorStrategy ? See https://ops4j1.jira.com/wiki/display/paxexam/Reactor+Strategies It does not help for the startup time but reduces the number of starts. Christian Am 14.06.2013 15:37 schrieb Marcos Mendez mar...@jitisoft.com mailto:mar...@jitisoft.com: Hi, Maven only checks the version in the build, as after the first build, that zip is already in my local .m2. The time I'm quoting is the actual container (start method) startup time (after creating the exam system and container). That's what I'm trying to minimize. I did plan to look at the repos that I'm using, to limit them to the local only - as I know what I will be installing. But was wondering if there's anything else I can do. Regards, Marcos On Jun 14, 2013, at 12:44 AM, Andreas Pieber wrote: Do you reference the apache karaf artifact in your pom files? This is the only problem I can imagine making plain karaf tests so slow for you. If you dont enter the karaf distribution in your pom file as a dependency the test framework doesnt copy it into your .m2 directory and therefore freshly download it for each test. Kind regards, Andreas On Thu, Jun 13, 2013 at 10:36 PM, Marcos Mendez mar...@jitisoft.com mailto:mar...@jitisoft.com wrote: Hi, I'm trying to improve the startup time for our integration tests. I'm using the vanilla maven distribution zip, the exam tooling, and cut down the featuresBoot to config. Is there anything else I can do to cut down the startup time? It's taking around 20-30s to start with no additional configuration. Any ideas? Regards, Marcos -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Cellar 3.0.0-SNAPSHOT
Will -p be added to 3.0.0 as well? Otherwise unit tests using 3.0.0 that create and connect to a child instance won't be able to in an integration test. Ryan -- View this message in context: http://karaf.922171.n3.nabble.com/Cellar-3-0-0-SNAPSHOT-tp4028863p4029056.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Cellar 3.0.0-SNAPSHOT
Hi Ryan, exactly, it's the plan. I gonna update 3.0.0 that way. Regards JB On 06/17/2013 04:56 PM, rkmoquin wrote: Will -p be added to 3.0.0 as well? Otherwise unit tests using 3.0.0 that create and connect to a child instance won't be able to in an integration test. Ryan -- View this message in context: http://karaf.922171.n3.nabble.com/Cellar-3-0-0-SNAPSHOT-tp4028863p4029056.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Cellar 3.0.0-SNAPSHOT
Ok, cool, I figured but just wanted to make sure. Is there an rough estimate on on that feature? Just trying to plan ahead :) Thanks! -- View this message in context: http://karaf.922171.n3.nabble.com/Cellar-3-0-0-SNAPSHOT-tp4028863p4029058.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Cellar 3.0.0-SNAPSHOT
Let say tonight (my time) ;) I reopen the Jira and work on that ;) Regards JB On 06/17/2013 05:12 PM, rkmoquin wrote: Ok, cool, I figured but just wanted to make sure. Is there an rough estimate on on that feature? Just trying to plan ahead :) Thanks! -- View this message in context: http://karaf.922171.n3.nabble.com/Cellar-3-0-0-SNAPSHOT-tp4028863p4029058.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Cellar 3.0.0-SNAPSHOT
By the way, I checked the Cellar itests and I saw an issue in the destroyCellarChild method. We properly uninstall the cellar feature using: System.err.println(executeCommand(admin:connect + name + features:uninstall cellar)); but it's not correct as features:uninstall and cellar are consider as two different arguments. We should use System.err.println(executeCommand(admin:connect + name + \features:uninstall cellar\)); for instance. I'm fixing issues like this in the itests. Regards JB On 06/17/2013 05:12 PM, rkmoquin wrote: Ok, cool, I figured but just wanted to make sure. Is there an rough estimate on on that feature? Just trying to plan ahead :) Thanks! -- View this message in context: http://karaf.922171.n3.nabble.com/Cellar-3-0-0-SNAPSHOT-tp4028863p4029058.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Client + 2 Blueprint Service
Hi,
I would like to deploy on OSGI platform (Karaf) two different versions (but
could be more) of an OSGI service (org.acme.common.HelloWorldService - v1
v2). For that purpose I have created 2 Blueprint XML config files, packaged
the bundles and deploy them on karaf
[ 57] [Active ] [Created ] [ 80] Acme :: OSGI :: Client (1.0.0)
[ 60] [Active ] [Created ] [ 80] Acme :: OSGI :: Commons :: v1
(1.0.0)
Here is an example of blueprint config for Commons V1
?xml version=1.0 encoding=UTF-8 standalone=no?
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:cm=
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0;
cm:property-placeholder id=property-placeholder
persistent-id=config.v1/
bean id=helloWorldService class=org.acme.common.HelloWorldServiceImpl
init-method=init destroy-method=destroy
property name=version value=${version}/
/bean
service ref=helloWorldService
interface=org.acme.common.HelloWorldService
ranking=100
service-properties
entry key=version value=v1/
/service-properties
/service
/blueprint
Now, a bundle, which is a client of a service will consume it.
?xml version=1.0 encoding=UTF-8 standalone=no?
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
bean id=helloWorldClient class=org.acme.client.HelloWorldClient
init-method=callService
property name=service ref=helloWorldService/
/bean
reference id=helloWorldService
interface=org.acme.common.HelloWorldService
filter=(version=v1)/
/blueprint
That works fine.
If now, I would like, that the client uses the latest version of the
service v2 (and not v1) when we have 2 OSGI Services deployed on OSGI
Registry, I must specifically specified that it must import the package
org.acme.common;version=2.0.
But when I use a version range to let the bundle to take the latest version
available, then I get this error
[ 57] [Active ] [Failure ] [ 80] Acme :: OSGI :: Client (1.0.0)
[ 60] [Active ] [Created ] [ 80] Acme :: OSGI :: Commons :: v1
(1.0.0)
[ 61] [Active ] [Created ] [ 80] Acme :: OSGI :: Commons :: v2
(2.0.0)
Caused by: java.lang.ClassCastException:
org.acme.common.HelloWorldServiceImpl cannot be cast to
org.acme.common.HelloWorldService
at Proxy93f66d24_52d9_49b4_9d6c_8c65ce3ef1f1.callService(Unknown Source)
at org.acme.client.HelloWorldClient.callService(HelloWorldClient.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_45]
Remark : Doing a refresh of the bundle client does not allow the bundle to
load the latest package version available.
karaf@root packages:exports 60
ID Packages
60 org.acme.common; version=1.0.0
karaf@root packages:exports 61
ID Packages
61 org.acme.common; version=2.0.0
karaf@root packages:imports 57
Acme :: OSGI :: Commons :: v1 (60): org.acme.common; version=1.0.0
Is there a workaround to allow a bundle which is a client of an OSGI
Service (= Proxy object) to use the bundle containing the latest package
version deployed ?
Regards,
--
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
