My team is using Geronimo 3 and osgi to develop applications. When our own osgi bundle or eba fails in Geronimo, I need to track the detailed failure information. Is there any API I can use to do this? Currently I could only do it by checking error stacktrace in geronimo log which is extremely not precise.
thanks,
Chandler
I added such a command to Karaf 3. It is called bundle:diag and shows the failure information for all bundles including blueprint and spring dm failures. As soon as Karaf 3 is released and geronimo switches to it you can use this. You can already try a karaf 3 snapshhot to see how it works.
Related
I am trying to launch the Felix OSGI Framework using AutoProcessor.process(...) to load my OSGI bundles. I have specified the directory containing the bundles using the felix.auto.deploy.dir property.
When that directory is empty I get no messages at all from Felix. When there are bundles in it I get a not very helpful stack dump.
How does one tell the Felix framework to output logging/debugging information? What I really want is for AutoProcessor to tell me which bundle it is working on when the stack dump occurs.
I have tried setting felix.log.level to 4; I have tried setting up an org.osgi.framework.FrameworkListener and an org.osgi.framework.BundleListener; and I have tried specifying a Logger with felix.log.logger; but Felix remains stubbornly taciturn.
So what's the secret trick?
After removing the duplicate org.osgi.core bundle as mentioned above, I tried once more to set up
an org.osgi.framework.FrameworkListener,
an org.osgi.framework.BundleListener, and
an org.osgi.framework.ServiceListener
on the framework that I had created. All 3 listener types fired and I was able to examine and log information from the events passed in as arguments.
I am trying to develop an application that can be configured by its users. I need the configuration to be done by installing/updating/stopping/uninstalling bundles. All this should be of course done dynamically during the run-time of the application.
I found a nice framework which is Apache Felix FileInstall that provides a directory in which it seems to add a bundle when you add the bundle file in the directory (update, and remove bundles similarly).
But I can see that this method does not work in my case. I need to have the bundles in the directory but to stop or even uninstall them by my application. And I want to install them when it is appropriate. This is how I am expecting the configuration of my application to be done.
Is what I am trying to achieve supported by Apache FileInstall? Am I making any wrong assumptions about this framework? What are other possible ways that would help me if Apache FileInstall is not enough? Thanks.
You don't need FileInstall for this, just use the OSGi APIs. You specifically mentioned installing, updating, stopping and uninstalling; these are supported with the following API calls respectively:
BundleContext.installBundle
Bundle.update
Bundle.stop
Bundle.uninstall
Incidentally these are exactly the same methods that are called by FileInstall to implements its directory-based bundle management.
I want to use glassfish 3.1.2.2 with OSGI for my development purposes. I installed OSGI Future pack over web administration console and restarted glassfish. After server restarting the web console stopped to work and shows me only a blank page without any errors. I looked in a log file and found there exception described bellow.
I had a number of questions:
How to replace start level of this bundle and which level it is necessary to set?
How to get access to Apache Felix's shell?
Whether it is possible to marry glassfish and karaf?
[org.glassfish.main.admingui.glassfish-osgi-console-plugin(Glassfish OSGI Console Plugin):3.1.2.1-SNAPSHOT]
com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [263] State [RESOLVED] [org.glassfish.main.admingui.glassfish-osgi-console-plugin(Glassfish OSGI Console Plugin):3.1.2.1-SNAPSHOT]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
at com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
at com.sun.enterprise.v3.server.ClassLoaderHierarchyImpl.createApplicationParentCL(ClassLoaderHierarchyImpl.java:200)
at org.glassfish.deployment.common.DeploymentContextImpl.createClassLoader(DeploymentContextImpl.java:216)
at org.glassfish.deployment.common.DeploymentContextImpl.createDeploymentClassLoader(DeploymentContextImpl.java:199)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:346)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.load(InstallerThread.java:210)
at com.sun.enterprise.v3.admin.adapter.InstallerThread.run(InstallerThread.java:108)
Caused by: org.osgi.framework.BundleException: Cannot start bundle org.glassfish.main.admingui.glassfish-osgi-console-plugin [263] because its start level is 2, which is greater than the framework's start level of 1.
at org.apache.felix.framework.Felix.startBundle(Felix.java:1807)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
... 12 more
This is a well known issue [1] and it has been fixed in GlassFish trunk. A work around is available for 3.1.x release as well.
[1] http://java.net/jira/browse/GLASSFISH-18880
Is anyone using Karaf instead of Servicemix? If so, how did you come to this decision? I'm aware that Servicemix adds a layer of functionality around Karaf, just curious if Karaf is being used on its own and why...
We're using Karaf for a number of our applications. We were already using Camel (JMS and Esper) for integration between several different platforms (a JBoss 4.2 instance, a Tomcat and several Felix instances) and as this was working well there was little justification in migrating this too (which would have been cause to consider ServiceMix).
The only reason we have some Felix nodes, is that they're limited in use (on client desktops), rarely need/get updated and I wanted the smallest footprint for these nodes. For anything OSGi on the serverside we're using Karaf.
Karaf provides all of the features you'd expect and need for a production environment (see the apache-karaf tag's info). We do our development and testing against standard minimal framework (using pax-exam) but deploy to Karaf.
If you don't need an ESB, JCA, BPEL, etc but want a solid, tunable OSGi container, then Karaf on it's own is more than adequate. (And if you found yourself needing a limited subset of ServiceMix's functionality you can always install these in a Karaf instance).
You can also customise the Karaf distribution as part of a maven build - personally I like have the container as part of the application's build, as I can checkout, build and run the entire setup from the command line in minimal time.
Recently there's a clustering subproject of Karaf called Cellar using HazelCast, I not sure if this applies to ServiceMix too.
Karaf's life started as the ServiceMix core. Currently, ServiceMix is really a set of bundles that are deployed into a Karaf container. ServiceMix has a number of very handy bundles which do a lot of cool stuff that karaf doesn't. That said, the two primary reason for using ServiceMix is if you want:
1) an ESB,
2) NMR (a feature that allows you to community between bundles AND instances of Karaf).
This all said, the ServiceMix group is currently planning version 5, which will remove the ESB and NMR features and will be focused on being a management container for Camel. In ESB's a great deal of effort when into creating components that could be described using BPL (Business Process Language). However, the folks that wrote ServiceMix began to focus on the implementation of EIP's (Enterprise Integration Patterns) which largely does the same stuff as BPL, but does it in a more standardized and accepted manner. This work was done under the Camel project.
So, in short. If you are using ServiceMix 4+, you're also using Karaf. If you want a more robust integration environment, the environment of choice today (in the Apache/Felix world at least) is Karaf, Camel, and a few bundles from Servicemix.
Here's a little comparative illustration I made. Going from the simplest case (JVM with OSGi functions provided by Apache Felix at the bottom), to more complete/manageable OSGi functions (Apache Karaf in the middle), to enough functions to implement complete ESB instances (Apache ServiceMix at the top) (note that "an ESB" is not a product but a set of endpoints, routers, databases, ETL functions and whatnot configured together in a particular task-specific way).
Karaf does NOT come with CXF.
Its pure extracted kernel of ServiceMix. However, you can install CXF on Karaf as below.
karaf:root()> feature:repo:add cxf
Once the feature URL is added we can see the "provided" features by using the following command.
karaf:root()> feature:repo:feature:list | grep cxf
To install cxf fire the command below
karaf:root()> feature:install cxf
This is cross posted from the fusesource forum and the servicemmix forum.
I can't get DOSGi working in FUSE. I'm trying to get CXF's DOSGi 1.1-SNAPSHOT with Zookeeper discovery onto FUSE 4.1.0.2. I'm also using Zookeepr 3.2.1.
Everything works perfectly on Felix 2.0.0. I just follow the instructions on the DOSGi Discovery page and then install the Discovery Demo bundles. For DOSGi, I just use the cxf-dosgi-ri-singlebundle-distribution-1.1-SNAPSHOT.jar for DSW and cxf-dosgi-ri-discovery-singlebundle-distribution-1.1-SNAPSHOT.jar for zookeepr discovery. Then when I start the sample bundles with the sample service impl on one machine, I see the node creation in zookeeper. Then I start the sample client on another machine and I see the output on the service machine. Works great. I do have an warning about an xml error being ignored because some XSD coudln't be found, but it doesn't seem to affect anything. Oh, I also have to install the OSGi compendium bundle first.
When I move to Fuse, I have no such luck. The OSGi compendium bundle comes with fuse, so no need to install that. I should just be able to install the dosgi-ri singlebundle, and the dosgi-ri-discovery single bundle, but that doesn't work. The dosgi-ri singlebundle has all kinds of overlapping bundles with servicemix. I get an error about port 8081? or whatever the osgi.http.service parameter is, being already in use. Apparently the dosgi-ri singlebundle comes with pax webservice, which reads the same property as the servicemix http service bundle that comes with servicemix. Thats when I switch to the cxf-dosgi-ri-multibundle-distribution-1.1-SNAPSHOT.zip and unzip it to take the parts I want. I take the dsw bundle out of the dosgi-ri multibundle and install that. No luck because of the jdom dependency. Then I install the jdom that comes in the ri multibundle, which works fine. Then go back to dsw, and that installs, so I think i'm getting somewhere. Time to go back and install the ri-discovery singlebundle. When I start that I get a pax logging service classcastexception saying it can't be cast to a osgi logservice or something. But thats just a logging error, and at the bottom it says it can't find the transport class for http://schemas.xmlsoap.org/soap/http. Ok, so logging is screwed up and I'm missing some transport class. Well, clearly this comes from not installing enough from the ri multibundle because it worked on felix. So what else in there is necessary. The cxf-minimal-bundle upon inspection has the missing class causing that last error. So I install that. Try to start the discovery bundle, but I end up with some kind of corbabroker exception. Wtf. Whose using corba in all of this? Then I go back and undo all of that and try to stick with the singlebundle distros of ri and ri-discovery, but just turn off the servicemix http service. That crashes servicemix and I can't restart it becauuse the cxf jbi components end up with an unsatisfied dependency. Odd. I'll just ignore that because I don't use those anyway, and try to start my samples. Can't start the samples because it says jetty can't start because the ports already in use. Doesn't make sense because I shutdown the servicemix http service already. Then I restart jetty. Works? Maybe. My service gets registered and I can browse to the wsdl using firefox, but no registration in zookeeper. Try to shutdown the ri-discovery bundle and restart it, but I get a nullpointerexception. Appparently the ri-discovery never actually started up due to one of the aforementioned errors. Then I started trying to take apart the ri-discovery singlebundle and pull out the internals. That didn't work because its all apparently necessary, even though theres some libs inside we could do without.
End of the story. Can't get it to work. Can anybody else get it to work? I just want to run the discovery samples in SMX4. I'm pretty sure its just a bundle conflict problem. Isn't this what OSGi is supposed to fix??? This is worse than just telling me what jars you depend on and making me setup my classpath. At least then I'd eventually get the thing running.
My next steps, I think, will be to try again with the ri-multibundle, just the dsw and jdom, plus the ri-discovery singlebundle. Then I'll try some of the cxf-fuse bundles or some of the cxf-rt bundles to get around the soap transport issue.
Edit notes: I need more than just showing the DOSGi bundles in an Active state. They don't actually do much until you try to expose a service through them. I do need to see multiple machines registering services with a zookeeper instance and other machines consuming those services -- just like the running DOSGi Discovery Sample.
I've been able to get cxf to expose the distributed service sample as a soap webservice by using the minimal cxf bundle mentioned by either removing parts of the original cxf bundles and restarting the jetty service, and then starting the sample service... or by installing the cxf minimal buundle, then starting my service, then immediately uninstalling the cxf minimal bundle, then restarting jetty... I think that was the order. Neither of these will work from a clean startup, and having to restart services as a procedure to get DOSGi working is just bad. I don't even know why installing then uninstalling would do anything -- it shouldn't be leaving any artifacts around.
First point, looking at the CXF DOSGi mega-bundle I think this is only for quick-n-dirty hacking in a bare OSGi runtime, basically the minimal environment provided by Equinox and Felix. It will not be intended for richer environments like FUSE or Servicemix as you will likely clash on services from the bundle and the platform, as you appear to have seen.
I was able to get Servicemix 4.0 to start cleanly (this is on Windows) and then I hot-deployed:
com.springsource.org.jdom-1.0.0.jar
cxf-bundle-minimal-2.2.1.jar
cxf-dosgi-ri-discovery-local-1.0.jar
cxf.dosgi-ri-dws.cxf-1.0.jar
Using the Servicemix console I listed all bundles and saw that all of the above were in the Active state (as expected). I listed the services and the 2 CXF DOSGi bundles were exporting services, so that appeared to have worked correctly. No errors were reported in the log.
How familiar are you with OSGi? Servicemix looks quite large and learning OSGi, Servicemix and CXF/DOSGi together isn't going to be easy (in my opinion).
The supplied console isn't great for the OSGi stuff and I'd suggest installing the Apache Felix console bundles for a web interface.