Fusion of Quarkus with OSGi

[Neeraj Vyas]

Hi All, I am wondering if it’s possible to utilize OSGi within Quarkus development and get best of both the worlds, specially generating native code based on Quarkus/GraalVM and maintaining modularity/bundles/services/etc of OSGi? 

Please look at OSGi enroute microservices example at 

https://enroute.osgi.org/tutorial/030-tutorial_microservice.html, what would it take it to work with Quarkus in JVM and Native mode both. I understand native mode may be challenging due to custom classloading in OSGi but I think and am sure that this group can have some cool way to integrate both. Would appreciate if someone can provide example app with this mesh-up. 

Thanks,

Neeraj 

[Emmanuel Bernard]

Hello,

I don't know enough OSGi to root it all entirely but since GraalVM has no classloader whatsoever, it's probably no fit for OSGi (or at least all the existing implementations out there). Also all of the dynamic reloading of modules that OSGi advertise is at odd with the Quarkus philosophy.

Emmanuel

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
Visit this group at https://groups.google.com/group/quarkus-dev.
For more options, visit https://groups.google.com/d/optout.

[David Daniel]

In my opinion depending on how you are using OSGI will depend what parts of OSGI can be utilized.  If you are planning on having a long running service and using the service loader to move things in and out then the goals may not match up very well.  However if you are using OSGI for the requirements/capabilities specification and build tools to test and have a nice uber jar then I think OSGI can be used with jlink https://virtual.osgiusers.org/2019/02/debug-jlink-java-image compatible frameworks.  One of the RFPS out there talks some about the different directions OSGI could go https://github.com/osgi/design/blob/master/rfps/rfp-0191-Future-role-in-distributed-systems.md .  To me what is interesting is that I think Quarkus will face many of the same problems as OSGI in the build system because there are similar problems for new users like

• Lack of library support and the possible need to update a library for integration
• Difficulty working with current testing tools
• Reflection use in many popular libraries like logging
• Dependency on native capabilities on build time components
• Different classloader capabilities than people are used to with standard java

I personally really like BND tools and think they have made great progress solving a number of the problems in mvn and gradel and I think Quarkus has great mvn/gradle integration.  I also think both projects are doing a great job with documentation.  What I would love to see is if there are common areas of difficulties if the tools could share some of the same strategies so that it is easy to move between build systems and developer tool generation could take advantage of some of the same libraries.

[Toni Menzel]

Good Point, David. The list of issues sound very similar, indeed.

Actually, as part of the aforementioned link [1] to "future role in distributed systems" there is already the observation that particular the adaptive service registry (and with it CDIs older brother DS) might be the most useful part in "static" systems - where you have no dynamic classloading. 

So, long story short: Support for the OSGi Service Registry would probably win many OSGi-folks - including me.

WDYT?

I saw that you have your own DI Kernel called ArC. This sounds like the spot where you could click-in another higher level service abstraction such as OSGi's DS. Right now i think CDI is the only high level runtime, correct? I did not have a deep look and how advanced ArC is and why it exists. Maybe someone can shed some light?

And with Clement Escoffier you already have at least one OSGi veteran on board. 

[1] https://github.com/osgi/design/blob/master/rfps/rfp-0191-Future-role-in-distributed-systems.md

Toni

toni menzel / rebaze consultancy Alleestrasse 25 / 30167 Hannover / Germany M +49 171 6520284 www.rebaze.com

rebaze GmbH, Zollstrasse 6, 39114 Hannover, Germany  Managing Director: Toni Menzel Phone: +49 171 6520284 / E-Mail: h...@rebaze.com Registration Court: District Court of Stendal Registration Number: HRB 17993  Sales Tax (VAT) Registration Number: DE282233792

[Neeraj Vyas]

Thanks Emmanuel for your response. Do you think these limitations can be a roadblock in widespread adopting Quarkus in longer run due to incompatible external dependencies (not talking specifically only about OSGi)? Having a way to allow such integration could be very beneficial to widespread adoption. 

[Jason Greene]

Since, Quarkus’ primary targets are microservice and serverless computing, both of which emphasize fine-grained, single purpose focused services, we don’t see as strong of a need for class loader isolation, which has its biggest value in use cases where multiple applications and services are sharing the same JVM.  Instead we prefer alternative mechanisms, such as opting in to only the extensions you need, and on the Quarkus framework side separating runtime and deployment dependencies.  

It is possible to carry over a major chunk of OSGi API set in some form, if you simply view the Quarkus output as a collapsed pre-wired frozen osgi service resolution tree.  Although it would have more boilerplate over the already provided injection facilities. 

[Todor Boev]

Indeed to make OSGi better adapted to containerized environments we are considering an OSGi flavor where the dynamic class loading is removed:
https://github.com/osgi/design/blob/master/rfps/rfp-0143-OSGiConnect.pdf

What will be retained are actually the most valuable parts of OSGi:

- the dependency resolution which is applied to the jars prior to compilation in all cases

- the dynamic service oriented programming model.

The service graph is not entirely static, since OSGi models external entities as services too: E.g. listen to a discovery protocol and add/remove a local service to model your external database.

This means your application will react to the db coming/going/relocating automatically without you the developer having to do much if anything.

In fact people already build OSGi based microservices in this way (packaged into containers and all).

We use the dynamic module reload only during development to quickly update our runtimes rather than to rebuild+reboot the entire container.

OSGi originally came from IoT and  it is perfectly capable of having a small footprint: this is where the fine-grained resolution model shines.

Basically just like everyone else we hit a wall where we can't shrink more under the standard JVM and just like everyone else we must make changes to enable GraalVM compatibility.

On Thursday, 25 April 2019 08:05:31 UTC+3, Jason Greene wrote:

Since, Quarkus’ primary targets are microservice and serverless computing, both of which emphasize fine-grained, single purpose focused services, we don’t see as strong of a need for class loader isolation, which has its biggest value in use cases where multiple applications and services are sharing the same JVM.  Instead we prefer alternative mechanisms, such as opting in to only the extensions you need, and on the Quarkus framework side separating runtime and deployment dependencies.  

It is possible to carry over a major chunk of OSGi API set in some form, if you simply view the Quarkus output as a collapsed pre-wired frozen osgi service resolution tree.  Although it would have more boilerplate over the already provided injection facilities. 

On Apr 24, 2019, at 8:59 PM, Neeraj Vyas <neera...@gmail.com> wrote:

Thanks Emmanuel for your response. Do you think these limitations can be a roadblock in widespread adopting Quarkus in longer run due to incompatible external dependencies (not talking specifically only about OSGi)? Having a way to allow such integration could be very beneficial to widespread adoption. 

On Wed, Apr 24, 2019 at 2:26 AM Emmanuel Bernard <eber...@redhat.com> wrote:

Hello,

I don't know enough OSGi to root it all entirely but since GraalVM has no classloader whatsoever, it's probably no fit for OSGi (or at least all the existing implementations out there). Also all of the dynamic reloading of modules that OSGi advertise is at odd with the Quarkus philosophy.

Emmanuel

On 24 Apr 2019, at 3:21, Neeraj Vyas wrote:

Hi All, I am wondering if it’s possible to utilize OSGi within Quarkus development and get best of both the worlds, specially generating native code based on Quarkus/GraalVM and maintaining modularity/bundles/services/etc of OSGi? 

Please look at OSGi enroute microservices example at 

https://enroute.osgi.org/tutorial/030-tutorial_microservice.html, what would it take it to work with Quarkus in JVM and Native mode both. I understand native mode may be challenging due to custom classloading in OSGi but I think and am sure that this group can have some cool way to integrate both. Would appreciate if someone can provide example app with this mesh-up. 

Thanks,

Neeraj 

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

Visit this group at https://groups.google.com/group/quarkus-dev.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

[David Lloyd]

On Thu, May 2, 2019 at 8:43 AM Todor Boev <rins...@gmail.com> wrote:
>
> Indeed to make OSGi better adapted to containerized environments we are considering an OSGi flavor where the dynamic class loading is removed:
> https://github.com/osgi/design/blob/master/rfps/rfp-0143-OSGiConnect.pdf
>
> What will be retained are actually the most valuable parts of OSGi:
> - the dependency resolution which is applied to the jars prior to compilation in all cases

This part at least is already handled by the build system at build
time for us. We only resolve one time (at build).

> - the dynamic service oriented programming model.
>
> The service graph is not entirely static, since OSGi models external entities as services too: E.g. listen to a discovery protocol and add/remove a local service to model your external database.
> This means your application will react to the db coming/going/relocating automatically without you the developer having to do much if anything.

This kind of thing could probably be implemented as extensions, if
there is a desire to use OSGi-flavored APIs for it.
--
- DML

[John-Paul Cunliffe]

Merging those two would be big step towards allowing modulithic development. By this I mean development via modules, deployment via microservices. moduliths are considered a game changer in reducing microservice complexity during development.

[Scott Lewis]

I know it's been 4 years since this discussion (which I wasn't aware of until recently).

> Merging those two would be big step towards allowing modulithic development. By this I mean development via modules, deployment via microservices.

As one of the implementers of the Remote Services/RSA reference implementation:  https://github.com/ECF

I agree with this statement, specifically the merging of the OSGi service registry...upon which RS/RSA is based...with Quarkus, to provide both multiprocess *and* single process microservices.

There have been major changes in the directions discussed here (old version referenced in post by David Daniel in this thread)

https://github.com/osgi/design/blob/main/rfps/rfp-0191-Microservice-Architactures.md

since this microservices architecture paper was written.  Here are some of the big changes:

1) The OSGI Connect specification has been completed/released:  https://docs.osgi.org/specification/osgi.core/8.0.0/framework.connect.html

2) There is an impl of Connect here:  https://github.com/apache/felix-atomos

What these two mean is that desire expressed in the paper to *remove* the bundle layer, and only use service layer and higher services (e.g. declarative services, RS/RSA) is fully in place.  I'm not an expert in Quarkus, but that should make integration easier.

3) RSA has matured spec-wise...e.g. https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.remoteserviceadmin.html to support async remote services

4) Spec-compliant impls of RS/RSA that provide multiple discovery and distribution providers (using multiple transports...e.g. jaxrs, socket, grpc, etcd3 discovery, etc. already exist...e.g. here https://github.com/ECF/grpc-RemoteServicesProvider, and its a simple matter to build new ones as other discovery and distribution transports are required for integration and security...while keeping a proper separation of concerns relative to the remote/service registry.  Also SCR is much more dynamic...and better suited to remote/network conditions (partial failure) than the other 

5) The available tooling in support of declarative services, rs/rsa and osgi development in general has improved significantly (see blog links below for example).

6) There are Python-based impls of OSGI bundle model with RSA built in.  for example:  https://eclipseecf.blogspot.com/2025/06/remote-tools-for-model-context-protocol.html.  There could easily be support in other languages for the OSGi service registry/RS/RSA.

One of the areas of continued work (for me and RSA impl project lead) is in using the extensibility defined by the OSGi remote services topologymanager

https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.remoteserviceadmin.html#d0e60111

to support some of the other use cases in the microservices paper.   Our impl has only a 'basic' topology manager (promiscuous for export and impor), but it can easily be extended or replaced with topology managers impls for managing the multiprocess/microservice discovery and orchestration in more complex ways/use cases as described by the microservices paper.

As an example of a mixed model of using process-level microservices and service-registry (in process) based microservices I've recently created these blog posts about using RS/RSA + modulithic development to create a Model Context Protocol (MCP) distributed application:

https://eclipseecf.blogspot.com/2025/07/building-mcp-servers-integration-via.html

https://eclipseecf.blogspot.com/2025/07/building-mcp-servers-part-2-example.html

[Scott Lewis]

Hi Folks,

Regarding the OSGi service registry usage in Quarkus:   I'm contributing to the MCP java sdk server, to enable to the use of OSGi services in the dynamic use of MCP Tools:

https://github.com/ECF/MCPToolGroups

OSGi services proven impl of the services registry, along with it's support for standardized service meta-data (e.g. remote services), dynamics (e.g. ds), service-level dependency management (ds again), leveraging of type safety and classloader isolation, support for multiple class versions in a single process, and other aspects, make for a very strong foundation on which to build dynamic mcp servers in java.