This is a little embarrassing considering I have been meddling around with Karaf for a while now.
I have a service implementation bundle and a CXF-REST bundle. If I throw in the REST bundle before the ServiceImpl bundle into my deploy folder, it waits for the service bundle for a few seconds and then goes into a Failed state. Obviously, all goes well if I do it in sequence - ServiceImpl first and REST next. I wanted my REST service to wait forever until the ServiceImpl is deployed (just like the rest of the OSGi bundles)
My guess is that there is some place where I should be increasing the timeout to wait forever. This guess is based on the fact that for a PaxExam test, I should do so.
#Inject
#Filter(timeout = 300000)
BootFinished bootFinished;
(source : KarafTestSupport.java)
Am I looking at the wrong place or should I be looking at other places for hints like Activator or Export/Import packages?
I understand that deploying as a .kar file along with the the rest of the libraries (I deploy the dependencies as a .kar) would solve it but I do not want to do that for the REST and Impl bundles because of faster deployments (and bandwidth sizes - I am on EC2).
Earlier I didnt have any timeout set.
<reference id=“xxxServiceBean"
interface="com.nutraspace.coreservices.search.service.impl.base.NewsSearchService">
</reference>
Now that I have set it to 10 minutes, it works great. Tested and verified.
<reference timeout="600000" id=“xxxServiceBean"
interface="com.nutraspace.coreservices.search.service.impl.base.NewsSearchService">
</reference>
Here's the link to the thread
http://karaf.922171.n3.nabble.com/Waiting-for-dependent-bundle-td4032415.html
Related
I am having three modules in my Maven project:
parent
rest-api # Spring REST API
web-client # AngularJS web client
application # Project to bundle it all up for a standalone
I am not sure if I have here an "elegant" solution so please hit me with a stick if that is complete garbage, but this is how it works - or how it's supposed to work:
rest-api
Module rest-api does simply offer the REST API and other core functionality - basically it is pure server code. It is a jar artifact.
web-client
To separate client and server code I am having the module web-client. It is a war project that hold the client webapp.
application
This module is supposed to glue it all up. It depends on rest-api and web-client. It does two important things:
It's pom.xml uses the spring-boot-maven-plugin to build a standalone runnable jar - my ultimate goal
It provides the main(String args[]) method that starts the #SpringBootApplication with SpringApplication.run(EasyModelAccessServer.class, args);
What I am currently able to is tell Eclipse to run this in a servlet container. The server boots up and I my two resources, the rest-api and the web-client working. Everything is fine so far.
The issue
What is not fully working is the standalone. If I package up the whole thing and run the server:
$ path/to/application: mvn clean package
$ path/to/application: java -jar target/application.jar
Only the REST API will work. The reason is because the web-client is not added or introduced as a web app to the Spring built-in Tomcat.
The question
is how I can make this work. There are two options which come to my mind:
Somehow sneak in the web-client.war file into the application.jar such that it is available as a resource and programmatically call tomcat.addWebapp("/web-client", "path/to/web-client.war") (or something like that) to load the additional service
Hope that the spring-boot-maven-plugin or another Spring Maven plug-in can do that for me and find somebody that links me to an example.
I've tried it with 1. but I didn't succeed to move web-client.war into application.jar but I am also not sure if I should actually do that.
FAQ
Q: "Why do you separate everything instead of merge all those modules into a server module where the Spring Maven plug-in would do everything for you out of the box?"
A: I really want to separate the client code from the server code. I could however merge web-client into application but last time I tried that I had 10 other issues why this did not work out so I decided to keep it that way and that it actually shouldn't be so hard to load an additional server resource.
Q: "Can I take a look at the project?"
A: Yes, you can. Just take a look: https://github.com/silentsnooc/easy-model-access Please forgive me that I am currently using tabs instead of whitespaces - I am going to change that as soon as I got everything up and running.
Before I call service from another bundle I would like to search for this service availability because I will get NPE.
What is the proper way to search for a service?
ServiceReference serviceReference = bc.getServiceReference(someclass.class.getName());
if (serviceReference == null)
{
throw new RuntimeException("Missing service someclass, please start bundle <name>");
}
else
{
kernelsManager = (someclass) bc.getService(serviceReference);
}
I would like to shutdown the framework if the service is not found. What is the proper to to do this? Can I improve somehow the above example?
This is not as easy as that in OSGi. As the bundle containing the service could be started after the bundle using the service you should account for that dynamic. Simply checking if the service is present at a single point in time is not good enough.
You can achieve this by using a ServiceTracker. If the service is added you initialize your own class that depends on it. If it goes down you stop it. If you have more than one service dependency this is quite complicated though.
So in bigger cases better use a framework like Declarative Services or blueprint that automates this for you.
As an addition to the answer by Christian, note that shutting down the framework simply because a service is unavailable, is bad practice. OSGi is dynamic by design, meaning that services may come and go, so your bundle should be able to deal with the situation that a service is not (yet) available or disappears and re-appears. Otherwise, I really don't see the purpose of using OSGi in the first place.
I have a problem on 2.2.8 version of Karaf (and most probably on the earlier versions too).
I'm going to use Karaf to host the system with dynamically deployed bundles. Bundles are deployed by users and i cannot know beforehand which are they.
I expect order of the BundleActivator.start() to exactly correspond to package dependencies between bundles (dependencies of import/export packages) and planning to expect that it will be safe to assume that bundle0 will be completely initialized before bundle1 is going to be started. But it is not so - it seems that BundleActivator.start() is invoked in a "random" order and disregards package dependencies between bundles.
Sample use-case, I have 3 libs
test-lib0 - defines testlib0.ITestRoot, exports testlib0 package
test-lib1 - defines testlib1.TestRoot implements ITestRoot, exports testlib1 package
test-lib2 - uses both libs, ITestRoot and TestRoot
When Karaf is started, i see following sample output in console
karaf#root> TestLib1Activator.start()
TestLib2Activator.start()
ITestRoot: interface com.testorg.testlib0.ITestRoot - 16634462
TestRoot: class com.testorg.testlib1.TestRoot - 21576551
TestLib0Activator.start()
but i expect it should be always in this order
TestLib0Activator.start()
TestLib1Activator.start()
TestLib2Activator.start()
ITestRoot: interface com.testorg.testlib0.ITestRoot - 16634462
TestRoot: class com.testorg.testlib1.TestRoot - 21576551
I'm attaching sample project for tests. Test case: after "mvn install" just move jars from ./deploy folder to the same folder of Karaf, trace messages should appear in console.
(Note: it may work correctly from the first attempt, try one more time then :))
Sample test project
http://karaf.922171.n3.nabble.com/file/n4025256/KarafTest.zip
Note: this is cross-post from http://karaf.922171.n3.nabble.com/What-is-the-natural-start-order-for-dependent-bundle-td4025256.html
In OSGi the bundle lifecycle is installed → resolved → starting → started.
Import-Package and Export-Package only influence when the bundle goes from installed to resolved. So the framework makes sure all bundles you import packages from are resolved before your bundle but then your bundle only goes to the resolved state. Then in a second step the activators are called. So you can not assume the activators are called in the same order. If you need some initializations before your testlib2 can work then you should use OSGi services.
So If I understood your case correctly then you testlib0 defines an interface, testlib1 implements it and testlib2 wants to use the implementation. So the best way to achieve this is to publish the impl as an OSGi service in testlib1 and reference this service in testlib3. You can then use the service with a ServiceTracker or with e.g. blueprint. I have a small example that shows this: http://www.liquid-reality.de/x/DIBZ . So if you do your case like in my example blueprint makes sure that the context of testlib2 only gets started when the service is there. It will even stop testlib2 when the service goes away.
I'd like to create a Configuration object in OSGi, but one that won't be persisted, so it won't be there when the framework is restarted. Similar to START_TRANSIENT for bundles.
Some background: I've got an OSGi (Felix) based client side application, deployed over OBR. The configuration object I'm talking about effectively boots the application. That works fine, but sometimes the content has changed while the context was stopped. In that case, it boots the application as OSGi revives all bundles and adds all configuration options. Then I inject the correct configuration, the application stops and then restarts again.
So it does actually work, but the app starts twice, and I can't get access to the framework before it reconstructs its old state.
Any ideas?
As BJ said there is no standard support for this in the Configuration Admin spec.
However the Felix implementation supports two features which may help you. First, you can set the felix.cm.dir property which configures where the configadmin saves its internal state (which by default will be somewhere under the Framework storage directory). You could set this to a location that you control and then simply wipe it every time you start OSGi (you could also wipe out the entire OSGi Framework storage directory on every start... some people do this but it has wider consequences that what you asked for).
Second, if you need a bit more control, Felix ConfigAdmin supports customising its persistence with a PersistenceManager service. You could probably implement this and return empty/doesn't-exist for the particular pids that you want to control.
The OSGi Config Admin spec does not support this. I also do not know of a non-standard means either for any of the CM impls I am familiar with.
Ok, what I did in the end was the following:
I created a special really small 'boot' bundle, which I do not provision from OBR, instead, I install it from the classpath.
That bundle controls the configuration, and I use START_TRANSIENT the moment I really want to load that configuration.
Not exactly pretty, it gets the job done. I do think transient configuration would make sense to have in OSGi.
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.