Apache Karaf moved to OSGi r4.3

Apache Karaf trunk (future 3.0 release) now fully supports OSGi 4.3 release by running Apache Felix framework 4.0.1 and Eclipse Equinox 3.7.1.

If this update is just a support update, it gives us the opportunity to see what we can leverage from the OSGi r4 early draft.

What’s in preparation in OSGi r4 ?

I will not cover the whole OSGi 4 specification. I will just spot some features that will be “key” features in Karaf.

New OBR specification (RFC-0112)

Currently, there are a number of available solutions to downloading and installing bundles:

  • current OBR stores the bundles and allows users to discover bundles
  • P2 provisioning platform used in Eclipse
  • Maven repositories as used in Karaf
  • Nimble Repositories which are an extension of OBR to deal with active state dependencies

The idea is to gather all these concepts into a new OBR specification.

The new OBR will be able to:

  • handle bundle fragments dependencies, provide management tooling
  • can use a resolver strategy allowing to work with Felix OBR, Sigil or Nimble
  • a normalized and new OBR XML schema, supporting bundle execution environment, etc.

Karaf Cave will be the perfect place to leverage new OBR specification implementation. It will allow Karaf to deploy bundles provided by P2, OBR, Nimble, etc.

Karaf Cave will also extend the OBR specification in order to directly handle Karaf features.

ACE will also use this new OBR specification for the ACE repository implementation.

Subsystems (RFC-0152)

Most of container defines a concept to gather bundles together and provide complete applications.

Depending of the container, we have different wording:

  • in Karaf, we name it features
  • in Spring DM, the name is applications
  • in Aries, it’s applications too
  • in Eclipse, it’s features or installable units

If the core concept is the same, the implementations are very different.

The Subsystems specification aim to use an unique way to define the concept of applications.

Subsystems leverages others OSGi technologies:

  • OBR, we already discussed about that in the first section. It’s the repository used to store all bundles required to be deploy to form an application.
  • framework hooks (RFC-0138) to isolate or group subsystems within a single OSGi framework.
  • deployment admin defines a file format to ship and deploy applications.
  • application admin provides the concept of an application in OSGi.

Subsystems could become a key feature in Karaf 3.0, as it could handle Karaf features and KAR.

We implemented in features concepts defined in this specification. For instance, in a Karaf features, we can use an OBR resolver.

More over, subsystems provides new features missing in the current Karaf features, especially a complete lifecycle, better subsystems dependencies.

Regarding the new OBR and subsystems specifications, we can have a consistent way to deploy applications and bundles.

OSGi for Enterprise (RFC-0164 and RFC-0146)

RFC-0146 covers Java EE JCA for OSGi. It will provides support for resource adapters, packaged as a RAR. The resources can be integrate with OSGi services.

On the other hand, RFC-0164 deals with Blueprint Declarative Transaction. It means that we can define the transaction on a bean methods by declaration in the blueprint descriptor:


<bean ...>
<tx:transaction method="count*" value="Required"/>
<tx:transaction method="count*Row" value="RequiresNew"/>
</bean>

These two specifications are a step forward to a Karaf EE distribution, by including such features and providing others.

OSGi JMX (RFC-0169)

Lot of comments and bugs have been raised regarding the OSGi-JMX specification.

This specification aim to implement most of suggestions and fix bugs.

Comments

Post a Comment

Popular posts from this blog

Quarkus and "meta" extension

Quarkus is a great Java framework with a large ecosystem thanks to the extensions . Basically, if using Maven, your pom.xml contains the list of the extensions you want to use, meaning something like this: ... <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-grpc</artifactId> </dependency> <dependency> <groupId>io.quarkus</groupId> <artifactId>quarkus-opentelemetry</artifactId> </dependency> ... It can quickly become large, and sometime you can have "conflict" between extensions (for example if you mix in the same dependencies set reactive and non reactive extensions). Quarkus "meta" extension To simplify the dependencies for the extensions you want to use (especially if it's basically the same extensions in all your services), you can create your own "meta" extension. This extension doesn't contain actual code, it "wraps" other exten
Read more

Getting started with Apache Karaf Minho

Image
Apache Karaf Minho Apache Karaf Minho is a new runtime, completely created from scratch. The objectives are: super easy to use and run ligtning fast, including GraalVM support Kubernetes compliant to be easily used on the cloud helping to optimize cloud costs by supporting applications colocation providing turnkey services allowing you to create Minho applications in a minute Minho is composed by: minho-boot is the core of Minho. It contains the runtime launcher and the core services (service registry, lifecycle service, configuration service, ...). minho-* services provided additional functionnalities in the runtime. You can use these services to create your own services, it's also where you will find the services managing sepcific kind of applications, allowing colocation. minho-tooling optionally provide convenient tools to create your own runtime. It includes minho-maven-plugin for instance. In this blog post, we will take a quick tour on A
Read more

Apache Karaf Minho and OpenTelemetry

Image
Telemetry is an important part of a software stack, especially on distributed system (where services call each others). OpenTelemetry is a CNCF project coming from OpenTracing and OpenCensus. It provides API to easily instrument your code and tools to collect and export telemetry data (metrics, logs and traces). Before going into how to use OpenTelemetry with Minho, we have to understand some key concepts: Span is a single building block representing an operation or some unit of work that you want to capture. They are capable of standing on their own, referencing (or following) from other spans, storing metadata, tags, etc. Trace is a visualisation of the life of a request (or series of other operations) that is made up of one or more spans. This collection of spans work together to paint a picture of the overall request, allowing you to easily reconstruct what happened within each span, etc. SpanContext is a wrapper of key values pairs that associates a trace to one or mor
Read more