how does the karaf client's bundle:list command determine the bundles' states? When a bundle show "Failure" in bundle:list, programmatically running this bundle's getState() (to display on a gui) shows Active. Is there another api i can use to determine if the bundle is in Failure state? Karaf version is 4.1.5 although it shows on earlier versions too. Thanks.
I've had a similar situation. If you look at the Karaf sources for the bundle:list, you'll notice that they use org.apache.karaf.bundle.core.BundleInfo to get the state via org.apache.karaf.bundle.core.BundleService =>
org.apache.karaf.bundle.core.BundleInfo info = bundleService.getInfo(bundle.get());
info.getState();
More info: https://github.com/apache/karaf/blob/5144a1eba5687dab0f016a9bf95e58e6687a26ad/bundle/core/src/main/java/org/apache/karaf/bundle/command/List.java
Related
as i'm new to this OpenDayLight, the following is my requirement
after installation of southbound plugin OVSDB in karaf console, i'm unable to get the http response from network-topology
installation is completely done by providing the following command in karaf console
feature:install odl-ovsdb-southbound-impl-ui
but after this installation,if i run the follow command
GET http://<controller-ip>:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1/
or
GET http://<controller-ip>:8181/restconf/operational/network-topology:network-topology/topology/ovsdb:1
the result body should be:
{
"topology": [
{
"topology-id": "ovsdb:1"
}
]
}
but the result of my console is showing only
INFO
please give me any idea to get resultant output.
what ODL version are you using?
what tool are you using to issue the REST call?
I just tried with a very recent distribution (but I've known this to work
for a long time on much older versions as well):
opendaylight-user#root>feature:install odl-ovsdb-southbound-impl-ui
opendaylight-user#root>
then:
$ curl -u "admin:admin" http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/ovsdb:1
which gave me:
{"topology":[{"topology-id":"ovsdb:1"}]}
I upgraded from spring-xd 1.2.1 to 1.3.0, and have both under /opt on my system. After starting xd in single node (but configured to use Zookeeper), I tried to create another stream (e.g. "time | log"), and spring-xd throws the following exception:
java.io.FileNotFoundException: /opt/spring-xd-1.2.1.RELEASE/xd/config/modules/modules.yml (Too many open files)
I changed ulimit -n 60000, but it didn't solve the problem. The strange thing is why it still points to spring-xd-1.2.1.RELEASE? I have started both xd-singlenode and xd-shell under /opt/spring-xd-1.3.1.RELEASE
EDIT: add xd-singlenode running process output just to show it's pointing to 1.3.1:
/usr/java/default/bin/java -Dspring.application.name=admin
-Dlogging.config=file:/opt/spring-xd-1.3.0.RELEASE/xd/config//
/xd-singlenode-logback.groovy -Dxd.home=/opt/spring-xd-1.3.0.RELEASE/xd
-Dspring.config.location=file:/opt/spring-xd-1.3.0.RELEASE/xd/config//
-Dxd.config.home=file:/opt
/spring-xd-1.3.0.RELEASE/xd/config//
-Dspring.config.name=servers,application
-Dxd.module.config.location=file:/opt/spring-xd-1.3.0.RELEASE/xd/config//modules/
-Dxd.module.config.name=modules -classpath
/opt/spring-xd-1.3.0.RELEASE/xd/modules/processor/scripts:/opt/spring-xd
-1.3.0.RELEASE/xd/config:/opt/spring-xd-1.3.0.RELEASE/xd/lib/activation-
...
have you updated your environment variables? specifically XD_CONFIG_LOCATION based on the error shown above.
I am trying to install two bundles on Karaf. For one of the bundle i am getting error and when I see the bundle:diag i got below message. It is the same thing compaining in logs also. Similar kind of bundle already deploy and it has the same dependencies. first one is working but the for second bundle i am getting below error. any thoughts?
opendaylight-user#root>bundle:diag
videoweb (421)
Status: GracePeriod
Blueprint
2/10/16 6:07 PM
Missing dependencies:
(objectClass=org.osgi.service.http.HttpService)
2016-02-10 23:54:07.113 GMT+00:00 [Blueprint Extender: 3] ERROR o.a.a.b.c.BlueprintContainerImpl - Unable to start blueprint container for bundle com.xyz.videosdn.tesweb due to unresolved dependencies [(objectClass=org.osgi.service.http.HttpService)]
java.util.concurrent.TimeoutException: null
at org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336) [org.apache.aries.blueprint.core:1.4.0]
at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) [org.apache.aries.blueprint.core:1.4.0]
The error means that your bundle has a mandatory reference to a service with the interface org.osgi.service.http.HttpService.
So you need to install a bundle that provides this service. In karaf this service is normally provided by pax-web. It can be installed using:
feature:install http
I have (intentionally created situation to test my CI setup) a bundle which does not have all dependencies configured correctly. When I deploy that the deployment fails with an exception as it should:
2014-02-07 09:17:15,738 | ERROR | rint Extender: 3 | BlueprintCamelContext | 103 - org.apache.camel.camel-blueprint - 2.10.7 | Error occurred during starting Camel: CamelContext(ura) due "org.xmlsoap.schemas.soap.envelope" doesnt contain ObjectFactory.class or jaxb.index
javax.xml.bind.JAXBException: "org.xmlsoap.schemas.soap.envelope" doesnt contain ObjectFactory.class or jaxb.index
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.7.0_11]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_11]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_11]
at java.lang.reflect.Method.invoke(Method.java:601)[:1.7.0_11]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:143)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.ContextFinder.find(ContextFinder.java:310)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)[89:org.apache.servicemix.specs.jaxb-api-2.2:2.2.0]
at org.apache.camel.dataformat.soap.SoapJaxbDataFormat.createContext(SoapJaxbDataFormat.java:303)[206:org.apache.camel.camel-soap:2.10.7]
at org.apache.camel.converter.jaxb.JaxbDataFormat.doStart(JaxbDataFormat.java:254)[187:org.apache.camel.camel-jaxb:2.10.7]
at org.apache.camel.dataformat.soap.SoapJaxbDataFormat.doStart(SoapJaxbDataFormat.java:101)[206:org.apache.camel.camel-soap:2.10.7]
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)[100:org.apache.camel.camel-core:2.10.7]
at org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:62)
The problem is that the bundle status is still "Active". Why?
karaf#root> osgi:list
START LEVEL 100 , List Threshold: 50
ID State Blueprint Spring Level Name
[ 242] [Active ] [Created ] [ ] [ 80] integraatiot-foo (1.0.0.SNAPSHOT)
I would like to setup my CI builds to that they detect failed bundles using http://code.citytechinc.com/osgi-bundle-status-maven-plugin/. This idea fails since bundle status is always "Active".
The bundle is active because it has been activated. This is normal. If an error occurred in some code within the bundle, that is nothing to do with the OSGi active state.
So you need to work out some way to report your internal failure such that it can be picked up by a CI build. I suggest using the OSGi LogService.
You'll need to make sure all your dependencies are required and with the correct version.
In this case it might be that the package your importing does existing in the wrong version.
Or better did you make sure you only import the right version of the package with [2,3.0) for example. Especially the stack trace makes it suspicious to me that your using import without version range and therefore do import the JRE jaxb classes which usually do have version 0.0.0
To check which bundles are actually used for import log in the shell and do a bundle:header [bundleID]
Can anyone point to a step-by-step tutorial on how to configure a remotely-accessible service contained within Eclipse Virgo 3.0x? I know that standards exist, etc., but I can find NO example which does not seem to contain a bunch of hand waving instead of specific steps along with working code/configurations to download. I don't care if the example uses Apache CXF, Eclipse ECF, or just about anything else. What I want is the equivalent of RMI in that both the transport and wire protocol are abstracted away behind what appears to both client and server-side developers as just plain Java (with some liberties taken).
Which bundles must be deployed into Virgo to support remoting? What Spring-ish configuration settings work? What jars must be on the client-side classpath? Etc, etc.?
I played around with Apache CXF DOSGI and got it working quite easily.
Download CXF single bundle distribution from here - I used 1.3.0.
Unzip Virgo (I used the kernel distribution for simplicity), copy CXF bundle to pickup, and start Virgo:
$ bin/startup.sh
[2012-04-04 14:17:33.011] startup-tracker <KE0001I> Kernel starting.
[2012-04-04 14:17:36.135] startup-tracker <KE0002I> Kernel started.
...
[2012-04-04 14:17:38.561] sync Event Dispatcher Thread <UR0001I> User region ready.
[2012-04-04 14:17:39.565] fs-watcher <HD0001I> Hot deployer processing 'INITIAL' event for file 'cxf-dosgi-ri-singlebundle-distribution-1.3.jar'.
[2012-04-04 14:17:40.060] fs-watcher <DE0000I> Installing bundle 'cxf-dosgi-ri-singlebundle-distribution' version '1.3.0'.
[2012-04-04 14:17:40.570] fs-watcher <DE0001I> Installed bundle 'cxf-dosgi-ri-singlebundle-distribution' version '1.3.0'.
[2012-04-04 14:17:40.593] fs-watcher <DE0004I> Starting bundle 'cxf-dosgi-ri-singlebundle-distribution' version '1.3.0'.
[2012-04-04 14:17:43.498] start-signalling-1 <DE0005I> Started bundle 'cxf-dosgi-ri-singlebundle-distribution' version '1.3.0'.
Install and run ZooKeeper server according to these instructions - I used 3.4.3. See also the ZooKeeper instructions including how to create a configuration file.
Create a file org.apache.cxf.dosgi.discovery.zookeeper.properties containing:
zookeeper.host = 127.0.0.1
and copy to pickup:
[2012-04-04 14:29:51.385] fs-watcher <HD0001I> Hot deployer processing 'CREATED' event for file 'org.apache.cxf.dosgi.discovery.zookeeper.properties'.
[2012-04-04 14:29:51.417] fs-watcher <DE0000I> Installing configuration 'org.apache.cxf.dosgi.discovery.zookeeper' version '0.0.0'.
[2012-04-04 14:29:51.428] fs-watcher <DE0001I> Installed configuration 'org.apache.cxf.dosgi.discovery.zookeeper' version '0.0.0'.
[2012-04-04 14:29:51.434] fs-watcher <DE0004I> Starting configuration 'org.apache.cxf.dosgi.discovery.zookeeper' version '0.0.0'.
[2012-04-04 14:29:51.439] fs-watcher <DE0005I> Started configuration 'org.apache.cxf.dosgi.discovery.zookeeper' version '0.0.0'.
Unzip another copy of Virgo kernel,copy the CXF bundle and org.apache.cxf.dosgi.discovery.zookeeper.properties into pickup, and start with a different JMX port:
$ bin/startup.sh -jmxport 9876
That's it, but to check that it's working, the remaining steps run the greeter sample...
Install/start the greeter interface and implementation bundles into the first Virgo instance. The simplest way is to copy the interface bundle to repository/usr and then copy the implementation bundle to pickup.
Install/start the greeter interface and client bundles into the second Virgo instance. The simplest way is to copy the interface bundle to repository/usr and then copy the client bundle to pickup.
When the "Invoke Remote Greeter Service" window appears, enter a string (e.g. "foo") into the Name field and click "Invoke".
The first Virgo instance shows the following trace log messages (in serviceability/logs/log.log):
Invoking: greetMe(foo)
The second Virgo instance shows the following trace log messages:
[2012-04-05 14:14:56.766] INFO Thread-29 System.out *** Invoking greeter ***
[2012-04-05 14:14:56.970] INFO Thread-29 System.out greetMe("foo") returns:
[2012-04-05 14:14:56.971] INFO Thread-29 System.out Hola foo
[2012-04-05 14:14:56.971] INFO Thread-29 System.out Bonjour foo
[2012-04-05 14:14:56.972] INFO Thread-29 System.out Hoi foo
[2012-04-05 14:14:56.972] INFO Thread-29 System.out Hello foo
[2012-04-05 14:14:56.972] INFO Thread-29 System.out *** Opening greeter client dialog ***
Look in the service registry of the second Virgo instance.
osgi> vsh:service examine 245
Properties:
endpoint.id:
http://localhost:9090/greeter
objectClass:
org.apache.cxf.dosgi.samples.greeter.GreeterService
service.id:
245
service.imported:
true
service.imported.configs:
org.apache.cxf.ws
Publisher: cxf-dosgi-ri-singlebundle-distribution 1.3.0 [84]
Consumer(s):
cxf-dosgi-ri-samples-greeter-client 1.2.0 [86]
A remote GreeterService has been published in the service registry.
This may not be precisely what you are looking for, but I have every reason to believe that the instructions in the Remote Services chapter in Enterprise OSGi in Action should work with Virgo.