Friday, October 5, 2018

OSGi Users' Forum Germany Meeting 22 Oct - Ludwigsburg

The OSGi Users' Forum Germany are having their next meeting the afternoon before the OSGi Community Event in Ludwigsburg - Oct 22 from 14.00hrs.

This meeting will be a workshop focusing on the recent OSGi Release 7 and there are three talks which will include a review on whats new in Release 7, the updated OSGi enRoute for R7 and an intro to gecko.io.  In addition there will be a Q&A and discussion session. The full agenda is available here.

So if you are joining us for the OSGi Community Event or attending EclipseCon Europe this provides a perfect opportunity to learn more about the latest OSGi release.

The meeting is open to all - OSGi Users' Forum Germany members and non-members and is being hosted as part of the Eclipse Community Day which takes place all day on Monday Oct 22.  Its €60 per person to attend and this provides you with access to any of the sessions all day, lunch and refreshments at breaks.

To secure your place please visit https://www.eclipsecon.org/europe2018/registration#special.

If you haven's got your pass for OSGi Community Event and EclipseCon there is still time to get one of these too. We have a packed conference and would be great to see you there.

Monday, October 1, 2018

Countdown to OSGi Community Event 2018

So it's reaching that time of year again. Not only is it, gulp, only 91 days to the end of the year and a mere, double gulp, 84 sleeps until Christmas, October is a really big month in the OSGi schedule.

Today, being October 1, means we are just 22 sleeps until OSGi Community Event 2018.

We have a packed schedule again this year in Ludwigsburg, Oct 23 to 25, including:
And if all that OSGi goodness isn't enough, we are co-located with EclipseCon Europe again this year and attendees get full access to the EclipseCon schedule and exhibition, along with all the excellent social events.

Registration is still open, so if you haven't booked your ticket yet I encourage you to do so fast and to secure your hotel as rooms are selling out.

Big thanks go to the following companies who have sponsored the OSGi Community Event in 2018. It is their support that makes it possible for us to bring this event to you.


See you in Ludwigsburg soon.

Tuesday, September 18, 2018

Meet us at Liferay DEVCON

The OSGi Alliance is pleased to be attending Liferay DEVCON in Amsterdam in November.  The main conference is taking place November 7 and 8 and we will have an OSGi booth in the exhibition area.  There is also an unconference taking place the day before the main conference on November 6.


We are happy to answer any questions you have about modularity and OSGi technology, the OSGi Alliance, the new R7 release and anything else you can think of that is OSGi related.

We would also encourage anyone who might be interested in joining the OSGi Alliance and contributing to the ongoing evolution and development of the open standard OSGi specifications to come and chat with us at our booth.  Even though R7 is only just out the door, we are already drawing up ideas for Release 8 (R8) and so now is a great time to join us and get involved in the new activities.

Liferay is an extensive user of OSGi technology and we are really pleased to have the opportunity to meet their community of users and developers at this key event.  Ray Augé, a Senior Software Architect at Liferay, and co-chair of the OSGi Enterprise Expert Group, will be presenting on the upcoming OSGi CDI integration specification. Ray's talk will demonstrate common usage patterns and its component model that brings OSGi dynamics; like services and configuration, to CDI and provides for an ecosystem of CDI portable extensions.

You can find out more about this year's Liferay DEVCON including how to register on the conference website.

We realize that this is coming hot on the heels of the OSGi Community Event and EclipseCon Europe in October and Liferay is offering a 25% discount on DEVCON ticket prices to anyone that is attending that event this year too.  To obtain your discount code please see the Liferay advert in the OSGi Community Event and EclipseCon Europe event brochure.

Wednesday, September 5, 2018

OSGi R7 Highlights Blog Series

The OSGi R7 Highlights blog series has come to a close and we certainly want to thank you for following the series and hope you found it insightful and useful!  The series featured posts from technical experts at the OSGi Alliance sharing some of the key highlights of the new R7 release.

Its worth noting that the OSGi Core specification has provided a stable platform for developing modular Java applications for almost two decades. The OSGi Core R7 specification continues this tradition by providing updates to the OSGi Core specification which are fully compatible with previous versions of the OSGi Core specification.  This gives developers and users of OSGi technology an established track record of certainty of their investment protection from adopting OSGi.

The blog posts covered the topics below so if you missed reading any of the posts, be sure to take a moment to check them out.

Feel free to send questions regarding any of the OSGi R7 blog posts to us by email or as comments on the post in question.  We welcome any and all feedback and want to hear from you if you have any suggestions on future topics related to OSGi R7 or otherwise.

OSGi R7 Highlights Blog Series

  • Java 9 Support – Multi-release JAR support and runtime discovery of the packages provided by the JPMS modules loaded by the platform.
  • Declarative Services – Constructor injection and component property types.
  • JAX-RS – A whiteboard model for building JAX-RS microservices.
  • Converter – A package for object type conversion.
  • Cluster Information – Support for using OSGi frameworks in clustered environments.
  • Transaction Control – An OSGi model for transaction life cycle management.
  • Http Whiteboard – Updates to the Http Whiteboard model.
  • Push Streams and Promises – The Promises packages is updated with new methods and an improved implementation and the new Push Streams package provides a stream programming model for asynchronously arriving events.
  • Configurator and Configuration Admin – Configuration Admin is updated to support the new Configurator specification for delivering configuration data in bundles.
  • LogService – A new logging API is added which supports logging levels and dynamic logging administration and a new Push Stream-based means of receiving log entries is also added.
  • Bundle Annotations – Annotations that allow the developer to inform tooling on how to build bundles.
  • CDI – Context and Dependency Injection support for OSGi developers.

Be sure to follow us on Twitter or LinkedIn or subscribe to our Blog feed.

Friday, August 31, 2018

Join us at JUG Thüringen on September 19

Join us for an evening of OSGi on September 19 with the Java User Group Thüringen (@jugthde).
The OSGi Alliance Expert Groups are gathering in Jena that week for their next face-to-face technical meetings. The JUG Thüringen have kindly arranged a meetup on the evening of September 19 at 6pm while the OSGi technical experts are in town.

There will be three, 30-minute 'talklets' and a one-hour open mic discussion session.  Registration is essential and please visit their meetup page for the event to book your place.

Thanks to Intershop for hosting the meeting.
The agenda for the evening meetup is as follows:
18:00 - Open
18:15 - Welcome from Intershop by Johannes Metzner and JUG Thüringen by Benjamin Nothdurft
18:30 - OSGi enRoute Quickstart - A Beginners Guide to OSGi by Tim Ward
19:00 - Gecko.io - Kickstart your professional OSGi Development by Jürgen Albert
19:30 - Intelligent robots - Resolving the promise by Tim Verbelen
20:00 - Break with finger food
20:30 - Open Mic / Panel Discussion (WIP)
21:30 - End with pub visit (Wagnergasse)
Abstracts and further information can be found on the registration page. We hope you can join us.

Friday, August 17, 2018

OSGi R7 Highlights: CDI Integration

The OSGi Enterprise Release 7 specification targeted for release in the coming months contains a brand new specification: CDI Integration. This specification brings the exciting features and capabilities of the Contexts and Dependency Injection (CDI) specification to OSGi.

CDI itself is a vast specification and with that in mind several goals were established to guide the development of the integration:
  1. Do not reinvent the wheel, follow established approaches such as leveraging the CDI Service Provider Interface model
  2. Make code look and feel as natural to CDI developers as possible using CDI designs and best practices where applicable and generally adopt CDI form and function
  3. Provide uncompromising support for key OSGi features such as services, configuration and the dynamics these entail, while not over-complicating or over-engineering the design
  4. Enable modularity for CDI Portable Extensions such that an ecosystem of portable extensions may emerge

Beans

The most basic interaction a developer has with CDI comes from the "Contexts" portion of the spec and the creation of beans, which stems from defining in which context a bean's instances reside. Generally this is accomplished by applying a scope annotation to a POJO.
@ApplicationScoped
public class ShopImpl implements Shop {
  public List<Product> getProducts() { ... }
}
This POJO is a bean whose scope is defined as @ApplicationScoped whose context defines its instance as visible to the entire application.

Injection

The next interaction with CDI comes from the "Dependency Injection" portion of the spec. This is accomplished by applying the @Inject annotation to a field, method or constructor of a POJO.
@ApplicationScoped
public class ShopImpl implements Shop {
  @Inject
  Logger logger;

  public List<Product> getProducts() { ... }
}
This POJO will now have a Logger instance injected into it when the instance is created.

OSGi Services

With a basic understanding of beans and dependency injection let's move on to the OSGi CDI Integration features. The most important feature provided by the CDI integration is the ability to register services with or obtain services from the OSGi service registry.

Registering a service can be as simple as applying the @Service annotation to a bean.
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  ...
}
This POJO is registered into the service registry with the service type Shop.

Adding service properties is accomplished using annotations that are meta-annotated with the @BeanPropertyType annotation. A couple of examples are the @ServiceDescription and @ServiceRanking annotations defined by this specification.
@ApplicationScoped
@Service
@ServiceDescription("This is the primary implementation of the Shop service.")
@ServiceRanking(1000)
public class ShopImpl implements Shop {
  ...
}

Obtaining services is accomplished by using the @Reference annotation in conjunction with @Inject.
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  ProductStore productStore;

  public List<Product> getProducts() {
    return productStore.all();
  }
}
This POJO is injected with a service of type ProductStore.

Filtering services is accomplished by specifying a target filter from the @Reference annotation and/or by adding one or more annotations meta-annotated with @BeanPropertyType to the injection point. The following example filters services having the service.vendor service property equal to Acme, Inc.
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  @ServiceVendor("Acme, Inc.")
  ProductStore productStore;

  public List<Product> getProducts() {
    return productStore.all();
  }
} 
 

Optionality, Cardinality and Dynamics

In OSGi services may need to be expressed in terms of their optionality (if a service is required at all), cardinality (how many services are required) and their dynamics (if the service(s) may change during the lifetime of the bean's context). These concerns are handled elegantly using the Java type system.

The previous example demonstrated a mandatory, unary cardinality reference.

Optional references are expressed using Java's Optional type.
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  Optional<ProductStore> productStore;

  public List<Product> getProducts() {
    return productStore.map(s -> s.all()).orElse(Collections.emptyList());
  }
}

Multi-cardinality references are expressed using a Collection or List types. The default cardinality in this scenario is 0 (which is to say that the services are optional by default). A minimum cardinality can optionally be expressed in conjunction with multi-cardinality using the @MinimumCardinality annotation.
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  @MinimumCardinality(1)
  List<ProductStore> productStores;

  public List<Product> getProducts() {
    return productStores.stream().flatMap(
      s -> s.all().stream()
    ).collect(Collectors.toList());
  }
}

Dynamic references are expressed using the Provider type.
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  Provider<ProductStore> productStore;

  public List<Product> getProducts() {
    return productStore.get().all();
  }
}

Greediness

One of the key distinctions between Declarative Services and CDI Integration with respect to references to services is greediness. Where the greediness of references in Declarative Services is reluctant by default, the greediness of references in CDI Integration is greedy by default. This means that CDI Integration references will always reflect the best service(s) available. This also means that CDI Integration beans may have a more volatile life cycle depending on their references and how often matching services come and go.

Defining a reference to be reluctant is accomplished using the @Reluctant annotation. (This means that once an adequate service is bound it is unlikely to be replaced with a better service in the future.)
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  @Reluctant
  ProductStore productStore;

  public List<Product> getProducts() {
    return productStore.all();
  }
}

Beans vs. Components

In a traditional CDI application, all beans make up the application and form a single cohesive unit; the CDI container. Modeling external dependencies such as (non-dynamic) references to services and configurations without complexities like proxies or byte code instrumentation means the CDI container has to be treated as a single unit, resulting that whenever any dependency changes in a significant way the entire CDI container must be destroyed and recreated. This is a fundamental difference to the model defined in Declarative Services which permits individual components to exist independently from each other. It is also rather limiting. In order to address this limitation the CDI Integration defines the concept of components. Components are cohesive collections of beans which have a consistent, related life cycle which may operate individually from one another.

The CDI Integration defines 3 component types:
  1. Container Component - All traditional beans (@ApplicationScoped, @RequestScoped, @SessionScoped, @Dependent, custom scopes, etc.) are part of the container component (in fact, any bean which is not @ComponentScoped is part of the container component)
  2. Factory Components - are collections of @ComponentScoped beans rooted by a bean having the stereotype @FactoryComponent (such components are driven by factory configuration)
  3. Single Components - are collections of @ComponentScoped beans rooted by a bean with the stereotype @SingleComponent
These components are arranged in two levels where the container component exists as the first level and any number of factory and/or single component children exist in the second level.

Type (relation to CDI Container)
1 Container Component (1..1)
2 Factory Component (0..n) Single Component (0..n)

Factory and single components exist and react to change independently from each other, just like Declarative Services components, while also depending on the container component. If the container component needs to be recreated then all factory and single components must also be recreated.

With this model, it's possible to replicate the Declarative Services component model, while also supporting the traditional monolithic CDI approach (with the additional capability to share beans between container, factory and single components provided they are @ApplicationScoped or @Dependent and also to use other CDI features like Decorators, Interceptors and CDI Portable Extensions.)

Let's see an example:
@ApplicationScoped
@Service
public class ShopImpl implements Shop {
  @Inject
  @Reference
  Provider<List<ProductStore>> productStores;

  public List<Product> getProducts() {
    return productStores.get().stream().flatMap(
      s -> s.all().stream()
    ).collect(Collectors.toList());
  }
}

@BeanPropertyType
public @interface StoreConfig {
  String vendor_name();
  String data_file();
}

@FactoryComponent("product.store")
@Service
public class ProductStoreImpl implements ProductStore {
  @Inject
  @ComponentProperties
  StoreConfig storeConfig;

  public List<Product> all() {
    return read(storeConfig);
  }
}
This application provides a Shop service that is dynamically tracking a number of ProductStore services. ProductStore instances are created by adding new factory configuration instances using the factory PID product.store. Each ProductStore instance is injected with its component properties which are coerced into a typesafe, user-defined StoreConfig for easy processing.

Conclusion

The CDI Integration specification bridges the powerful features of CDI and OSGi in a clean and concise way which should empower developers. There are many other aspects of the specification that don't fit into a single blog post such as modularity for CDI Portable Extensions, further discussion about BeanPropertyType, configuration dependencies, tracking service events, the relationship with Decorators and Interceptors, etc. So don't forget to read the latest draft of the spec. The CDI Integration specification is an important step forward in OSGi dependency injection story that hopefully opens the OSGi door to a wider audience already familiar with CDI.


Want to find out more about OSGi R7?

Wednesday, August 1, 2018

OSGi Community Event 2018 Talks Announced

We are pleased to announce that the details of the selected talks for this year's Community Event are now available.  You can find the list of talks, titles, and abstracts online.

Congratulations to everyone selected.

Thanks to everybody who made a submission for the OSGi Community Event 2018. We recognize that it takes time and effort and appreciate all of the submissions, whether successful or not.

Forum am Schlosspark -- Venue for the OSGi Community Event 2018

If you are joining us in Ludwigsburg at the event October 23 to 25 then we encourage you to book your tickets early to secure the best price and also to make your hotel reservations as soon as you can as the conference hotel (Nestor Hotel) always sells out well before the event.