I am at the moment creating a matrix which is showing how far Knopflerfish, Equinox and Felix are OSGi 4.2 compliant.
So far I looked at the Knopflerfish documentation (Link 1, Link 2) to get an idea of how much of the Core and Compendium specs are actually implemented.
The core specification seems to be fully implemented, although there are some inconsistent statements about the Security Layer and the Declarative Services.
What makes me wonder is how much of all the Compendium specs are implemented:
Remote Services
Log Service
Http Service
Device Access
Configuration Admin Service
Metatype Service
Preferences Service
User Admin Service
Wire Admin Service
IO Connector Service
Initial Provisioning
UPnP Device Service
Declarative Services
Event Admin Service
Deployment Admin
Auto Configuration
Application Admin
DMT Admin Service
Monitor Admin Service
Foreign Application Access
Blueprint Container
Tracker
XML Parser Service
Position
Measurement and State
Execution Environment
To find out more I downloaded (Download page) the source code of Knopflerfish and had a look at it. It looks like some parts of the spec are implemented through the "original" framework provided by the OSGi Alliance (org.osgi.*).
One example is the UPnP package:
alt text http://img6.imageshack.us/img6/5853/screenshot20100403at212.png
Does this mean that missing parts which are not directly implemented by Knopflerfish are added through the "original" OSGi framework?
And does this also apply to other frameworks like Felix or Equinox?
Most of the OSGi specifications define interface classes for services. You can download these classes together with the specification directly from the OSGi Alliance's website.
Implementations such as Knopflerfish must provide the underlying functionalities, e.g. the actual implementation for the UPnP Service Admin you mentioned in your example. Some of the interface classes also provide interfaces that must be implemented by the developer of a user service, e.g. a BundleActivator.
All frameworks that claim to be OSGi compliant must provide implementations for these interfaces. There is no "original" OSGi framework (well, beside of the reference implementation, of course). The interfaces do not provide implementations.
Related
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 have deployed a Tuscany SCA component (developed in IBM Rational Application Developer) to WebSphere 8.5. It has a Web Service binding, with 5 methods. I want to apply different Policy Sets to each method. However, in the Admin Console, under Service Providers, I can only see the Service, and the Endpoint - ie No Operations are listed.
I can do this just fine at the Operation level with regular JAX-WS service components.
This is day 2 of trying to solve this. I've tried all of the SCA Annotations in the Java implementation code, but no joy.
Anyone got any ideas?
Not sure I'm following your question entirely, but here what I think is the answer.
In SCA, you don't define the policies at the Service Providers level, instead you can specify them in the SCA Composite file, at the implementation, services and/or references levels.
WAS Knowledge Center has comprehensive documentation about how to accomplish the task of adding and configuring Policies in SCA applications. Open this link and scroll down to the configure Security for SCA applications.
http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/welc6tech_sca_links.html?lang=en
You can have a better glance in this document, which is the SCA Policies spec
http://docs.oasis-open.org/opencsa/sca-policy/sca-policy-1.1.pdf
I am considering writing a new set of applications using OSGi, but they will need to interact heavily with existing non-OSGi applications.
To clarify, the new applications will need to call into existing non-OSGi code bases maintained by other teams (usually propriety services of varying protocols), and new non-OSGi applications will need to call the new OSGi services.
I am not seeing much documentation for how to do this.
Can someone please point me to the correct steps
It sounds like you want to embed OSGi into a larger application. A good starting point for this is a blog post I wrote some time ago: http://njbartlett.name/2011/07/03/embedding-osgi.html
The trick to creating visibility between OSGi bundles and the objects "outside" OSGi is to publish and/or consume services using the system bundle's BundleContext. The embedding code must be aware of the objects from the outer application that you want to make visible into OSGi, and it should publish them as services. Be aware that you need to export the service interface packages via the system bundle exports -- how to do this is described in the blog post.
OSGi services are only for communications inside the same JVM process. So I guess you want to communicate between processes. In this case you have all the usual remoting protocols like SOAP, Rest, RMI. On the OSGi side you can bridge from OSGi services to offering SOAP or REST endpoints using Distributed OSGi (DOSGi).
I’m currently “struggling” with OSGi services, or to be more specific, with the wiring between the services. I’m aware of the basics of DS, SCR and the general strategies for a component instance to acquire services. Anyway, here is my problem:
Following DS, components declare e.g. their provided and consumed services in a XML-file. In my case, I’m interested in the “consumed/referenced” services of a particular component (which are declared by the “Reference” tag in the component’s XML-file).
E.g. consider a running OSGi-application: a bunch of bundles collaborating with each other based on services (DS). Now, I want to pick a particular bundle and query all its references to the services it (may) consume - no matter if these services are currently available or not.
Referring to Apache Felix GoGo shell commands, like inspect requirements *, I do get information about the imported packages etc. but not a complete overview about the consumed services (-> both currently consumed services and services the component is waiting for).
I’ve read about the Framework API which provides insight in the registration, modification and deregistration of service but apparently, it does not provide the information about what services bundles are waiting for. Following the OSGi core specification, this could be achieved by a Listener Hook.
Isn’t there a way, where I just can query e.g. the SCR to get all referenced services of a specific bundle? Obviously, the SCR is supposed to read the bundle’s Service-Component-XML-file and to “register” some kind of “Service Tracker” to track the consumed/referenced services – hence the information of a bundle’s consumed/referenced services should somehow be available, shouldn’t it?
It would be great if you could help me with this.
Thanks,
Don
Checkout xray, http://softwaresimplexity.blogspot.com/2012/07/xray-again.html, from Peter Kriens.
I am trying to brand a Apache Felix web console, but I am not able to find resource for the same. As per Apache Felix website,
Branding for the Web Console can be provided in two ways: By registering a BrandingPlugin service or by providing a branding properties files. The Web Console uses the branding from the BrandingPlugin service registered with the highest ranking.
But I am not understanding how to register a BrandingPlugin service? What and Jar files should I put? Is there any guidance or tutorial available for the same? If yes, can you guide me in this?
Since I am totaly getting confused with Apache Felix's website, since those documents are not clear on this.
You may find it helpful to do some background reading on OSGi services. OSGi provides a service registry, and most interactions in an OSGi environment are handled by registering and consuming services. It doesn't matter what jar file you put the service in; the only thing that matters is the interface name its registered under.
You can register services in lots of ways; programmatically from a BundleActivator, using Declarative Services (also known as SCR), and using Blueprint are some of the most popular patterns. Which one is easiest for you depends on how you're building your jars and what other OSGi facilities you're using. If you've already got an Activator the programmatic route may be the quickest way to get started; if you're using the Maven bundle plugin you may find SCR annotations easiest.
What you'll need to do is include an implementation of the 'BrandingPlugin' interface in a jar which gets started by your OSGi runtime, and register that implementation as an OSGi service. Once you've done this you should see that the Felix console discovers your BrandingPlugin implementation and uses it.