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.
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 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.
We run Restlet 2.1 in an OSGi environment (Equinox) as bundle (ie. not as library within a bundle). The problem is that the Restlet Engine does not detect helpers (like converters) that are provided by Restlet extensions. Specifically, the EngineClassLoader#getResources() call does not return any result. The extensions are also deployed as OSGi bundles in the target platform.
Is automatic converter registration actually supposed to work within OSGi environments?
In fact, Restlet supports such feature thanks to a dedicated activator (see the Activator class in the package org.restlet.engine.internal).
This activator introspects bundles to find out the following things:
servers corresponding to registered servers
servers corresponding to registered clients
authenticators corresponding to registered clients
converters
Be aware that to use this feature, we must use the OSGi edition of Restlet since it's the only that has the MANIFEST file of the org.restlet bundle with the activator class specified. Otherwise you don't have to care about the bundle loading order...
Hope it helps you.
Thierry
Unless the Restlet-bundle explicitly imports the packages that contain the extensions (and I doubt it does, and it shouldn't), it wouldn't be able to load them, because bundles have isolated class-spaces.
A possible solution would be to provide the extensions as fragments attached to the Restlet-bundle. Thus, if you make it use the bundle-classloader (the documentation says this can be done by setting the Engines classloader), it would be able to load classes from the fragments.
Indeed it doesn't quite work for OSGi, as it depends on the ability to see the entire class space.
The way to do this in OSGi would be to use the service registry for the extensions, but that only works for OSGi aware libraries.
There is some help on the way: In the recently released OSGi 5 (Service Loader Mediator) there will be support to 'bridge' META-INF/services (I don't know if Restlet uses those, though) onto OSGi services, so 'legacy' libraries should work well within OSGi.
There is an implementation in Apache Aries called Spi-Fly. I looked at it briefly a while back. It might do the trick for you, it might not.
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.