OSGi Community Event 2014
Abstract:
Everit Component Registry is an amazingly simple yet powerful new open source Component Model. The primary goal of its concept is to allow more configuration options via Configuration Admin and by doing that, offer an alternative to the de-facto standard, whiteboard pattern.
The implementation of Everit Component Registry is in progress. The goal of the session is to
show the status of the project
talk about all the ideas that came up till now
collect about new ideas and weaknesses with the help of the audience
See the most important parts of the concept below:
Configuration via Configuration Admin The concept is similar to Declarative Services. Every configuration should be done via Configuration Admin.
Reference clauses Instead of a simple OSGi filter, references of these components can be configured with clause(s). By doing that it is possible to specify attributes of the binding on the consumer side. The OSGi filter is only a directive of the clause. E.g.: Imagine a ServletContext component that accepts Servlet OSGi services. A clause that selects a servlet can be the following:
myServlet;filter:=(...);mapping=/my/*;init_param1=value1
Cardinality The following cardinalities are supported: 0..1, 1..1, 0..N, 1..N. The choice must be made in the source code. In case of 0..1 and 1..1 cardinality, the type of the clause configuration property is String. In case of 0..N and 1..N the type is String[].
Optionality There is no optional support like in Declarative Services. In case the cardinality is 0..1 or 0..N, it can be configured via Configuration Admin if a service should be picked up or not. In case one ore more clause is defined via ConfigAdmin, all of the clauses must be satisfied.
Dynamism If it is allowed by the programmer of the component, the reference can be updated without restarting the component instance.
Programmability Sub-status and message can be dropped from activate() and deactivate() methods. By doing that, it is possible to get more information in the console about the state of the component (E.g.: unsatisfied programmatic requirements).
New component classes and already instantiated objects can be registered programmatically. By doing that, existing Component Model logic can be mixed with the new concept.
Avoiding magic Using proxy instances, bytecode manipulation, runtime inheritance and other tricks is strictly forbidden. Injected service objects are not “enhanced”, they should be used as they are.
Speaker Bio:
Balazs Zsoldos is the co-founder of Everit. He is the leader of the development of Everit OpenSource Components. Developing Java based solutions is not only his job but also his passion.
He believes in simplicity. That is why he decided to design and build as many simple, but useful goal-oriented modules as he can. As the base of the stack, he chose OSGi.
Balazs does not believe in monoholitic frameworks, therefore all of the sol
24. Delayed component
Declarative Services Everit Component
Model
The activation of the component is
delayed until the service is
requested.
No
25. Optionality
Declarative Services Everit Component
Model
Component is satisfied even if there
is no OSGi service available for the
reference
No configuration must be provided
for the reference / attribute.
If there is no configuration for a
reference, no OSGi service is
picked up.
28. Whiteboard ECM
Configuration on Service side Configuration on Container
and / or on Service side
Services are extended as
soon as they are available
Services are extended as
soon as all necessary services
are available
Ordering based on
service.ranking
Ordering based on the
configuration of container
29. public enum ComponentState {
STOPPED,
UNSATISFIED,
STARTING,
ACTIVE,
STOPPING,
FAILED,
FAILED_PERMANENT
}
// activate(), Thread
// deactivate(), Thread
// Throwable, restart on configuration change
// Throwable, never restart
30. Dynamism
Declarative Services Everit Component
Model
If the configuration is updated, the
component is not restarted.
If a reference is dynamic, the OSGi
services can come and go based on
the cardinality of the reference.
If any of the dynamic attributes /
references are updated, the
component is not restarted
automatically.
If an OSGi service is that is wired to
a reference is unregistered, but
there is another one that can be
wired, the component is not
restarted.
31. Component failure and restart
● Failure cause
– Issue in the component definition (permanent)
– Exception in activate method (temporary)
– Fail called programmatically
● Restart
– A non-dynamic attribute or reference is changed
– Restart called programmatically
32. public interface ComponentContext<C> {
/**
* Causes the component to step into the {@link ComponentState#FAILED} or
* {@link ComponentState#FAILED_PERMANENT} state.
*
* @param e
* The cause of the failure.
* @param permanent
* Whether the failure should be permanent or not. In case of
* permanent failure, the component will not be restarted until
* the bundle that registered the component is updated.
*/
void fail(Throwable e, boolean permanent);
/**
* Causes the restarting of the component. The old instance will be dropped
* and a new one will be instantiated.
*/
void restart();
// Other methods
}
33. @Activate
public void activate(ComponentContext<Component> componentContext) {
// A funny StackOverflowError
componentContext.restart();
}
@Activate
public void activate(ComponentContext<Component> componentContext) {
// Always failing component
Exception e = new Exception("I am an evil failure");
componentContext.fail(e, true);
}
42. Components view
● Shows the state of the components
● Shows the wirings
● Link to the configuration
● Link to the ThreadViewer plugin if the component
is in STARTING or STOPPING state
● Link to the Component Graph plugin
● No enable / disable, restart, etc.
43. Component Graph
● Visual representation of OSGi services and
Components
● Only the selected component and its direct
wirings are shown
● Walking via the wirings
45. No magic, no Christmas tree
@Transactional
public long saveUser(String firstName, String lastName) {
public long saveUser(String firstName, String lastName) {
Objects.requireNonNull(firstName);
Objects.requireNonNull(lastName);
return transactionHelper.required(() -> {
// Logic that should be implemented
return 0l;
});
}
Objects.requireNonNull(firstName);
Objects.requireNonNull(lastName);
// Logic that should be implemented
return 0l;
}
