Re: OSGi spec R8 and Blueprint in Karaf
Hi Jan, While Blueprint was removed from the overall OSGi R8 Compendium spec document this doesn't mean the spec doesn't exist any more it's still part of the OSGi R7 Compendium spec: https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.blueprint.html Main reason why it was removed was that nobody was helping to maintain this specification and that as it was, the Blueprint spec contains some decisions that over time have turned out to not be ideal (for example the Service Damping that Blueprint has turned out to be counter productive in large systems). If someone starts maintaining Blueprint to fix its issues, it might come back into the set of OSGi specs in the future. Having said that, OSGi is not about implementing everything at once, but more aimed at 'implement just what you need'. Additionally, OSGi specs are versioned, and in many cases mixing specs implementation of R8 Compendium can perfectly well be combined with older specs implementations. So in short, if you need Blueprint you can just pick up an implementation that supports the existing R7 specs and you should be able to combine it with newer specs implementations from R8. If you need _improvements_ to Blueprint, then someone needs to jump in and start maintaining it: https://github.com/osgi/osgi (the OSGi spec process is now at Eclipse, that link should get you started). Best regards, David On Sun, 20 Mar 2022 at 16:10, Jan Fetyko wrote: > Dear Karaf team, > > I'm wondering if anybody has an idea what will happen to Blueprint support > in Karaf when it moves to support OSGi spec version 8, which as far as I > can tell, has the Blueprint spec removed. > > A related question is, why was that spec even removed ? There is no mention > of its removal anywhere that I can find, but it is for sure not there. > > Anybody have any insight or thoughts about the above concerns ? > > Thank you, > > Jan >
Re: [DISCUSS] Cave and Karaf 4
The Felix 2.x Bundle Repository is compliant with the OSGi Repository spec. What is it that makes it not useful? On 29 April 2015 at 16:51, Guillaume Nodet gno...@apache.org wrote: Currently, cave is using the old 1.6.4 bundle repository, so it does not support the repository spec at all. Unfortunately, even the 2.x branch of bundle repository is not really useful for what I listed above. 2015-04-29 17:31 GMT+02:00 David Bosschaert david.bosscha...@gmail.com: Sounds interesting! Does Cave implement the actual OSGi Repository spec? Cheers, David On 29 April 2015 at 16:18, Guillaume Nodet gno...@apache.org wrote: I've raised a JIRA issue for the integration of Cave and Karaf 4 (see KARAF-3712). I have the following things in mind to integrate Cave into Karaf 4. When I mean integrating, I mean two things : - ability to to use osgi repository from cave inside the karaf feature resolution process (karaf 4 already support external osgi repositories so we're simply missing a compliant repository server) - ability to use cave as a maven repository and not only an osgi repository (i.e. serve other kind of artifacts with a real maven layout) It would require the following things : - upgrade to CXF 3.1 - us the spec'ed xml instead of the custom bundle repository xml format (both internally and for external access) - provide support for accessing repositories as json based repository as read by karaf 4 (see JsonRepository class) - support for gzip encoding of the repository in the servlet (repositories do compress very well) - move the maven proxy support from karaf 4 to cave I think a good addition would be to provide each repository managed by cave as a Repository object instead of relying on the bundle repository Repository object which is an aggregation. I would also get rid of OBR since this is deprecated. We may also want to get rid of the felix bundle repository completely and rely on the felix repository and karat-features-core bundle internal classes. Another good improvement for 4.0 would be to make sure the repositories can be used with cellar using DOSGi. Using a simple servlet instead of a full war for the cave http servlet would trim down the dependencies a bit too with no real loss imho. I'm wiling to experiment a bit with these ideas ... Thoughts ?
Re: [DISCUSS] Cave and Karaf 4
Sounds interesting! Does Cave implement the actual OSGi Repository spec? Cheers, David On 29 April 2015 at 16:18, Guillaume Nodet gno...@apache.org wrote: I've raised a JIRA issue for the integration of Cave and Karaf 4 (see KARAF-3712). I have the following things in mind to integrate Cave into Karaf 4. When I mean integrating, I mean two things : - ability to to use osgi repository from cave inside the karaf feature resolution process (karaf 4 already support external osgi repositories so we're simply missing a compliant repository server) - ability to use cave as a maven repository and not only an osgi repository (i.e. serve other kind of artifacts with a real maven layout) It would require the following things : - upgrade to CXF 3.1 - us the spec'ed xml instead of the custom bundle repository xml format (both internally and for external access) - provide support for accessing repositories as json based repository as read by karaf 4 (see JsonRepository class) - support for gzip encoding of the repository in the servlet (repositories do compress very well) - move the maven proxy support from karaf 4 to cave I think a good addition would be to provide each repository managed by cave as a Repository object instead of relying on the bundle repository Repository object which is an aggregation. I would also get rid of OBR since this is deprecated. We may also want to get rid of the felix bundle repository completely and rely on the felix repository and karat-features-core bundle internal classes. Another good improvement for 4.0 would be to make sure the repositories can be used with cellar using DOSGi. Using a simple servlet instead of a full war for the cave http servlet would trim down the dependencies a bit too with no real loss imho. I'm wiling to experiment a bit with these ideas ... Thoughts ?
Re: [VOTE] Create/donate Apache Karaf Decanter subproject
+1 David On 16 October 2014 08:40, Roedl Lukas lukas.ro...@ait.ac.at wrote: +1 (non-binding) Best, Lukas
Re: [VOTE] Release Apache Karaf 4.0.0.M1 technology preview.
+1 David On 11 October 2014 22:10, Jamie G. jamie.goody...@gmail.com wrote: Hi, We have 327 issues resolved on our way towards Apache Karaf 4.0.0 GA release. This is a technology preview, as such there will be features and other functionality not yet implemented. Please refrain from using this particular RC in production. https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-4.0.0.M1-release.page Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1013/ Release git tags: 4.0.0.M1 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
Re: [VOTE] Release Apache Karaf 3.0.2
+1 David On 10 October 2014 20:34, Jamie G. jamie.goody...@gmail.com wrote: Hi, We resolved 215 issues in this release: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.2-release.page?view=markup Dependency changes can be reviewed here: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup (The website published table will be updated after vote) Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1012/ Git tag: karaf-3.0.2 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
Re: [VOTE] Release Apache Karaf 2.3.8
+1 David On 16 September 2014 09:23, Jean-Baptiste Onofré j...@nanthrax.net wrote: +1 (binding) Regards JB On 09/16/2014 09:56 AM, Jamie G. wrote: Hi, We resolved 9 issues in this release: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.8-release.page?view=markup Dependency changes can be reviewed here: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-2.3.x.page?revision=1613719view=markup Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1010/ Git tag: karaf-2.3.8 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [VOTE] Release Apache Karaf 2.3.7
+1 David On 3 September 2014 01:47, Jamie G. jamie.goody...@gmail.com wrote: Hi, We resolved 15 issues in this release: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.7-release.page?view=markup Dependency changes can be reviewed here: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-2.3.x.page?revision=1613719view=markup Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1009/ Git tag: karaf-2.3.7 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
Re: [VOTE] Release Apache Karaf version 2.3.4
+1 from me. David On 15 February 2014 02:09, Jamie G. jamie.goody...@gmail.com wrote: Hi, We resolved 116 issues in this release (web page will be published post RC promotion): https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.4-release.page Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-1000/ Repository: karaf Updated Tags: refs/tags/karaf-2.3.4 [created] 653d885f4 2.3.x Dependencies table: https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps- 2.3.x.page Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
Re: [PROPOSAL] Release Karaf 2.3.4 end of this week, 2.4.0 next week ?
+1 from me too! Cheers, David On 6 January 2014 15:28, Achim Nierbeck bcanh...@googlemail.com wrote: +1 2014/1/6 Jamie G. jamie.goody...@gmail.com +1 :) On Mon, Jan 6, 2014 at 6:23 AM, Claus Ibsen claus.ib...@gmail.com wrote: Sounds good. I would like to see releases of 2.x being picked up again. On Mon, Jan 6, 2014 at 10:34 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, I started to work on Jira for 2.3.4 and 2.4.0. As we released 2.3.3 in September, I think it's the good time to release a 2.3.4 maintenance release. WDYT ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen Make your Camel applications look hawt, try: http://hawt.io -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/
Re: [VOTE] Release Apache Karaf version 3.0.0
+1 from me. Good work guys. 1158 issues - wow! David On 21 December 2013 17:40, Jamie G. jamie.goody...@gmail.com wrote: Hi, We resolved 1158 issues in this release: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup Dependency changes can be reviewed here: http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup (The website published table will be updated after vote) Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-013/ Git tag: karaf-3.0.0 Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
Re: [ANN] Apache Karaf repository moved to git
This is great news! Thanks for the efforts here, JB! David On 17 December 2013 14:51, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, The Apache Karaf source repositories have moved to git. Read-only: https://git.apache.org/repos/asf/karaf.git https://github.com/apache/karaf.git Read-write (for committers): https://git-wip-us.apache.org/repos/asf/karaf.git The Apache Karaf website and KEYS file will remain in Subversion. I will move the old Subversion source repository to Attic and create a README file to inform of the move. I'm going to update the website and the documentation to refer git instead of Subversion. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
itests (trunk) on Mac osx (now with Java 7)
Hi all, I have updated to Java 7 on my Mac and am getting the errors below with the itests [1]. They work fine for me on Linux. Also note that all the other maven modules in karaf trunk test/pass fine for me. Anyone an idea? I'm using the following Java: $ java -version java version 1.7.0_45 Java(TM) SE Runtime Environment (build 1.7.0_45-b18) Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode) Thanks, David [1] All the itests fail as follows: java.util.ServiceConfigurationError: org.ops4j.pax.exam.TestContainerFactory: Provider org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory could not be instantiated: java.lang.IllegalStateException: Cannot select localhost. That usually not a good sign for networking.. at java.util.ServiceLoader.fail(ServiceLoader.java:224) at java.util.ServiceLoader.access$100(ServiceLoader.java:181) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:377) at java.util.ServiceLoader$1.next(ServiceLoader.java:445) at org.ops4j.pax.exam.spi.PaxExamRuntime.sanityCheck(PaxExamRuntime.java:172) at org.ops4j.pax.exam.spi.PaxExamRuntime.getTestContainerFactory(PaxExamRuntime.java:69) at org.ops4j.pax.exam.spi.reactors.ReactorManager.createsTestContainerFactory(ReactorManager.java:335) at org.ops4j.pax.exam.spi.reactors.ReactorManager.createReactor(ReactorManager.java:308) at org.ops4j.pax.exam.spi.reactors.ReactorManager.prepareReactor(ReactorManager.java:184) at org.ops4j.pax.exam.junit.impl.ProbeRunner.lt;initgt;(ProbeRunner.java:80) at org.ops4j.pax.exam.junit.PaxExam.createDelegate(PaxExam.java:82) at org.ops4j.pax.exam.junit.PaxExam.lt;initgt;(PaxExam.java:73) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) Caused by: java.lang.IllegalStateException: Cannot select localhost. That usually not a good sign for networking.. at org.ops4j.pax.exam.karaf.container.internal.RMIRegistry.lt;initgt;(RMIRegistry.java:51) at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainerFactory.lt;initgt;(KarafTestContainerFactory.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at java.lang.Class.newInstance(Class.java:374) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373) ... 31 more
StandardFeaturesTest.installSSHFeature() problem (trunk)
Hi all, When I'm running the following test on trunk (which is part of the itests) StandardFeaturesTest. installSSHFeature() I get an error message on the console and the ssh functionality is not actually available. What's worrying is that the test actually passes, I would have thought that it should fail... Anyway, I'm looking for similar functionality for another test (I want to install the 'ssh' feature for that itest) and am wondering what is needed to get the 'ssh' feature to properly install. I think the key error here is: Caused by: java.lang.NoClassDefFoundError: org/apache/mina/core/service/IoHandler Anyone an idea? Thanks, David The full log is: installSSHFeature(org.apache.karaf.itests.features.StandardFeaturesTest) 15:50:49,928 | INFO | apache.karaf.features.internal.FeaturesServiceImpl | Installing feature ssh 3.0.0-SNAPSHOT 15:50:50,082 | INFO | org.apache.sshd.common.util.SecurityUtils | BouncyCastle not registered, using the default JCE provider 15:50:50,346 | WARN | org.apache.aries.blueprint.container.BeanRecipe | Object to be destroyed is not an instance of UnwrapperedBeanHolder, type: null 15:50:50,349 | ERROR | e.aries.blueprint.container.BlueprintContainerImpl | Unable to start blueprint container for bundle org.apache.karaf.shell.ssh org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to initialize bean sshServerFactory at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787) at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_65] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_65] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245) at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183) at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:681) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:378) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269) at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276) at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245) at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422) at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103) at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403) at org.apache.felix.framework.Felix.startBundle(Felix.java:2092) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942) at org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:469) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:428) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:363) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:352) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:335) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:313) at Proxy90cbc3f4_536f_489a_a10b_79f29a0e4f07.installFeature(Unknown Source) at org.apache.karaf.itests.KarafTestSupport.installAssertAndUninstallFeature(KarafTestSupport.java:395) at org.apache.karaf.itests.features.StandardFeaturesTest.installSSHFeature(StandardFeaturesTest.java:29) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_65] at
Re: StandardFeaturesTest.installSSHFeature() problem (trunk)
Java 6 is no more support for Karaf 3.0.0 Oh, really? I wasn't aware of that :) I'm still using Java 6 on my mac because it sometimes catches out issues that you otherwise don't find. Ok - I'll move on to Java 7. Thanks, David On 3 December 2013 16:42, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi David, Java 6 is no more support for Karaf 3.0.0, you have to use Java 7 (Java 6 is EOL now). I guess that you run with Java 6. Regards JB On 12/03/2013 04:58 PM, David Bosschaert wrote: Hi all, When I'm running the following test on trunk (which is part of the itests) StandardFeaturesTest. installSSHFeature() I get an error message on the console and the ssh functionality is not actually available. What's worrying is that the test actually passes, I would have thought that it should fail... Anyway, I'm looking for similar functionality for another test (I want to install the 'ssh' feature for that itest) and am wondering what is needed to get the 'ssh' feature to properly install. I think the key error here is: Caused by: java.lang.NoClassDefFoundError: org/apache/mina/core/service/IoHandler Anyone an idea? Thanks, David The full log is: installSSHFeature(org.apache.karaf.itests.features.StandardFeaturesTest) 15:50:49,928 | INFO | apache.karaf.features.internal.FeaturesServiceImpl | Installing feature ssh 3.0.0-SNAPSHOT 15:50:50,082 | INFO | org.apache.sshd.common.util.SecurityUtils | BouncyCastle not registered, using the default JCE provider 15:50:50,346 | WARN | org.apache.aries.blueprint.container.BeanRecipe | Object to be destroyed is not an instance of UnwrapperedBeanHolder, type: null 15:50:50,349 | ERROR | e.aries.blueprint.container.BlueprintContainerImpl | Unable to start blueprint container for bundle org.apache.karaf.shell.ssh org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to initialize bean sshServerFactory at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:714) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824) at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787) at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_65] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_65] at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88) at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245) at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183) at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:681) at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:378) at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269) at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276) at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245) at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463) at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422) at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103) at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403) at org.apache.felix.framework.Felix.startBundle(Felix.java:2092) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942) at org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:469) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:428) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:363) at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:352
Re: Toward Karaf 3.0.0
Great, thanks JB! David On 24 November 2013 17:26, Jean-Baptiste Onofré j...@nanthrax.net wrote: As said this morning, I've enabled the JMX RBAC by default on the root instance. Now, I'm updating to the same behaviour for: - instance started using the wrapper - instances managed by the instance script or the instance:* commands/MBeans It should be done tonight. Regards JB On 11/24/2013 07:04 AM, Jean-Baptiste Onofré wrote: Hi David, Now that KARAF-2513 is fixed, I'm OK to enable it by default. I gonna do that, and I will add the documentation to explain how to disable it (if an user really wants to). Thanks, Regards JB On 11/23/2013 11:40 PM, David Bosschaert wrote: Hi all, I would like to come to a conclusion before we release 3.0.0 on whether we want JMX Role-based Access Control enabled by default or not. Right now it's not enabled and you have to set the KARAF_ACL environment variable for this. While I have no problem with adding a command line flag to control this I think it would be nice if it was enabled by default. I realize that until recently KARAF-2513 was standing in the way of that, but this should now be fixed. I'm personally not aware of any other issues with it... Shell commands (and OSGi Services in general) already have RBAC enabled by default and I think they should probably line up. However if people disagree with having this enabled, then I could live with that, but in that case I think it would be good to also disable the shell command/osgi service RBAC switched on/off via the same mechanism. Thoughts anyone? David On 21 November 2013 12:50, Jean-Baptiste Onofré j...@nanthrax.net wrote: Thanks David. Let me test it again. I will get back to you soon. Regards JB On 11/21/2013 01:32 PM, David Bosschaert wrote: Hi JB, I fixed the issue with Camel MBeans (KARAF-2513): the JMX RBAC code wasnt properly unwrapping exceptions before throwing them up to the caller. We disabled JMX RBAC by default as it breaks projects MBeans (like Camel, CXF, etc). You also mention 'CXF' and 'etc'. Are there other actual bugs or use cases that don't work? If so please let me know and I'll look into them Cheers, David On 20 November 2013 15:04, Jean-Baptiste Onofré j...@nanthrax.net wrote: Awesome, thanks a lot David ! Regards JB On 11/20/2013 04:02 PM, David Bosschaert wrote: On 20 November 2013 14:55, Jean-Baptiste Onofré j...@nanthrax.net wrote: I checked in bin/karaf and bin/karaf.bat, and actually, in both, JMX RBAC are disabled by default (the test is just different on Windows and Unix). Yep, my bad for not see that one is doing '==' where the other does '!='. The problem with Camel is captured in https://issues.apache.org/jira/browse/KARAF-2513 I'm going to have a look to see whether I can address that. I'd really like to see the JMX RBAC stuff working in all contexts :) Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Toward Karaf 3.0.0
Hi all, I would like to come to a conclusion before we release 3.0.0 on whether we want JMX Role-based Access Control enabled by default or not. Right now it's not enabled and you have to set the KARAF_ACL environment variable for this. While I have no problem with adding a command line flag to control this I think it would be nice if it was enabled by default. I realize that until recently KARAF-2513 was standing in the way of that, but this should now be fixed. I'm personally not aware of any other issues with it... Shell commands (and OSGi Services in general) already have RBAC enabled by default and I think they should probably line up. However if people disagree with having this enabled, then I could live with that, but in that case I think it would be good to also disable the shell command/osgi service RBAC switched on/off via the same mechanism. Thoughts anyone? David On 21 November 2013 12:50, Jean-Baptiste Onofré j...@nanthrax.net wrote: Thanks David. Let me test it again. I will get back to you soon. Regards JB On 11/21/2013 01:32 PM, David Bosschaert wrote: Hi JB, I fixed the issue with Camel MBeans (KARAF-2513): the JMX RBAC code wasnt properly unwrapping exceptions before throwing them up to the caller. We disabled JMX RBAC by default as it breaks projects MBeans (like Camel, CXF, etc). You also mention 'CXF' and 'etc'. Are there other actual bugs or use cases that don't work? If so please let me know and I'll look into them Cheers, David On 20 November 2013 15:04, Jean-Baptiste Onofré j...@nanthrax.net wrote: Awesome, thanks a lot David ! Regards JB On 11/20/2013 04:02 PM, David Bosschaert wrote: On 20 November 2013 14:55, Jean-Baptiste Onofré j...@nanthrax.net wrote: I checked in bin/karaf and bin/karaf.bat, and actually, in both, JMX RBAC are disabled by default (the test is just different on Windows and Unix). Yep, my bad for not see that one is doing '==' where the other does '!='. The problem with Camel is captured in https://issues.apache.org/jira/browse/KARAF-2513 I'm going to have a look to see whether I can address that. I'd really like to see the JMX RBAC stuff working in all contexts :) Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Board Report for December, 2013
+1 David On 22 November 2013 12:58, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, I prepared the Board Report for December, 2013: https://cwiki.apache.org/confluence/display/KARAF/Board+Reports Please review it. I will update the report with the latest numbers end of November. Thanks, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Toward Karaf 3.0.0
Hi JB, I fixed the issue with Camel MBeans (KARAF-2513): the JMX RBAC code wasnt properly unwrapping exceptions before throwing them up to the caller. We disabled JMX RBAC by default as it breaks projects MBeans (like Camel, CXF, etc). You also mention 'CXF' and 'etc'. Are there other actual bugs or use cases that don't work? If so please let me know and I'll look into them Cheers, David On 20 November 2013 15:04, Jean-Baptiste Onofré j...@nanthrax.net wrote: Awesome, thanks a lot David ! Regards JB On 11/20/2013 04:02 PM, David Bosschaert wrote: On 20 November 2013 14:55, Jean-Baptiste Onofré j...@nanthrax.net wrote: I checked in bin/karaf and bin/karaf.bat, and actually, in both, JMX RBAC are disabled by default (the test is just different on Windows and Unix). Yep, my bad for not see that one is doing '==' where the other does '!='. The problem with Camel is captured in https://issues.apache.org/jira/browse/KARAF-2513 I'm going to have a look to see whether I can address that. I'd really like to see the JMX RBAC stuff working in all contexts :) Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Toward Karaf 3.0.0
I noticed that to address this an environment variable was introduced for the scripts that can be set to enable/disable JMX RBAC. However when looking at it I noticed that the default is different on Windows and Unix. Currently, on Unix the default is to have JMX RBAC enabled (when the $KARAF_ACL is not set), however on Windows the default is to have JMX RBAC disabled (when %KARAF_ACL% is not set). Any reason why they are different? And what do we want the default to be? I would personally say that it's better to have the more secure default, which is to have JMX RBAC enabled. Best regards, David On 22 October 2013 01:28, Jean-Baptiste Onofré j...@nanthrax.net wrote: Thanks for your comment David, it's what I suspected. I will at least update the documentation to explain this point to the users. Regards JB On 10/21/2013 01:56 PM, David Bosschaert wrote: I left a comment on KARAF-2506 With the new RBAC for JMX you need to be logged in as a user which needs some roles in order to get access to anything. So if you simply attach via JConsole to the local process it will show everything as unavailable. When you log in using the Remote Process mechanism from JConsole (i.e. via a URL like this: service:jmx:rmi://localhost:4/jndi/rmi://localhost:1099/karaf-root) and provide username and password, it should all work... Cheers, David On 21 October 2013 12:40, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, just a quick update about that. I gonna commit the Aries Blueprint CM update: I tested locally, it looks good to me. One blocking issue should be fixed: https://issues.apache.org/jira/browse/KARAF-2506 We can not release a Karaf version with a JMX layer that doesn't really work. I gonna take a look on that today. Regards JB On 10/08/2013 04:41 PM, Jean-Baptiste Onofré wrote: Hi all, Thanks to Dan, we got the Aries release required for Karaf 3.0.0. I'm upgrading on Karaf trunk. I'm working on the latest mandatory improvement (KARAF-2496) now. So, today, I will: - commit both blueprint upgrade and KARAF-2496 - update Jira to add 3.0.1 version - review the Jira and move to 3.0.1 I discussed with Jamie this morning, he's ready to cut off the 3.0.0 release. I propose to prepare the release and vote for next Thursday (it gives some time to latest fixes and tests tomorrow). WDYT ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Toward Karaf 3.0.0
On 20 November 2013 14:55, Jean-Baptiste Onofré j...@nanthrax.net wrote: I checked in bin/karaf and bin/karaf.bat, and actually, in both, JMX RBAC are disabled by default (the test is just different on Windows and Unix). Yep, my bad for not see that one is doing '==' where the other does '!='. The problem with Camel is captured in https://issues.apache.org/jira/browse/KARAF-2513 I'm going to have a look to see whether I can address that. I'd really like to see the JMX RBAC stuff working in all contexts :) Cheers, David
Re: Versioning of command apis
+1 on getting a clean API separated out from implementation and helper classes. Once that API is there we can nicely apply semantic versioning on it, which should make life a lot easier for people implementing commands. Just FYI - the bndtools.org project has recently made a lot of progress in providing tools that tell you when you need to update your versions to comply with OSGi semantic versioning. Although it's not been used in anger in under Maven yet, Maven support has been in the works for a while and I think it would be good if we could start using it. Just my 2c, David On 14 November 2013 09:21, Christian Schneider ch...@die-schneider.net wrote: As you all know we had and still some compatibility problems with bundles that implement commands externally from karaf. CXF and Camel work now but ActiveMQ still does not work with karaf 3. There are two kinds of problems that appear with the switch to karaf 3. 1. We moved the classes from org.apache.felix.gogo.commands and org.apache.felix.gogo.commands.basic to org.apache.karaf.shell.commands and org.apache.karaf.shell.commands.basic. 2. The org.apache.karaf.shell.console package and subpackages are exported as version 3.0.0 now which is by default incompatible with auto generated import ranges. For problem 1 we created deprecated old classes at the old place which allows people to migrate. For problem 2 all external command bundles need to increase their import range to include 3.x. The problem will reappear with version 4. I just discussed with Achim on irc what to do and we agreed that for problem 2 a much better solution would be to introduce a versioning on package level. This requires a lot more care and effort than what we now do though. So my question is. Should we start versioning at least this api on package level and what rules should be in place to make sure it works? When I look into the packages from shell.console I think that these are not real api packages as of now. They contain some classes that rather qualify as implementation like AbstractAction and DefaultActionPreparator as they contain much code. At the moment these packages can not be split easily from the minimal api we need to provide. So I am not sure if we are already at a stage were we can do good api versioning. So I wonder if we perhaps keep the api mostly unchanged for karaf 3 and do a bigger redesign of the command apis for karaf 4. If we decide to go this way it would be more consistent to revert the move of the classes described in problem 1. This would then make sure that users of karaf commands only need to do the change once. For problem 2 we might simply define one fixed export version for command apis in karaf 3.x like (2.3.0). This version would be compatible to old external commands and we could use the same version for karaf 2.x starting with 2.4. So we would stay very compatible for now and spare the real changes for karaf 4. We could start these changes in a kind of preview api in karaf 3.x and formalize it at some point which would then become the karaf 4 command api. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [ANN] Learning Apache Karaf is now available!
Yes, congratulations, Jamie! David On 1 November 2013 18:48, Christian Posta christian.po...@gmail.com wrote: Congrats!! Just bought it :) On Fri, Nov 1, 2013 at 4:55 AM, Jamie G. jamie.goody...@gmail.com wrote: Hi All, We'd like to take this opportunity to notify the Apache Karaf community of a new learning resource becoming available - Packt Publishing's Learning Apache Karaf. Johan, Heath, and I began working on this project this past summer after being approached by Packt to submit an outline for how we see Apache Karaf being introduced to developers and administrators. Several months later we arrived at our final draft after obtaining feedback from many members of the Karaf community. In our humble opinion, this book contains the distilled experiences of using Apache Karaf that you need to know. We hope that you find our approach to be concise, fast paced, and get your Karaf instance up and running as quickly as possible. Reviewing our book's content you'll o Install your first Apache Karaf instance o Learn to command and control the runtime o Explore system configuration tuning o Delve into Karaf’s provisioning mechanisms o Understand application deployment through practical examples o Improve your Karaf deployment to production-ready status o Discover Apache Karaf Cellar, and o Harness Karaf’s features with our sample final project For more information, please visit the book's site: http://www.packtpub.com/learning-apache-karaf/book -- Christian Posta http://www.christianposta.com/blog twitter: @christianposta
Re: Build failure on Karaf trunk...
Hi Christian, Yes, it was a weird one - in any case Dan fixed it so at least I'm all good now :) Cheers, David On 26 October 2013 06:47, Christian Schneider ch...@die-schneider.net wrote: Hi David, sorry .. did not see the mail. I use maven 3.0.4 and it works fine for me. The jenkins build fails though. Christian On 25.10.2013 16:45, David Bosschaert wrote: Hi all, When I run 'mvn install' on Karaf trunk it fails. (OSX, Java 1.6) See below. It was fine yesterday - so I suspect it's one of the commits done today. cschneider, since you are the only one who did commits today, are you seeing this too? Cheers, David [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2:14.440s [INFO] Finished at: Fri Oct 25 15:36:51 IST 2013 [INFO] Final Memory: 83M/163M [INFO] [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-create-kar (package) on project framework: Execution package of goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-create-kar failed: An API incompatibility was encountered while executing org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-create-kar: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLineAsCallable(Lorg/codehaus/plexus/util/cli/Commandline;Ljava/io/InputStream;Lorg/codehaus/plexus/util/cli/StreamConsumer;Lorg/codehaus/plexus/util/cli/StreamConsumer;I)Lorg/codehaus/plexus/util/cli/CommandLineCallable; [ERROR] - [ERROR] realm = pluginorg.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/Users/david/checkouts/karaf/tooling/karaf-maven-plugin/target/karaf-maven-plugin-3.0.0-SNAPSHOT.jar [ERROR] urls[1] = file:/Users/david/.m2/repository/org/sonatype/sisu/sisu-inject-bean/2.1.1/sisu-inject-bean-2.1.1.jar [ERROR] urls[2] = file:/Users/david/.m2/repository/org/sonatype/sisu/sisu-guice/2.9.4/sisu-guice-2.9.4-no_aop.jar [ERROR] urls[3] = file:/Users/david/.m2/repository/org/sonatype/aether/aether-util/1.11/aether-util-1.11.jar [ERROR] urls[4] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar [ERROR] urls[5] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar [ERROR] urls[6] = file:/Users/david/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar [ERROR] urls[7] = file:/Users/david/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar [ERROR] urls[8] = file:/Users/david/.m2/repository/org/slf4j/slf4j-jdk14/1.7.5/slf4j-jdk14-1.7.5.jar [ERROR] urls[9] = file:/Users/david/.m2/repository/org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar [ERROR] urls[10] = file:/Users/david/.m2/repository/org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar [ERROR] urls[11] = file:/Users/david/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [ERROR] urls[12] = file:/Users/david/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar [ERROR] urls[13] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.10/plexus-utils-1.5.10.jar [ERROR] urls[14] = file:/Users/david/.m2/repository/org/apache/felix/maven-bundle-plugin/2.4.0/maven-bundle-plugin-2.4.0.jar [ERROR] urls[15] = file:/Users/david/.m2/repository/biz/aQute/bnd/bndlib/2.1.0/bndlib-2.1.0.jar [ERROR] urls[16] = file:/Users/david/.m2/repository/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.jar [ERROR] urls[17] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-archiver/2.1/plexus-archiver-2.1.jar [ERROR] urls[18] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-io/2.0.2/plexus-io-2.0.2.jar [ERROR] urls[19] = file:/Users/david/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.1/maven-dependency-tree-2.1.jar [ERROR] urls[20] = file:/Users/david/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar [ERROR] urls[21] = file:/Users/david/.m2/repository/org/apache/felix/org.apache.felix.fileinstall/3.2.6/org.apache.felix.fileinstall-3.2.6.jar [ERROR] urls[22] = file:/Users/david/checkouts/karaf/features/core/target/org.apache.karaf.features.core-3.0.0-SNAPSHOT.jar [ERROR] urls[23] = file:/Users/david/.m2/repository/org/ops4j/pax/url/pax-url-wrap/1.6.0/pax-url-wrap-1.6.0.jar [ERROR] urls[24] = file:/Users/david/.m2/repository/org/ops4j/base/ops4j-base-net/1.4.0/ops4j-base-net-1.4.0.jar [ERROR] urls[25] = file:/Users
Build failure on Karaf trunk...
Hi all, When I run 'mvn install' on Karaf trunk it fails. (OSX, Java 1.6) See below. It was fine yesterday - so I suspect it's one of the commits done today. cschneider, since you are the only one who did commits today, are you seeing this too? Cheers, David [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2:14.440s [INFO] Finished at: Fri Oct 25 15:36:51 IST 2013 [INFO] Final Memory: 83M/163M [INFO] [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-create-kar (package) on project framework: Execution package of goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-create-kar failed: An API incompatibility was encountered while executing org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-create-kar: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLineAsCallable(Lorg/codehaus/plexus/util/cli/Commandline;Ljava/io/InputStream;Lorg/codehaus/plexus/util/cli/StreamConsumer;Lorg/codehaus/plexus/util/cli/StreamConsumer;I)Lorg/codehaus/plexus/util/cli/CommandLineCallable; [ERROR] - [ERROR] realm = pluginorg.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/Users/david/checkouts/karaf/tooling/karaf-maven-plugin/target/karaf-maven-plugin-3.0.0-SNAPSHOT.jar [ERROR] urls[1] = file:/Users/david/.m2/repository/org/sonatype/sisu/sisu-inject-bean/2.1.1/sisu-inject-bean-2.1.1.jar [ERROR] urls[2] = file:/Users/david/.m2/repository/org/sonatype/sisu/sisu-guice/2.9.4/sisu-guice-2.9.4-no_aop.jar [ERROR] urls[3] = file:/Users/david/.m2/repository/org/sonatype/aether/aether-util/1.11/aether-util-1.11.jar [ERROR] urls[4] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar [ERROR] urls[5] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar [ERROR] urls[6] = file:/Users/david/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar [ERROR] urls[7] = file:/Users/david/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar [ERROR] urls[8] = file:/Users/david/.m2/repository/org/slf4j/slf4j-jdk14/1.7.5/slf4j-jdk14-1.7.5.jar [ERROR] urls[9] = file:/Users/david/.m2/repository/org/slf4j/slf4j-api/1.7.5/slf4j-api-1.7.5.jar [ERROR] urls[10] = file:/Users/david/.m2/repository/org/apache/maven/shared/maven-filtering/1.0-beta-4/maven-filtering-1.0-beta-4.jar [ERROR] urls[11] = file:/Users/david/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [ERROR] urls[12] = file:/Users/david/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.4/plexus-build-api-0.0.4.jar [ERROR] urls[13] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.10/plexus-utils-1.5.10.jar [ERROR] urls[14] = file:/Users/david/.m2/repository/org/apache/felix/maven-bundle-plugin/2.4.0/maven-bundle-plugin-2.4.0.jar [ERROR] urls[15] = file:/Users/david/.m2/repository/biz/aQute/bnd/bndlib/2.1.0/bndlib-2.1.0.jar [ERROR] urls[16] = file:/Users/david/.m2/repository/org/apache/maven/maven-archiver/2.5/maven-archiver-2.5.jar [ERROR] urls[17] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-archiver/2.1/plexus-archiver-2.1.jar [ERROR] urls[18] = file:/Users/david/.m2/repository/org/codehaus/plexus/plexus-io/2.0.2/plexus-io-2.0.2.jar [ERROR] urls[19] = file:/Users/david/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.1/maven-dependency-tree-2.1.jar [ERROR] urls[20] = file:/Users/david/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar [ERROR] urls[21] = file:/Users/david/.m2/repository/org/apache/felix/org.apache.felix.fileinstall/3.2.6/org.apache.felix.fileinstall-3.2.6.jar [ERROR] urls[22] = file:/Users/david/checkouts/karaf/features/core/target/org.apache.karaf.features.core-3.0.0-SNAPSHOT.jar [ERROR] urls[23] = file:/Users/david/.m2/repository/org/ops4j/pax/url/pax-url-wrap/1.6.0/pax-url-wrap-1.6.0.jar [ERROR] urls[24] = file:/Users/david/.m2/repository/org/ops4j/base/ops4j-base-net/1.4.0/ops4j-base-net-1.4.0.jar [ERROR] urls[25] = file:/Users/david/.m2/repository/org/ops4j/base/ops4j-base-lang/1.4.0/ops4j-base-lang-1.4.0.jar [ERROR] urls[26] = file:/Users/david/.m2/repository/org/ops4j/base/ops4j-base-monitors/1.4.0/ops4j-base-monitors-1.4.0.jar [ERROR] urls[27] = file:/Users/david/.m2/repository/org/ops4j/pax/swissbox/pax-swissbox-bnd/1.7.0/pax-swissbox-bnd-1.7.0.jar [ERROR] urls[28] = file:/Users/david/.m2/repository/org/ops4j/pax/url/pax-url-commons/1.6.0/pax-url-commons-1.6.0.jar [ERROR] urls[29] =
Re: Build failure on Karaf trunk...
I was actually using the default mvn install on my system which is 3.0.3. I just tried with 3.1.1 which gives me a slightly similar error (below). What Maven version should work? Cheers, David The error with maven 3.1.1: [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor (compile) on project framework: Execution compile of goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor failed: Unable to load the mojo 'features-generate-descriptor' (or one of its required components) from the plugin 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT': com.google.inject.ProvisionException: Guice provision errors: [ERROR] [ERROR] 1) No implementation for org.sonatype.aether.RepositorySystem was bound. [ERROR] while locating org.apache.karaf.tooling.features.GenerateDescriptorMojo [ERROR] at ClassRealm[pluginorg.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT, parent: sun.misc.Launcher$AppClassLoader@7987aeca] [ERROR] while locating org.apache.maven.plugin.Mojo annotated with @com.google.inject.name.Named(value=org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor) [ERROR] [ERROR] 1 error [ERROR] role: org.apache.maven.plugin.Mojo [ERROR] roleHint: org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor On 25 October 2013 16:27, nseb seb_nicoul...@hotmail.com wrote: You use maven 3.1.0 ? -- View this message in context: http://karaf.922171.n3.nabble.com/Build-failure-on-Karaf-trunk-tp4030054p4030055.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Build failure on Karaf trunk...
Hmmm... I just tried mvn 3.0.5 on both OSX as well as on a fresh Linux (Fedora) machine. Linux passes OSX fails... Time to whack the .m2 directory ... On 25 October 2013 16:59, Andreas Pieber anpie...@gmail.com wrote: 3.1.x does not work by now. Since the karaf plugin does not use the abstraction layer this terribly fails with the new maven version -- 3.0.x should work Kind regards, Andreas On Fri, Oct 25, 2013 at 5:37 PM, David Bosschaert david.bosscha...@gmail.com wrote: I was actually using the default mvn install on my system which is 3.0.3. I just tried with 3.1.1 which gives me a slightly similar error (below). What Maven version should work? Cheers, David The error with maven 3.1.1: [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor (compile) on project framework: Execution compile of goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor failed: Unable to load the mojo 'features-generate-descriptor' (or one of its required components) from the plugin 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT': com.google.inject.ProvisionException: Guice provision errors: [ERROR] [ERROR] 1) No implementation for org.sonatype.aether.RepositorySystem was bound. [ERROR] while locating org.apache.karaf.tooling.features.GenerateDescriptorMojo [ERROR] at ClassRealm[pluginorg.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT, parent: sun.misc.Launcher$AppClassLoader@7987aeca] [ERROR] while locating org.apache.maven.plugin.Mojo annotated with @com.google.inject.name.Named(value=org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor) [ERROR] [ERROR] 1 error [ERROR] role: org.apache.maven.plugin.Mojo [ERROR] roleHint: org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor On 25 October 2013 16:27, nseb seb_nicoul...@hotmail.com wrote: You use maven 3.1.0 ? -- View this message in context: http://karaf.922171.n3.nabble.com/Build-failure-on-Karaf-trunk-tp4030054p4030055.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Build failure on Karaf trunk...
Just rebuilt using a fresh new .m2 on OSX, but am still getting the same error. Although the NoSuchMethodError reports being on org.codehaus.plexus.util.cli.CommandLineUtils I wonder could it have something to do that I'm using Java 1.6 on OSX? My successful build on Linux was with 1.7... Cheers, David On 25 October 2013 17:06, David Bosschaert david.bosscha...@gmail.com wrote: Hmmm... I just tried mvn 3.0.5 on both OSX as well as on a fresh Linux (Fedora) machine. Linux passes OSX fails... Time to whack the .m2 directory ... On 25 October 2013 16:59, Andreas Pieber anpie...@gmail.com wrote: 3.1.x does not work by now. Since the karaf plugin does not use the abstraction layer this terribly fails with the new maven version -- 3.0.x should work Kind regards, Andreas On Fri, Oct 25, 2013 at 5:37 PM, David Bosschaert david.bosscha...@gmail.com wrote: I was actually using the default mvn install on my system which is 3.0.3. I just tried with 3.1.1 which gives me a slightly similar error (below). What Maven version should work? Cheers, David The error with maven 3.1.1: [ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor (compile) on project framework: Execution compile of goal org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor failed: Unable to load the mojo 'features-generate-descriptor' (or one of its required components) from the plugin 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT': com.google.inject.ProvisionException: Guice provision errors: [ERROR] [ERROR] 1) No implementation for org.sonatype.aether.RepositorySystem was bound. [ERROR] while locating org.apache.karaf.tooling.features.GenerateDescriptorMojo [ERROR] at ClassRealm[pluginorg.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT, parent: sun.misc.Launcher$AppClassLoader@7987aeca] [ERROR] while locating org.apache.maven.plugin.Mojo annotated with @com.google.inject.name.Named(value=org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor) [ERROR] [ERROR] 1 error [ERROR] role: org.apache.maven.plugin.Mojo [ERROR] roleHint: org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor On 25 October 2013 16:27, nseb seb_nicoul...@hotmail.com wrote: You use maven 3.1.0 ? -- View this message in context: http://karaf.922171.n3.nabble.com/Build-failure-on-Karaf-trunk-tp4030054p4030055.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: Build failure on Karaf trunk...
JB Wrote: Anyway, I'm not sure the problem is in Karaf, as the error comes from plexus. Possibly - although I do see a the Karaf Kar Mojo in the stacktrace. It only started appearing today on the Karaf trunk. I had my checkout previously up-to-date to Oct 24 and all was fine then (on OSX with JDK 1.6 and Maven 3.0.3)... ja...@carmanconsulting.com wrote: Stack trace? Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLineAsCallable(Lorg/codehaus/plexus/util/cli/Commandline;Ljava/io/InputStream;Lorg/codehaus/plexus/util/cli/StreamConsumer;Lorg/codehaus/plexus/util/cli/StreamConsumer;I)Lorg/codehaus/plexus/util/cli/CommandLineCallable; at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributesByPath(PlexusIoResourceAttributeUtils.java:247) at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributes(PlexusIoResourceAttributeUtils.java:172) at org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:159) at org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:404) at org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:316) at org.apache.karaf.tooling.features.CreateKarMojo.createArchive(CreateKarMojo.java:224) at org.apache.karaf.tooling.features.CreateKarMojo.execute(CreateKarMojo.java:139) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 20 more
Re: Build failure on Karaf trunk...
Excellent - many thanks, Dan. I can confirm that it works :) Have a great weekend, David On 25 October 2013 19:00, Daniel Kulp dk...@apache.org wrote: David, I was able to reproduce this. Filed a patch: https://issues.apache.org/jira/browse/KARAF-2530 Dan On Oct 25, 2013, at 1:48 PM, David Bosschaert david.bosscha...@gmail.com wrote: JB Wrote: Anyway, I'm not sure the problem is in Karaf, as the error comes from plexus. Possibly - although I do see a the Karaf Kar Mojo in the stacktrace. It only started appearing today on the Karaf trunk. I had my checkout previously up-to-date to Oct 24 and all was fine then (on OSX with JDK 1.6 and Maven 3.0.3)... ja...@carmanconsulting.com wrote: Stack trace? Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLineAsCallable(Lorg/codehaus/plexus/util/cli/Commandline;Ljava/io/InputStream;Lorg/codehaus/plexus/util/cli/StreamConsumer;Lorg/codehaus/plexus/util/cli/StreamConsumer;I)Lorg/codehaus/plexus/util/cli/CommandLineCallable; at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributesByPath(PlexusIoResourceAttributeUtils.java:247) at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributes(PlexusIoResourceAttributeUtils.java:172) at org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:159) at org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:404) at org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:316) at org.apache.karaf.tooling.features.CreateKarMojo.createArchive(CreateKarMojo.java:224) at org.apache.karaf.tooling.features.CreateKarMojo.execute(CreateKarMojo.java:139) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 20 more -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Some thoughts around adding security for Karaf Shell Commands
Thanks again JB for reviewing and applying the commits. I have written a blog article about how it all works here: http://coderthoughts.blogspot.com/2013/10/role-based-access-control-for-karaf.html Best regards, David On 8 October 2013 16:50, Jean-Baptiste Onofré j...@nanthrax.net wrote: Awesome, thanks a lot David. I will review it tomorrow morning. Regards JB On 10/08/2013 05:44 PM, David Bosschaert wrote: Hi all, I have the pull request for KARAF-2455 (role-based security for OSGi Services) and KARAF-2442 (role-based security for Karaf Shell Commands) ready. Since KARAF-2442 builds on top of KARAF-2455 (thanks Christian for suggesting this originally) I included both in a single pull requests as two separate commits: https://github.com/apache/karaf/pull/22 One note - I have included lots of unit tests (generally 95% coverage for any of the code I touched) but am also planning to add some system tests. However I'd like to add those system tests separately later. Feedback appreciated, David On 19 September 2013 11:22, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi David, awesome, thanks for the update. I just started to review the patches. I will apply tonight or tomorrow. Thanks again, Regards JB On 09/19/2013 11:56 AM, David Bosschaert wrote: Hi all, Just a little status update on this... I have since implemented most of KARAF-2455 (role-based security for OSGi Services) and KARAF-2442 (role-based security for Karaf Shell Commands). They build on top of what I did for KARAF-2434 and KARAF-2435. Once those are merge I can rebase my implementation on trunk and will provide patches to apply... Cheers, David On 26 August 2013 10:22, Jean-Baptiste Onofré j...@nanthrax.net wrote: Thanks David, it makes sense. Regards JB On 08/26/2013 11:16 AM, David Bosschaert wrote: Since I think the general consensus here is that it would be good to have a general security mechanism for OSGi services I have created a JIRA for that (KARAF-2455) and noted that role-based security for the commands can be built on top of this (KARAF-2442). Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Toward Karaf 3.0.0
I have the code for KARAF-2455 (Role-based security for OSGi Services) and KARAF-2442 (Role-based security for Shell/Console commands) pretty much ready and was planning to submit pull requests for it tomorrow. I don't know, it might be worth including this in 3.0.0 as it complements the JMX role-based access nicely... If people think it's not necessary, that's fine too. I'm fine either way... Cheers, David On 8 October 2013 15:41, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, Thanks to Dan, we got the Aries release required for Karaf 3.0.0. I'm upgrading on Karaf trunk. I'm working on the latest mandatory improvement (KARAF-2496) now. So, today, I will: - commit both blueprint upgrade and KARAF-2496 - update Jira to add 3.0.1 version - review the Jira and move to 3.0.1 I discussed with Jamie this morning, he's ready to cut off the 3.0.0 release. I propose to prepare the release and vote for next Thursday (it gives some time to latest fixes and tests tomorrow). WDYT ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Some thoughts around adding security for Karaf Shell Commands
Hi all, I have the pull request for KARAF-2455 (role-based security for OSGi Services) and KARAF-2442 (role-based security for Karaf Shell Commands) ready. Since KARAF-2442 builds on top of KARAF-2455 (thanks Christian for suggesting this originally) I included both in a single pull requests as two separate commits: https://github.com/apache/karaf/pull/22 One note - I have included lots of unit tests (generally 95% coverage for any of the code I touched) but am also planning to add some system tests. However I'd like to add those system tests separately later. Feedback appreciated, David On 19 September 2013 11:22, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi David, awesome, thanks for the update. I just started to review the patches. I will apply tonight or tomorrow. Thanks again, Regards JB On 09/19/2013 11:56 AM, David Bosschaert wrote: Hi all, Just a little status update on this... I have since implemented most of KARAF-2455 (role-based security for OSGi Services) and KARAF-2442 (role-based security for Karaf Shell Commands). They build on top of what I did for KARAF-2434 and KARAF-2435. Once those are merge I can rebase my implementation on trunk and will provide patches to apply... Cheers, David On 26 August 2013 10:22, Jean-Baptiste Onofré j...@nanthrax.net wrote: Thanks David, it makes sense. Regards JB On 08/26/2013 11:16 AM, David Bosschaert wrote: Since I think the general consensus here is that it would be good to have a general security mechanism for OSGi services I have created a JIRA for that (KARAF-2455) and noted that role-based security for the commands can be built on top of this (KARAF-2442). Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Classloading question (Spring DM + Felix)
Yes, I'm pretty sure Blueprint doesn't replace the OSGi classloaders. However OSGi classloaders support the concept of Bundle Revisions [1]. As long as existing bundles refer to classes from a Bundle, even if that bundle is updated or uninstalled a Bundle Revision is kept around for it until the last reference is gone. Cheers, David [1] http://www.osgi.org/javadoc/r5/core/org/osgi/framework/wiring/BundleRevision.html On 24 September 2013 19:32, Johan Edstrom seij...@gmail.com wrote: In the blueprint case I think and for this case it probably is cleanup - ie like commons-logging in Tomcat then, you keep refs to something. On Sep 24, 2013, at 12:29 PM, Charles Moulliard ch0...@gmail.com wrote: And Blueprint too as i have done a test and behavior is the same Personally I would prefer that we improve that. Otherwise what will be here the benefit to promote OSGI ? On Tue, Sep 24, 2013 at 6:44 PM, Johan Edstrom seij...@gmail.com wrote: Spring dm replaces the classloaders for the bundles. Sent from my pressure cooker. On Sep 23, 2013, at 23:04, Charles Moulliard ch0...@gmail.com wrote: Hi, Is there a reason why when we deploy 2 bundles where Bundle A = Spring DM project = Spring XML File + Bean initialized using Class exposed by Bundle B that when we remove Bundle B, the Bundle A (after osgi;restart) still contain Class from Bundle B ? Does it work like that with Aries Blueprint ? Scenario 1) Package a bundle B containing a class com.mycompany.HelloWorld exporting this package 2) Package a Spring XML file creating a bean (com.mycompany.HelloWorld) as a Bundle A 3) Deploy Bundle A, B 4) Start them and verify in the log that by example init method of HelloWorld has been called 5) Stop Bundle B, remove it 6) Restart Bundle A = Spring project. No error occurs ! Regards, -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Classloading question (Spring DM + Felix)
One more thing. Restarting a bundle doesn't re-resolve it. It keeps the wirings as they were created during the resolve phase. You have to refresh it to get that behaviour. If your bundle A depends on bundle B and you uninstall bundle B, you can restart A. But when you refresh bundle A you'll notice that it won't resolve any more and at that point you can't start it any more either... On 24 September 2013 19:35, David Bosschaert david.bosscha...@gmail.com wrote: Yes, I'm pretty sure Blueprint doesn't replace the OSGi classloaders. However OSGi classloaders support the concept of Bundle Revisions [1]. As long as existing bundles refer to classes from a Bundle, even if that bundle is updated or uninstalled a Bundle Revision is kept around for it until the last reference is gone. Cheers, David [1] http://www.osgi.org/javadoc/r5/core/org/osgi/framework/wiring/BundleRevision.html On 24 September 2013 19:32, Johan Edstrom seij...@gmail.com wrote: In the blueprint case I think and for this case it probably is cleanup - ie like commons-logging in Tomcat then, you keep refs to something. On Sep 24, 2013, at 12:29 PM, Charles Moulliard ch0...@gmail.com wrote: And Blueprint too as i have done a test and behavior is the same Personally I would prefer that we improve that. Otherwise what will be here the benefit to promote OSGI ? On Tue, Sep 24, 2013 at 6:44 PM, Johan Edstrom seij...@gmail.com wrote: Spring dm replaces the classloaders for the bundles. Sent from my pressure cooker. On Sep 23, 2013, at 23:04, Charles Moulliard ch0...@gmail.com wrote: Hi, Is there a reason why when we deploy 2 bundles where Bundle A = Spring DM project = Spring XML File + Bean initialized using Class exposed by Bundle B that when we remove Bundle B, the Bundle A (after osgi;restart) still contain Class from Bundle B ? Does it work like that with Aries Blueprint ? Scenario 1) Package a bundle B containing a class com.mycompany.HelloWorld exporting this package 2) Package a Spring XML file creating a bean (com.mycompany.HelloWorld) as a Bundle A 3) Deploy Bundle A, B 4) Start them and verify in the log that by example init method of HelloWorld has been called 5) Stop Bundle B, remove it 6) Restart Bundle A = Spring project. No error occurs ! Regards, -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Classloading question (Spring DM + Felix)
Hi Charles, I don't have a Karaf 2.3 ready, but I tried this on 3.0/trunk: It contains the following bundles: [ 39] [Active] [ 30] Apache Karaf :: JAAS :: Modules (3.0.0.SNAPSHOT) [ 55] [Active] [ 30] Apache Karaf :: JAAS :: Command (3.0.0.SNAPSHOT) 55 depends on 39 (imports package org.apache.karaf.jaas.modules) I go: karaf@root() uninstall -f 39 karaf@root() refresh -f 55 Then, when I do: karaf@root() list -t 0 | grep 55 I get: [ 55] [ Installed] [ 30] Apache Karaf :: JAAS :: Command (3.0.0.SNAPSHOT) which means that bundle 55 could not be resolved... Cheers, David On 24 September 2013 20:12, Charles Moulliard ch0...@gmail.com wrote: Hi David, I have done a test on Karaf 2.3 but running refresh on the bundle having dependencies with a bundle which is not longer there doesn't and status of this bundle is still active 1) Installed [ 304] [Active ] [] [Started] [ 60] plainAndSimple-context.xml (0.0.0) [ 306] [Active ] [] [ ] [ 60] wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0 (0) JBossFuse:karaf@root packages:imports 304 wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0 (306): org.jboss.fuse.training.jar; version=0.0.0 Bundle 304 = Spring XML Bundle 2) Remove bundle 306 exposing the package : org.jboss.fuse.training.jar JBossFuse:karaf@root uninstall 306 JBossFuse:karaf@root packages:imports 304 wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0 (306): org.jboss.fuse.training.jar; version=0.0.0 3) Run refresh on bundle importing this package JBossFuse:karaf@root refresh 304 JBossFuse:karaf@root packages:imports 304 wrap_mvn_org.jboss.fuse.training_servicemix-exercises-plain-jar_1.0 (306): org.jboss.fuse.training.jar; version=0.0.0 Regards, On Tue, Sep 24, 2013 at 8:51 PM, David Bosschaert david.bosscha...@gmail.com wrote: One more thing. Restarting a bundle doesn't re-resolve it. It keeps the wirings as they were created during the resolve phase. You have to refresh it to get that behaviour. If your bundle A depends on bundle B and you uninstall bundle B, you can restart A. But when you refresh bundle A you'll notice that it won't resolve any more and at that point you can't start it any more either... On 24 September 2013 19:35, David Bosschaert david.bosscha...@gmail.com wrote: Yes, I'm pretty sure Blueprint doesn't replace the OSGi classloaders. However OSGi classloaders support the concept of Bundle Revisions [1]. As long as existing bundles refer to classes from a Bundle, even if that bundle is updated or uninstalled a Bundle Revision is kept around for it until the last reference is gone. Cheers, David [1] http://www.osgi.org/javadoc/r5/core/org/osgi/framework/wiring/BundleRevision.html On 24 September 2013 19:32, Johan Edstrom seij...@gmail.com wrote: In the blueprint case I think and for this case it probably is cleanup - ie like commons-logging in Tomcat then, you keep refs to something. On Sep 24, 2013, at 12:29 PM, Charles Moulliard ch0...@gmail.com wrote: And Blueprint too as i have done a test and behavior is the same Personally I would prefer that we improve that. Otherwise what will be here the benefit to promote OSGI ? On Tue, Sep 24, 2013 at 6:44 PM, Johan Edstrom seij...@gmail.com wrote: Spring dm replaces the classloaders for the bundles. Sent from my pressure cooker. On Sep 23, 2013, at 23:04, Charles Moulliard ch0...@gmail.com wrote: Hi, Is there a reason why when we deploy 2 bundles where Bundle A = Spring DM project = Spring XML File + Bean initialized using Class exposed by Bundle B that when we remove Bundle B, the Bundle A (after osgi;restart) still contain Class from Bundle B ? Does it work like that with Aries Blueprint ? Scenario 1) Package a bundle B containing a class com.mycompany.HelloWorld exporting this package 2) Package a Spring XML file creating a bean (com.mycompany.HelloWorld) as a Bundle A 3) Deploy Bundle A, B 4) Start them and verify in the log that by example init method of HelloWorld has been called 5) Stop Bundle B, remove it 6) Restart Bundle A = Spring project. No error occurs ! Regards, -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
Re: Some thoughts around adding security for Karaf Shell Commands
Hi all, Just a little status update on this... I have since implemented most of KARAF-2455 (role-based security for OSGi Services) and KARAF-2442 (role-based security for Karaf Shell Commands). They build on top of what I did for KARAF-2434 and KARAF-2435. Once those are merge I can rebase my implementation on trunk and will provide patches to apply... Cheers, David On 26 August 2013 10:22, Jean-Baptiste Onofré j...@nanthrax.net wrote: Thanks David, it makes sense. Regards JB On 08/26/2013 11:16 AM, David Bosschaert wrote: Since I think the general consensus here is that it would be good to have a general security mechanism for OSGi services I have created a JIRA for that (KARAF-2455) and noted that role-based security for the commands can be built on top of this (KARAF-2442). Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: [VOTE] Release Apache Karaf version 2.3.3
+1 (non-binding) David On 17 September 2013 15:48, Jamie G. jamie.goody...@gmail.com wrote: Hi, We resolved 36 issues in this release (web page will be published post RC promotion): https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf- 2.3.3-release.page Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-063 Release tags: https://svn.apache.org/repos/asf/karaf/tags/karaf-2.3.3/ 2.3.x Dependencies table: https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps- 2.3.x.page Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours.
Re: Some thoughts around adding security for Karaf Shell Commands
Since I think the general consensus here is that it would be good to have a general security mechanism for OSGi services I have created a JIRA for that (KARAF-2455) and noted that role-based security for the commands can be built on top of this (KARAF-2442). Cheers, David
Re: Some thoughts around adding security for Karaf Shell Commands
Hi Christian, On 22 August 2013 23:14, Christian Schneider ch...@die-schneider.netwrote: Sounds great. I have not yet looked into it in detail but the concept sounds decent. One thing you should keep in mind is to make the authorization exchangeable. For example at Talend we provide an xacml based pdp. So it would be great to have a hook wehere we can plug this in to do the auth decisions. Personally I am not a fan of xacml but this shows that different organizations would probably like to treat this differently. What I did provides the authorization roles completely through ConfigAdmin. Which is pluggable in a number of ways: in Karaf we use the Felix Config admin which allows the registration of additional configuration providers. You can also replace the Config Admin Service itself to provide the info from another place... I guess we can always add more pluggability if that's needed. The way round your aproach sounds much more maintainable than xacml. So it might even be interesting to attach a pdp to your authorization impl :-) :) I have one other idea. How about doing the authorization for jmx and commands only on the service level? At least in karaf 3 both use the same services so securing only the service instead of jmx and commands would reduce the number of config settings needed. For example: jmx: featureJMXBean.install(**feature) command: feature:install feature Both would be secured by simply securing the FeatureService. The problem with this is that there are still JMX APIs that aren't provided as OSGi services so that would leave a pretty big hole in the security if you ask me... For those cases where a single Service covers both JMX and the console we could use a single security point (that would be just a matter of configuring it that way), but I think that we still need the direct JMX security to make sure people can't do any damage through any of the non-OSGi-Service MBeans... One thing I am not sure about btw. is doing too much magic behind the scenes. Like the config admin config you described that causes other configs to be created on the fly. Perhaps we find a simpler model that also works. Currently I do not have a good idea how to handle it though. I agree. We need to find the balance between simplicity and ease-of-use. If you think of a simpler way without configuration generation that doesn't make the thing horrilbly hard to use for commands I'd love to hear it. Cheers, David
Re: Some thoughts around adding security for Karaf Shell Commands
That may be true for the Karaf MBeans but there are also other MBeans in the system. For example ones provided by the JVM. As an example take the MBean with the following object name: connector:name=rmi It is registered by the JVM and not through OSGi services and has a few operations (start(), stop()). By purely having the ACLs go through the service registry model you would not be able to prevent anyone from calling stop() on that mbean... It's just an example. Another example would be when an OSGi bundle registers MBeans directly (not through the WhiteBoard pattern). With the approach I suggest in KARAF-2435 you can secure any JMX operation, regardless of whether it's implemented as an OSGi service or not... Cheers, David On 23 August 2013 11:43, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, @David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean registration. Aries JMX looks up for MBeans exposed as OSGi services. So I think we can leverage it. WDYT ? Regards JB On 08/23/2013 10:41 AM, David Bosschaert wrote: Hi Christian, On 22 August 2013 23:14, Christian Schneider ch...@die-schneider.net** wrote: Sounds great. I have not yet looked into it in detail but the concept sounds decent. One thing you should keep in mind is to make the authorization exchangeable. For example at Talend we provide an xacml based pdp. So it would be great to have a hook wehere we can plug this in to do the auth decisions. Personally I am not a fan of xacml but this shows that different organizations would probably like to treat this differently. What I did provides the authorization roles completely through ConfigAdmin. Which is pluggable in a number of ways: in Karaf we use the Felix Config admin which allows the registration of additional configuration providers. You can also replace the Config Admin Service itself to provide the info from another place... I guess we can always add more pluggability if that's needed. The way round your aproach sounds much more maintainable than xacml. So it might even be interesting to attach a pdp to your authorization impl :-) :) I have one other idea. How about doing the authorization for jmx and commands only on the service level? At least in karaf 3 both use the same services so securing only the service instead of jmx and commands would reduce the number of config settings needed. For example: jmx: featureJMXBean.install(feature) command: feature:install feature Both would be secured by simply securing the FeatureService. The problem with this is that there are still JMX APIs that aren't provided as OSGi services so that would leave a pretty big hole in the security if you ask me... For those cases where a single Service covers both JMX and the console we could use a single security point (that would be just a matter of configuring it that way), but I think that we still need the direct JMX security to make sure people can't do any damage through any of the non-OSGi-Service MBeans... One thing I am not sure about btw. is doing too much magic behind the scenes. Like the config admin config you described that causes other configs to be created on the fly. Perhaps we find a simpler model that also works. Currently I do not have a good idea how to handle it though. I agree. We need to find the balance between simplicity and ease-of-use. If you think of a simpler way without configuration generation that doesn't make the thing horrilbly hard to use for commands I'd love to hear it. Cheers, David -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Some thoughts around adding security for Karaf Shell Commands
Hi all, As suggested by Christian, I started looking at adding role-based access to OSGi services in general (in Karaf) and applying this to the Karaf commands. At this point I have something that kinda works. It proxies services for service consumers using service registry hooks and on invocation checks that the Subject associated with the current Access Control Context has the right roles. If not it blocks the service invocation by throwing a SecurityException. Not all services are secured this way, there is a new property in etc/system.properties that selects what services are processed this way using a simple OSGi service filter. To apply it to the shell commands it is set to the following: karaf.secured.services=((osgi.command.scope=*)(osgi.command.function=*)) The actual ACLs for the secured services are defined using ConfigAdmin in a way that's pretty much identical to what I did for the JMX acls in KARAF-2435, except that the PID doesn't matter. The configuration is matched with a service on a 'service.guard' property. The other entries match method names of the service. They can also match values passed in (as you can do with JMX), so you can define different roles for doit(foo) and doit(bar). An example configuration could look like this: service.guard = (objectClass=org.acme.TestServiceAPI) doit = admin, viewer doit[foo] = admin So the next thing I did was look at whether this could be applied to the shell commands. The problem was that every little command is a separate service so this would potentially be a lot of configuration files for the administrator to maintain. You really want to define the ACLs for a single scope in a single configuration file, something like this (for the bundle scope): install = manager start = manager list = manager, viewer stop = manager stop[/.*0.*/] = admin # only admin can stop the framework uninstall = admin To fit with the general service ACL model this would have to be 5 different configuration files (one for each command). I thought that that was not very user friendly. Therefore I came up with a mechanism that accepts ConfigAdmin configuration for commands in the same scope like the above and then generates additional ConfigAdmin configuration on the fly that conforms to the general service ACL form. With that, enabled... let's say I'm logged in as a 'manager', with the above example configuration for the bundle scope, the it has the following effect: karaf@root() stop 50 # works karaf@root() stop 0 Error executing command: Insufficient credentials. Which is pretty much what I wanted to achieve :) So basically what we have here is a combination of two things: 1. Modification of service registrations to add a roles property which is then used by the CommandProcessor to only show the commands that the user associated with the active console can potentially execute (it could still reject commands based on arguments passed in). 2. Proxying of services (including shell command services) that check that the Subject associated with the current AccessControlContext has the right roles to make this invocation. The role-checking is still done outside of the service implementations. The actual services being secured don't need to change their code. You can see my experimental implementation at my branch here: https://github.com/bosschaert/karaf/commit/2668b88a7ddfb1ba93e7e732884734ff7dc0d1a3 That branch is not finished (cleanup, tests terribly lacking, no optimization) and some things could be made a little more user friendly, but it contains the general idea... If people are happy with the general idea I can focus a little on tiding it up... Thoughts anyone? David On 19 August 2013 10:56, David Bosschaert david.bosscha...@gmail.comwrote: Hi Christian, On 19 August 2013 10:29, Christian Schneider ch...@die-schneider.netwrote: The idea was to use Shiro to establish a kind of security context in a thread local. Your approach of using Subject.doas might be the better alternative though. In any case we should recommend one standard approach to establish the security context. Perhaps we could even allow both and have adapters to establish one context from another. Yep, this needs to be standard. On 08/15/2013 10:16 PM, Christian Schneider wrote: I like the idea of adding permissions to the commands. I wonder though if this is perhaps a more general problem that not only affects commands. So how about adding a generic permission check for services? For example I would like to use the @RolesAllowed annotation to couple roles or permissions with service methods. A service registry hook could then check that the caller has the permission before allowing the call. Of course there could be other additional way of adding this information like the service properties you mentioned. I'm not sure I like the annotation approach. One of the things that I would like to enable is for customers to change
Re: Some thoughts around adding security for Karaf Shell Commands
Hi all, On 15 August 2013 21:23, Jean-Baptiste Onofré j...@nanthrax.net wrote: OSGi already provides the security module for that, and it's what David proposed (to leverage the services security). Well AFAIK OSGi doesn't yet contain a general framework for allowing/disallowing the invocation of *existing* services based on Principals of the current user. So I actually agree with Cristian that this would indeed be a nice general feature. It should be possible to generalize my proposal so that it can be used for other purposes than just commands... An extension with Shiro (expecially now that we have Pax Shiro ;)) is a good idea. That should be possible later, but I'd like to keep it as simple as possible for now. There is no need to use Shiro for this stuff, but I can see that people who already use Shiro like to have an integration. On 08/15/2013 10:16 PM, Christian Schneider wrote: I like the idea of adding permissions to the commands. I wonder though if this is perhaps a more general problem that not only affects commands. So how about adding a generic permission check for services? For example I would like to use the @RolesAllowed annotation to couple roles or permissions with service methods. A service registry hook could then check that the caller has the permission before allowing the call. Of course there could be other additional way of adding this information like the service properties you mentioned. I'm not sure I like the annotation approach. One of the things that I would like to enable is for customers to change the roles associated with operations/service invocations afterwards, simply because the roles chosen by the developer may not match up with the roles mappings of all organizations. With an annotation approach you'd have to modify the code and recompile it when you want to change them. I prefer to use OSGi ConfigAdmin for that since it completely decouples this information from the code and can easily be modified later... We should also provide a generic way to attach authentication information to a thread that calls a service. I tought about using apache shiro for this but I am not sure if it is universal enough. I don't understand why you need Shiro for this. Isn't javax.security.auth.Subject.doAs() the standard way to do this? Cheers, David
Re: Some thoughts around adding security for Karaf Shell Commands
Hi Christian, On 19 August 2013 10:29, Christian Schneider ch...@die-schneider.netwrote: The idea was to use Shiro to establish a kind of security context in a thread local. Your approach of using Subject.doas might be the better alternative though. In any case we should recommend one standard approach to establish the security context. Perhaps we could even allow both and have adapters to establish one context from another. Yep, this needs to be standard. On 08/15/2013 10:16 PM, Christian Schneider wrote: I like the idea of adding permissions to the commands. I wonder though if this is perhaps a more general problem that not only affects commands. So how about adding a generic permission check for services? For example I would like to use the @RolesAllowed annotation to couple roles or permissions with service methods. A service registry hook could then check that the caller has the permission before allowing the call. Of course there could be other additional way of adding this information like the service properties you mentioned. I'm not sure I like the annotation approach. One of the things that I would like to enable is for customers to change the roles associated with operations/service invocations afterwards, simply because the roles chosen by the developer may not match up with the roles mappings of all organizations. With an annotation approach you'd have to modify the code and recompile it when you want to change them. I prefer to use OSGi ConfigAdmin for that since it completely decouples this information from the code and can easily be modified later... We should also provide a generic way to attach authentication I think there could be three levels of external configurability: 1. You could use annotations with roles like @RolesAllowed(admin) public void deleteUser(...); 2. You could use annotations to store permissions @RolesAllowed(Userservice.**deleteUser) public void deleteUser(...); Then the mapping to roles could be done by using groups in the simplest form. group UserService.deleteUser: admin, ... 3. You could completely externalize the decision. In this case a Policy Decision Point approach could make sense. You extract the meta information of a service call, give it to a pdp and get back an authorization decision. I would favor having just option 3. I can see that option 2 provides some form of indirection, but you still need to modify the service code to add the annotation in the first place. That might be ok for services that have their code in the Karaf codebase, but for outside services it would be pretty much impossible. I would rather have a clear single way of configuring this so that it's very clear what the definition is - if a security guy wants to figure out what roles are needed for options 1 2 (s)he needs to have access to the source to read how the annotation was declared, or otherwise rely on documentation, which you are never sure is actually in sync with the code. If we'd opt for a combined annotation+external approach it's still quite hard to get a full overview of what roles are required to invoke what if you want to understand that... Hence I would simply go for having just option 3 and keep everything in one place. information to a thread that calls a service. I tought about using apache shiro for this but I am not sure if it is universal enough. I don't understand why you need Shiro for this. Isn't javax.security.auth.Subject.**doAs() the standard way to do this? Probably it is. How does this work internally? Does it also use a thread local? How does it work if you spawn a new thread using an executor or similar? I think we should do some examples to see how it works in practice. Re Subject.doAs(). The Subject would be configured via JAAS to contain the appropriate roles for the current user, as we do today in Karaf (although you should be able to configure Shiro to provide this info)... Once you're inside a piece of code that is executed via Subject.doAs() (which could be in a different thread) you can do: AccessControlContext acc = AccessController.getContext(); Subject subject = Subject.getSubject(acc); At this point you can get all the Principals from the subject, e.g. all the roles: SetRolePrincipal roles = subject.getPrincipals(RolePrincipal.class); This is all plain standard J2SE code, no library dependencies... Cheers, David
Re: [VOTE] Switch from svn to git
I'm working preparing my contribution for KARAF-2434 and KARAF-2435... What's the process I should follow? Should I still attach a patch to the bugs or should I simply refer to a commit on github or even file a pull request somewhere? Apologies if this has already been discussed. David On 9 August 2013 14:06, Jean-Baptiste Onofré j...@nanthrax.net wrote: Yes, I will close the vote and deal with infra. Thanks for the reminder. Regards JB On 08/09/2013 08:23 AM, Łukasz Dywicki wrote: Can we finish this vote and move forward to git? :) Cheers, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Christian Müller christian.muel...@gmail.com w dniu 17 lip 2013, o godz. 00:00: Apache Camel is using Git since a few weeks now without any issue. We also did three releases in this time without any problems. Feel free to ask if you need any assistance/help. I like to help... Best, Christian - Software Integration Specialist Apache Camel committer: https://camel.apache.org/team V.P. Apache Camel: https://www.apache.org/**foundation/https://www.apache.org/foundation/ Apache Member: https://www.apache.org/**foundation/members.htmlhttps://www.apache.org/foundation/members.html https://www.linkedin.com/pub/**christian-mueller/11/551/642https://www.linkedin.com/pub/christian-mueller/11/551/642 On Tue, Jun 25, 2013 at 11:12 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, to follow the discussion that we had some weeks ago, I start here a formal vote to migrate our scm from svn to git. Please vote to approve this switch: [ ] +1 Approve the switch (from svn to git) [ ] -1 Do not approve the switch (please provide specific comments) This vote will be open for 72 hours. Thanks, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Role based security for Karaf JMX access
Hi Ioannis, Christian, Thanks for the feedback! Yes, providing similar Access Control for the Karaf shell is also on my list. Hopefully I can look at that in the near future. WRT to groups versus nested roles. I thought about that too. You could achieve the same effect with roles if they can subsume other roles. This would require a recursive/nested definition of roles and I'm not sure this is universally supported by all security back-ends. The users/groups/roles combination seems extremely common and supported by many systems. It's also a little bit simpler in that there is no recursion involved, which might make it easier to map it to certain types of back-end stores... Therefore I opted for groups, I hope everyone can live with that... Btw. I am planning to add some jaas based authentication and role based security to CXF that might also profit from your addition. Cool, yes with that a CXF might set JAAS principals in the current context, which can then be picked up by the JMX guard... Cheers, David On 7 August 2013 08:37, Christian Schneider ch...@die-schneider.net wrote: Group and Role based security sounds like a good addition to karaf. I am not sure if it is necessary to distinguish groups and roles though. Can't we just support adding roles into roles (or groups into groups)? This should provide the same additional layer of abstraction. Btw. I am planning to add some jaas based authentication and role based security to CXF that might also profit from your addition. Another thing that seems related is xacml support in cxf. Perhaps we could define some common Policy Decision Point interface that can be implemented using either your implementation or an xacml based pdp. Christian On 06.08.2013 12:22, dav...@apache.org wrote: Hi all, I have started an implementation of Role based security for JMX access into Karaf. Up until now, remote JMX access was guarded by one role. If you had that role you could access everything. With my changes you can define roles (ACLs) per MBean, per method or based on arguments to an MBean invocation. There are also wildcards that can be used to define general rules for all MBeans which provide default behaviour for any MBean which doesn't have a specific ACL. It works like this. The bin/karaf launch script sets -Djavax.management.builder.**initial to specify a Karaf-provided MBean Server Builder. This builder guards/intercepts any MBean invocations and checks the roles of the current user for the current invocation. These roles are set through the existing Karaf JAAS intergration. If the current user doesn't have the required roles an exception is thrown and the invocation does not proceed. ACLs for the various MBeans are defined alongside other Karaf configuration in the cfg/ directory and read through OSGi ConfigAdmin. The PID/file name is based on the MBean Object Name, for example an MBean called org.apache.karaf:type=bundles,**name=root is mapped to a file jmx.acl.org.apache.karaf.**bundles.root.cfg. This file can contain an ACL like this: list : viewer, manager restart : manager stop(java.lang.String)[0] : admin # String argument match stop(java.lang.String)[/([1-4]**)?[0-9]/] : admin # Regexp argument match stop(java.lang.String) : manager # any other arguments match this If no rules can be found for the current invocation the system will search in a higher level cfg file, with as highest level jmx.acl.cfg which contains the following 'catchall' rules. get* : viewer is* : viewer set* : admin * : admin Whenever a matching rule is found, that is used and the code doesn't look any further. So the most specific definition wins. Certain rules need to have broad access, e.g. an admin role. It's not practical to have to specify 'admin' as a role with every single access control declaration. For this I have introduced groups. While other solutions might be possible, groups are widely supported in security systems so I used those. E.g. to address the 'admin' use-case above you might have a user (joe) who needs rights to every MBean in the system. For this you add joe to the AdminGroup. The AdminGroup then has every role that is defined in the system. It's not magic, because every time you add a new role to the system you need to update the AdminGroup, but it's manageable. Finally I added a special MBean org.apache.karaf.security that allows you to find out whether the current user has the right roles to use a certain mbean or invoke a certain invocation. This can be used when building a management console/GUI to hide things that map to operations that the current user has no right to anyway. It's not 100% watertight in the sense that a specific role can be specified for a specific value (e.g. only 'admin' can stop bundle 0), so there is still a chance that the attempted invocation is rejected, but in general it should be a help to building smart
