Re: Cannot connect to child instance - "Channel opening failed"
Hi, What's your JVM ? Do you have security policy on it ? Regards JB On 12/13/2016 02:14 AM, CodeCola wrote: karaf@root()> instance:start SecondInstance karaf@root()> instance:connect SecondInstance Connecting to host localhost on port 8106 Connecting to unknown server. Automatically adding to known hosts. Storing the server key in known_hosts. Password: * Connected *Error executing command: Channel opening failed* Windows 10 -- View this message in context: http://karaf.922171.n3.nabble.com/Cannot-connect-to-child-instance-Channel-opening-failed-tp4048990.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
ECF 3.13.3 released
ECF 3.13.3 is now available for download [1]. This is a bug-fix release. We provide a CT-tested implementation of the OSGi R6 Remote Services and Remote Service Admin specifications. A new simpler set of features has reduced the size of the RS/RSA install on Karaf [2]. ECF supports pluggable distribution providers [3]. This allows remote services to be declared, implemented, and consumed across multiple transports such as xmlrpc, rosgi, jersey, cxf, javagroups, jms, mqtt, google rpc, hazelcast or custom distribution implementations. Also recently introduced are remote management services and Eclipse-based tooling for RS/RSA development and test [4]. [1] https://www.eclipse.org/ecf/downloads.php [2] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf [3] https://wiki.eclipse.org/Distribution_Providers [4] https://www.eclipse.org/ecf/NewAndNoteworthy.html
Re: Exit a child instance without stopping it
Hi, If you connect using instance:connect (which is basically ssh), and then CTRL-D or exit (not shutdown or halt), then the instance is still running. You can control instance "outside" of the root one using bin/instance script. Regards JB On 12/13/2016 02:59 AM, CodeCola wrote: I am in karaf@Container2> How do I exit the Container to return to the karaf@root> without stopping the Container2 ? I don't see an *instance:exit* command ? -- View this message in context: http://karaf.922171.n3.nabble.com/Exit-a-child-instance-without-stopping-it-tp4048991.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Exit a child instance without stopping it
Usually the child instances spawn their own process. So you connect to it via SSH, therefore just disconnect via Ctrl-D as from any other remote shell. Regards, Achim sent from mobile device Am 13.12.2016 2:59 vorm. schrieb "CodeCola" : > I am in > > karaf@Container2> > > How do I exit the Container to return to the > > karaf@root> > > without stopping the Container2 ? > > I don't see an *instance:exit* command ? > > > > > > -- > View this message in context: http://karaf.922171.n3.nabble. > com/Exit-a-child-instance-without-stopping-it-tp4048991.html > Sent from the Karaf - User mailing list archive at Nabble.com. >
Exit a child instance without stopping it
I am in karaf@Container2> How do I exit the Container to return to the karaf@root> without stopping the Container2 ? I don't see an *instance:exit* command ? -- View this message in context: http://karaf.922171.n3.nabble.com/Exit-a-child-instance-without-stopping-it-tp4048991.html Sent from the Karaf - User mailing list archive at Nabble.com.
Cannot connect to child instance - "Channel opening failed"
karaf@root()> instance:start SecondInstance karaf@root()> instance:connect SecondInstance Connecting to host localhost on port 8106 Connecting to unknown server. Automatically adding to known hosts. Storing the server key in known_hosts. Password: * Connected *Error executing command: Channel opening failed* Windows 10 -- View this message in context: http://karaf.922171.n3.nabble.com/Cannot-connect-to-child-instance-Channel-opening-failed-tp4048990.html Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problems after removing a feature repository in Karaf 4.0
The features are installed programmatically, by a separate "installer" bundle. The karaf feature repo file is generated and saved in the persistent storage area of that installer bundle. In our application, it's possible that a bundle with the same name and version, but with different content gets re-installed. Currently, this is not a problem, since we find the bundle, uninstall it, and re-install it using feature:install and a “disposable” feature repository. If we can't remove the feature repo, then if we need to reinstall a bundle, we need to find the feature repo that was used to install it, and remove that repo. If we wouldn't, then we would have 2 feature repos which contain the same feature, which doesn't seem like a good idea. While this is not impossible, it's more complicated than our current solution. The point is that we don't really “need” a persistent feature repository, we can easily regenerate the feature repository file when we need to reinstall a bundle. A system that can regenerate data is usually simpler than a system that needs to keep track of that data, making sure it stays in synch, is backed up, doesn't get removed etc... Using Karaf features to install bundles is very convenient for us. We have URLStreamHandlers in place to handle file:, ftp:, and scp: protocols, which means we can easily install bundles from remote locations. The bundles that need to be installed are very light-weight, they are not much more than a wrapper around an Ant script, with a blueprint descriptor that registers it as an OSGi service. This allows us to run a reusable, versioned Ant script on a remote system.While this Ant script is in development, it will be repackaged into a bundle and redeployed to the remote systems. Hence the need to re-install a bundle with the same name and version. I can see the need for tighter rules on features, certainly for consistency’s sake, but we were happier with the more “relaxed” approach. I don't have enough knowledge of Karaf or OSGi to propose a solution, but I hope to make the case to allow less strict rules in certain cases. Thank you very much for your swift reply, Frank 'S Jegers. -- View this message in context: http://karaf.922171.n3.nabble.com/Problems-after-removing-a-feature-repository-in-Karaf-4-0-tp4048979p4048988.html Sent from the Karaf - User mailing list archive at Nabble.com.
Karaf on AWS Beanstalk
Hi all, did anybody try to get a Karaf running on Amazon Beanstalk? I can imagine it could be doable basically converting ./karaf command into a commandline for Beanstalk (http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-se-platform.html ) I am going to try this during holidays, but If somebody has tried this I would appreciate feedback :) Fabian -- Fabian Lange | Performance Expert mobil: +49 (0) 160.3673393 codecentric AG | Hochstraße 11 | 42697 Solingen | Deutschland Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
Re: Problems after removing a feature repository in Karaf 4.0
2016-12-12 15:16 GMT+01:00 Frank_S : > Hi, > > we run our application in Karaf. It has a pluggable architecture in the > sense that extra bundles get installed that perform certain services. The > services are defined using Blueprint descriptors. For installing the > bundles, we use the features framework of Karaf. More specifically, we > generate a feature repository file, add the feature repository, install the > feature, remove the feature repository, and then delete the generated > feature repository file. > This worked well in Karaf 2.4.0, but if we do this in Karaf 4.0, the first > feature install succeeds, but a subsequent feature install yields the > following exception : > > org.osgi.service.resolver.ResolutionException: Unable to resolve root: > missing requirement [root] osgi.identity; > osgi.identity=com.ikanalm.phase.echoparameters; type=karaf.feature; > version="[1.0.0,1.0.0]"; > filter:="(&(osgi.identity=com.ikanalm.phase.echoparameters)( > type=karaf.feature)(version>=1.0.0)(version<=1.0.0))" > at > org.apache.felix.resolver.ResolutionError.toException( > ResolutionError.java:42)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.felix.resolver.ResolverImpl.resolve( > ResolverImpl.java:235)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.felix.resolver.ResolverImpl.resolve( > ResolverImpl.java:158)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.karaf.features.internal.region.SubsystemResolver.resolve( > SubsystemResolver.java:216)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.karaf.features.internal.service.Deployer. > deploy(Deployer.java:263)[8:org.apache.karaf.features.core:4.0.7] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl. > doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features. > core:4.0.7] > at > org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call( > FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.7] > at java.util.concurrent.FutureTask.run(FutureTask. > java:266)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1142)[:1.8.0_60] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:617)[:1.8.0_60] > at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] > > The bundle com.ikanalm.phase.echoparameters, version 1.0.0 is the one that > was installed using the generated feature repository file, which looks like > this : > http://karaf.apache.org/xmlns/features/v1.2.1"; > name="com.ikanalm.phase.echoparameters1.0.0_1481545020697"> > > file://SOMEPATH/com.ikanalm.phase.echoparameters- > 1.0.0.jar > > > > The feature doesn't show up when I do "feature:list -i", and the feature > repository isn't listed when I do "feature:repo-list". The bundle, however, > is still installed, so our application is able to use it. > > Unfortunately, the feature is still listed in the requirements list of the > “root” instance : > karaf@root()> requirement-list > Region | Requirement > --- > root | feature:com.ikanalm.phase.echoparameters/[1.0.0,1.0.0] > > When I do a “requirement-remove” on the feature, the feature is > uninstalled, > and after that I can again install other features without the exception > popping up, but regrettably, the bundle is also uninstalled, so that > doesn't > really help us. > > Is there a way to remove a requirement on an instance without uninstalling > the feature or the bundle ? Or is the removal of the feature repository a > bad idea, and are we wrong to use the feature framework merely as a > “vessel” > to get our bundles installed ? > You shouldn't really remove a repository if you haven't uninstalled the features in that repository. There's an additional check in 4.1 which forbids you to do that (see https://issues.apache.org/jira/browse/KARAF-4060 ). And if you uninstall the feature, the bundles will be uninstalled if they are not needed anymore. The reason is that the Karaf 4 features service considers the set of requirements and computes a set of bundles that need to be installed. If you remove a requirement on the feature, the bundle does not need to be installed anymore. And if you remove the repository, the requirement on the feature can't be satisfied anymore. There's no easy workaround for this specific problem: there's definitely no way to keep a feature installed and remove the corresponding repository. Why do you see keeping the repository as a problem ? > > Note again that this worked fine in Karaf 2.4.0. > > Thanks, > Frank 'S Jegers. > > > > > -- > View this message in context: http://karaf.922171.n3.nabble. > com/Problems-after-removing-a-feature-repository-in-Karaf-4- > 0-tp4048979.html > Sent from the Karaf - User mailing list archive at Nabble.com. > -- Guillaume Nodet --
Re: Problems after removing a feature repository in Karaf 4.0
What you do sounds very strange. Can you explain why you first install the repo and feature and then remove the repo? Why don't you simply leave it there? If you want to cleanly uninstall a feature and repo use feature:uninstall and feature:repo-remove. Christian On 12.12.2016 15:16, Frank_S wrote: Hi, we run our application in Karaf. It has a pluggable architecture in the sense that extra bundles get installed that perform certain services. The services are defined using Blueprint descriptors. For installing the bundles, we use the features framework of Karaf. More specifically, we generate a feature repository file, add the feature repository, install the feature, remove the feature repository, and then delete the generated feature repository file. This worked well in Karaf 2.4.0, but if we do this in Karaf 4.0, the first feature install succeeds, but a subsequent feature install yields the following exception : org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=com.ikanalm.phase.echoparameters; type=karaf.feature; version="[1.0.0,1.0.0]"; filter:="(&(osgi.identity=com.ikanalm.phase.echoparameters)(type=karaf.feature)(version>=1.0.0)(version<=1.0.0))" at org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[8:org.apache.karaf.features.core:4.0.7] at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[8:org.apache.karaf.features.core:4.0.7] at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.7] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] The bundle com.ikanalm.phase.echoparameters, version 1.0.0 is the one that was installed using the generated feature repository file, which looks like this : http://karaf.apache.org/xmlns/features/v1.2.1"; name="com.ikanalm.phase.echoparameters1.0.0_1481545020697"> file://SOMEPATH/com.ikanalm.phase.echoparameters-1.0.0.jar The feature doesn't show up when I do "feature:list -i", and the feature repository isn't listed when I do "feature:repo-list". The bundle, however, is still installed, so our application is able to use it. Unfortunately, the feature is still listed in the requirements list of the “root” instance : karaf@root()> requirement-list Region | Requirement --- root | feature:com.ikanalm.phase.echoparameters/[1.0.0,1.0.0] When I do a “requirement-remove” on the feature, the feature is uninstalled, and after that I can again install other features without the exception popping up, but regrettably, the bundle is also uninstalled, so that doesn't really help us. Is there a way to remove a requirement on an instance without uninstalling the feature or the bundle ? Or is the removal of the feature repository a bad idea, and are we wrong to use the feature framework merely as a “vessel” to get our bundles installed ? Note again that this worked fine in Karaf 2.4.0. Thanks, Frank 'S Jegers. -- View this message in context: http://karaf.922171.n3.nabble.com/Problems-after-removing-a-feature-repository-in-Karaf-4-0-tp4048979.html Sent from the Karaf - User mailing list archive at Nabble.com. -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Problems after removing a feature repository in Karaf 4.0
Hi, we run our application in Karaf. It has a pluggable architecture in the sense that extra bundles get installed that perform certain services. The services are defined using Blueprint descriptors. For installing the bundles, we use the features framework of Karaf. More specifically, we generate a feature repository file, add the feature repository, install the feature, remove the feature repository, and then delete the generated feature repository file. This worked well in Karaf 2.4.0, but if we do this in Karaf 4.0, the first feature install succeeds, but a subsequent feature install yields the following exception : org.osgi.service.resolver.ResolutionException: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=com.ikanalm.phase.echoparameters; type=karaf.feature; version="[1.0.0,1.0.0]"; filter:="(&(osgi.identity=com.ikanalm.phase.echoparameters)(type=karaf.feature)(version>=1.0.0)(version<=1.0.0))" at org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[8:org.apache.karaf.features.core:4.0.7] at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[8:org.apache.karaf.features.core:4.0.7] at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.7] at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.7] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60] at java.lang.Thread.run(Thread.java:745)[:1.8.0_60] The bundle com.ikanalm.phase.echoparameters, version 1.0.0 is the one that was installed using the generated feature repository file, which looks like this : http://karaf.apache.org/xmlns/features/v1.2.1"; name="com.ikanalm.phase.echoparameters1.0.0_1481545020697"> file://SOMEPATH/com.ikanalm.phase.echoparameters-1.0.0.jar The feature doesn't show up when I do "feature:list -i", and the feature repository isn't listed when I do "feature:repo-list". The bundle, however, is still installed, so our application is able to use it. Unfortunately, the feature is still listed in the requirements list of the “root” instance : karaf@root()> requirement-list Region | Requirement --- root | feature:com.ikanalm.phase.echoparameters/[1.0.0,1.0.0] When I do a “requirement-remove” on the feature, the feature is uninstalled, and after that I can again install other features without the exception popping up, but regrettably, the bundle is also uninstalled, so that doesn't really help us. Is there a way to remove a requirement on an instance without uninstalling the feature or the bundle ? Or is the removal of the feature repository a bad idea, and are we wrong to use the feature framework merely as a “vessel” to get our bundles installed ? Note again that this worked fine in Karaf 2.4.0. Thanks, Frank 'S Jegers. -- View this message in context: http://karaf.922171.n3.nabble.com/Problems-after-removing-a-feature-repository-in-Karaf-4-0-tp4048979.html Sent from the Karaf - User mailing list archive at Nabble.com.
