Dependency Manager - Design Patterns :: Apache Felix
Home
Subprojects
Dependency Manager
Event Admin
File Install
Framework
Gogo Shell
Health Checks
Inventory
Log
Logback
Maven bundle plugin
Maven SCR plugin
Metatype Service
Preferences Service
Remote Shell
Script console plugin
Lightweight shell
Shell TUI
Web Console
Downloads
Documentation
Documentation
Downloads
Getting Started
News
Community
Apache Felix Project Info
Contributing
Projects Using Felix
Development
Coding Standards
DEPENDENCIES file template
Provisional OSGi API Policy
Release Management
Site How To
Using the OSGi Compliance Tests
FAQS
Apache Felix Bundle Plugin Frequently Asked Questions
Apache Felix SCR Plugin Frequently Asked Questions
Subprojects
Apache Felix Dependency Manager
Guides
Apache Felix Dependency Manager - Migrating from earlier versions
Dependency Manager - Annotations
Dependency Manager - Background
Dependency Manager - Bundles and Dependencies
Dependency Manager - Design Patterns
Dependency Manager - Development
Dependency Manager - History
Dependency Manager - JavaDocs
Dependency Manager - Migrating from other solutions.
Dependency Manager - Performance Tuning
Dependency Manager - Resource adapters
Dependency Manager - What’s new in version 4?
Dependency Manager Lambda
What’s New in R15
Reference
Dependency Manager - Adapter
Dependency Manager - Aspect
Dependency Manager - Bundle Adapter
Dependency Manager - Bundle Dependency
Dependency Manager - Components
Dependency Manager - Configuration Dependency
Dependency Manager - Dependencies
Dependency Manager - External Links
Dependency Manager - Factory Configuration Adapter Service
Dependency Manager - Resource Adapter
Dependency Manager - Resource Dependency
Dependency Manager - Service Dependency
Dependency Manager - Service Scopes
Dependency Manager - Singleton Component
Dependency Manager - Thread Model
Dependency Manager Annotations
Tutorials
Dependency Manager - Annotations
Dependency Manager - Getting Started
Dependency Manager - Leveraging the shell
Dependency Manager sample projects
Apache Felix Event Admin
Apache Felix File Install
Apache Felix Framework
Apache Felix Framework Bundle Cache
Apache Felix Framework Configuration Properties
Apache Felix Framework Frequently Asked Questions
Apache Felix Framework Launching and Embedding
Apache Felix Framework Usage Documentation
Apache Felix Framework Security
Apache Felix Gogo
RFC 147 Overview
Apache Felix Health Checks
Apache Felix Inventory Printer
Apache Felix Log
Apache Felix Logback
Apache Felix Maven Bundle Plugin (BND)
Apache Felix Metatype Service
Apache Felix OSGi Bundle Repository (OBR)
Apache Felix Preferences Service
Apache Felix Remote Shell
Apache Felix Shell
Apache Felix Shell TUI
Apache Felix Web Console
Extending the Apache Felix Web Console
Web Console RESTful API
Web Console Security Provider
Extensions
Branding the Web Console
Providing Resources
Providing Web Console Plugins
Web Console Logging
Web Console Output Templating
Tutorials
Apache Felix Application Demonstration
Apache Felix OSGi Tutorial
OSGi Frequently Asked Questions
OSGI Tutorial
Apache Felix Tutorial Example 1 - Service Event Listener Bundle
Apache Felix Tutorial Example 2
Apache Felix Tutorial Example 2b
Apache Felix Tutorial Example 3
Apache Felix Tutorial Example 4
Apache Felix Tutorial Example 5
Example 6 - Spell Checker Service Bundle
Example 7 - Spell Checker Client Bundle
Example 8 - Spell Checker Service using Service Binder
Example 9 - Spell Checker Service using Declarative Services
Apache License 2.0
Site map
Documentation
master
Documentation
master
Documentation
Subprojects
Apache Felix Dependency Manager
Guides
Dependency Manager - Design Patterns
Edit this Page
Dependency Manager - Design Patterns
This section lists a couple of design patterns as they can be applied in an OSGi context.
Singleton Service
Provides a service as long as its dependencies are resolved.
Motivation
In a dynamic framework, services can come and go.
Components that publish a service are often themselves dependent on other services to perform their task.
In such cases, they have a dependency on those services and it makes sense to only publish their own services when these dependencies are available.
Being able to declare such dependencies in code ensures consistent life cycle behavior.
Structure
requires
publishes«Singleton»Repository
get(key) : objectstore(key, object)
Code Example
public class Activator extends DependencyActivatorBase {
public void init(BundleContext context, DependencyManager manager) throws Exception {
manager.add(createComponent()
.setInterface(UserStore.class, new Properties() {{ put("store.id", "users"); }})
.setImplementation(UserStoreImpl.class)
.add(createServiceDependency()
.setService(Store.class)
.setRequired(true)
)
.add(createServiceDependency()
.setService(LogService.class)
.setRequired(false)
)
);
}
public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
}
Aspect Service
Provides an aspect on top of a specific type of service.
Motivation
In aspect oriented programming, supporting functions are isolated from the main application’s business logic.
This increases modularity at the source level by allowing the separation of cross-cutting concerns.
In OSGi we want to extend this modularity to the runtime, therefore we implement aspects to work on certain services, where the aspect itself publishes that same service but (usually) with a higher priority.
This allows you to dynamically add and remove aspects.
Structure
intercepts
publishes«Aspect»RepositoryCache
get(key) : objectstore(key, object)
Code Example
public class Activator extends DependencyActivatorBase {
public void init(BundleContext context, DependencyManager manager) throws Exception {
manager.add(createAspectService(Manageable.class, "(monitor=true)", 50)
.setImplementation(ManageableMonitor.class)
);
}
public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
}
public interface Manageable {
public void setProperty(String key, String value);
}
public class ManageableMonitor implements Manageable {
private volatile Manageable m_manageable;
public void setProperty(String key, String value) {
System.out.println("Someone set " + key + " to " + value);
m_manageable.setProperty(key, value);
}
}
Adapter Service
Provides an adapter for a specific type of service.
Motivation
Like with aspects, sometimes you want to create adapters for certain services, which add certain behavior that results in the publication of (in this case) a different service.
Adapters can dynamically be added and removed and allow you to keep your basic services implementations clean and simple, adding extra features on top of them in a modular way.
Structure
Code Example
public class Activator extends DependencyActivatorBase {
public void init(BundleContext context, DependencyManager manager) throws Exception {
manager.add(createAdapterService(Manageable.class, "(publish=servlet)")
.setInterface(HttpServlet.class.getName(), null)
.setImplementation(ManageableServlet.class)
);
}
public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
}
public interface Manageable {
public void setProperty(String key, String value);
}
public class ManageableServlet implements HttpServlet {
private volatile Manageable m_manageable;
public void doPost(HttpRequest req, HttpResponse response) {
String key = req.getProperty("key");
String value = req.getProperty("value");
m_manageable.setProperty(key, value);
}
}
Resource Adapter Service
Provides an adapter for a specific type of resource.
Motivation
Resource adapters are similar to normal adapters, but instead of requiring a service, they require a resource and provide a service on top of it.
Resources are an abstraction that is introduced by the dependency manager, represented as a URL.
They can be implemented to serve resources embedded in bundles, somewhere on a file system or in a content repository or database.
Structure
Temporal Dependency
Provides a proxy that hides the service dynamics of a dependency, even if it disappears for a short time.
Motivation
As a service consumer, you sometimes do not want to deal with the dynamics of services and the fact that they tend to go away for short periods of time whilst their hosting bundle gets updated.
A temporal dependency provides you with a proxy that hides these dynamics and blocks your calls if you try to invoke a method on a service that is currently "updating".
The maximum time to wait is configurable and you will get an exception if no new service becomes available before that time.
Structure
Null Object
Provides an implementation of an object that does nothing and can be used in the absence of the real object.
Motivation
When a component depends on a service, but the dependency is optional, it means that it will use this service when available, but it can still operate if it’s not.
Constantly checking in your code if a service is actually available tends to lead to code with a lot of "if (service != null) service.invoke();" constructions which do not help with code readability.
Instead, the dependency manager offers you a mechanism where it will inject null objects for services that are currently not available so you can simply invoke methods on them that "do nothing".
Structure
Whiteboard
Handles listeners by leveraging the OSGi service registry to publish and look them up.
Motivation
The traditional model for dealing with listeners in Java needlessly complicates things in an OSGi context.
Instead of having listeners registering themselves with the component that will invoke them on any change, a listener simply registers itself in the service registry and the component will do a lookup of all relevant services.
This is explained in more detail on the OSGi.org wiki in the "Listeners considered harmful: the 'whiteboard' pattern" article.
Structure
Content licensed under AL2. UI licensed under MPL-2.0 with extensions licensed under AL2