Adobe Developers Live 2021, Session | OSGi inside - why we love it and why you don't really need to care

[kautuk_sahni]

Session Details

A panel with Carsten Ziegeler, Karl Pauls, & David Bosschaert on why we use OSGi, why it's relevant in the Cloud and what AEM developers need to know about it

Experience League Session Recording 

Session Schedule

8-Feb, 11:45 AM - 12:15 PM PST

Speaker(s)

Carsten Ziegeler, Karl Pauls & David Bosschaert

Full Schedule

Check Here

Q&A

Please use this thread to ask the question related to this Session.

Session FAQs

Q. The strongest part of OSGi is to support having packages to support several versions, thus, provides a way to support backward compatibility and seamless deployments, however, I can not say I see this strong side in AEM(we used AMS). Why do you think this happened? Did the availability constraints of AMS oppress the flexibility of OSGi?

A. This is one feature of OSGi but not the most important one. The general modularity, services model and standard APIs for various technologies are far more important.

Q. If we're saying that we don't need downtime to do a new deployment: Why is there in fact downtime in AEM when doing a deployment? When doing a deployment, you will generally experience a few seconds to maybe even a minute of downtime in the sense that you will notice that services are (re)starting, servlets are missing (causing a 404), ...

A.  This question does not relate to OSGi.

Q. Will there any future change in OSGI considering Java9 Project Jigsaw

A. As mentioned in the talk – the new OSGi R8 core spec has the OSGi Connect specification. That one can be used to interact with JPMS (Java9 Project Jigsaw). It requires you to provide a connector that does know about JPMS like e.g. the Apache Felix Atomos subproject. It has support for exposing JPMS modules as bundles - there are examples for it.

Q. AEM as a Cloud Service has pretty much done away with the provision of updating OSGi configurations on the fly, mandating deployments for such changes. What would become the motivation for making Components/Services configurable anymore (which was the way for maintaining 'infrequent' changes)?

A. Immutable deployments should not have dynamic tweaks. These don’t work in a container-based environment.

Q. If AEM as a Cloud Service had to be built from the ground up today, where would you still use OSGi? It seems to me that OSGi is mostly an advantage when building a monolith, not so much when building microservices, or serverless functions for that matter. But maybe I'm missing something, or maybe you would still build AEM as a monolith?

A. OSGi is useful in pretty much all Java project, so yes. Would still use OSGi.

Q. This is more of an AEM question than OSGi, but wouldn't it be logical to re move the webserver(jetty) from Felix and provide as an additional Application Server to remove the load on the OSGi?

A. Jetty doesn’t put a load on OSGi. When talking about AEM, it is possible to use it inside an application server such as JBoss – however, that would have little impact on OSGi.

Q. Are there any rules to follow on when to separate out and create a new project/bundles, for application code.

Should bundles be separated on business logic or performance or other factors?

A. In general, it is advisable to cut your bundles around high cohesion and low coupling. In other words, each bundle should try to focus on a specific thing and have a minimal set of dependencies.

Don't forget to register yourself for this session using the registration link shared above.