I want to use Sling scheduler as a bundle in my Eclipse Equinox Environment and now trying to just run the examples, both whiteboard or via API without success. After lots of debugging I have now been able to make it work but I had to make a change in the scheduler bundle in QuartzScheduler and change the reference to MetricRegistry to add optional cardinality:
#Reference(cardinality=ReferenceCardinality.OPTIONAL)
MetricRegistry metricsRegistry;
which otherwise makes the service fail to start on Equinox.
Running tests in the bundle it seems that this is also never resolved even with Felix, but in that case the service still starts. I should also note that MetricRegistry doesn't appear to be a service and I can't understand why it would be instantiated via #Reference. Actually changing the line to:
MetricRegistry metricsRegistry = new MetricRegistry();
will correctly retrieve the metricsRegistry in all cases, Felix or Equinox.
Have I uncovered a bug or there is something I don't understand?
In Apache Sling a MetricRegistry instance is registered from the org.apache.sling.commons.metrics bundle, see MetricsServiceImpl#activate. You should deploy this bundle in your OSGi container.
Related
I have a non-blueprint bundle which provides a service via Declarative Service annotations.
I have another bundle, using blueprint, which contains a optional reference for this service and then injects this reference into a number of declared beans.
Starting up both within a Karaf container, the service is registered and the blueprint bundle can access it and use as intended. The configuration for the service providing bundle can be updated, and it is unbound and rebound again to the blueprint bundle which is perfect.
However, when the service providing bundle is restarted, or updated, the service is unbound but never rebound to the using bundle, so that the proxy object held by the blueprint reference never resolves to the service reference.
Sometimes restarting the blueprint bundle will fix this, but usually it requires a full framework restart to get it working again.
I do not get the same behavior when a non-blueprint bean is consuming the service via declarative services.
Has anyone had any similar issues with using a mix of DS and blueprint to provide/consume services?
Blueprint is not dynamic. It has a "damping" proxy which tries to wallpaper over service dynamism but does not always provide what is needed. In general, I would always use DS over Blueprint.
I have a sling Servlet (and various other components) running inside an OSGi bundle inside AEM / Apache Felix.
eg:
#SlingServlet(
label = "XXXX - SSO Post Servlet",
metatype = true,
methods = {"POST"},
name = "XXXX.core.components.SlingPostServlet",
paths = {"/services/SSOPost"}
)
public class SlingPostServlet extends SlingAllMethodsServlet {
//etc
My components work as expected, maven is able to build, bundle and deploy the entire project fine.
My issue is that updates to my components are not activated until I restart the entire AEM instance. I have tried refreshing OSGi packages, restarting the bundle, and as many likely UI actions to achieve this effect as I can think of, but no luck.
Any ideas? I'm hoping its a simple config issue/ button I am not aware of.
Thanks.
The bundle is started but the event might not be active. It should get activated when the service is actually used. We can use the #Component(immediate=true) annotation to activate the component when the bundle gets started
Try deleting the old jar first, and then deploy the new jar. This works for me most of the times, but not always.
I've been using Maven to deploy my bundles over a felix server.
One of the things that fascinates me about Felix/OSGi is if i have configured a component with some values and i deploy my bundle again, even though the #Activate method will be called again for that configuration but my values which i've put there before deployment still persist.
How is Felix able to achieve this and is the configuration shown at /system/console/configMgr not an instance of my Java class used to create the OSGi Component ?
It's the job of the Configuration Admin service (for which Apache Felix provides an implementation) to deal with those details. Ideally, the "how" is irrelevant because those are implementation details, but if you are running an OSGi framework in a specialized environment (an embedded device for example), you would have to select a Configuration Admin provider that works within the limits of the host platform.
Under the hood, the Felix Configuration Admin service uses one or more PersistenceManagers to persist and retrieve the configuration data for your managed services. If you're curious about these implementation details you can read about them on the Felix website or you can take a look at the source code.
The configuration is OSGi is handled by the Configuration Admin Service
If you use OSGi container such as Karaf, you will remark that your configuration is independent from your bundle ($KARAF_HOME/etc) and are injected by the configuration admin service.
As was already said, Configuration Admin is your friend here. In OSGi enRoute we've a page about Configuration Admin and a sample project with lots of Configuration Admin example code.
I am able to get OSGi blueprint to work in Karaf, but I don't understand how to do it in Apache Felix, or my question can be also defined as how can I use OSGi blueprint in plain OSGi?
I made an example here https://github.com/PhilAndrew/sbt-osgi-felix-akka-blueprint-camel using https://github.com/doolse/sbt-osgi-felix in which Akka is working but Blueprint and Camel not yet working.
This question may help Is Apache Aries running in Felix?
It's not starting Blueprint because your bundle's code doesn't actually rely on any of the classes in blueprint, so you either need to add "Require-Bundle" header to your manifest:
requireBundle := Seq("org.apache.aries.blueprint")
or add the bundles that needed to be started to the osgiDependencies of run:
osgiDependencies in run := bundleReqs("org.apache.aries.blueprint.core",
"org.apache.aries.proxy")
Apache Karaf also runs on felix. So for the most part you just need to install the correct bundles and maybe do the necessary system package exports if you hit package use constraint violations.
Check what karaf installs and try to do the same.
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.