OSGi extender pattern for a new module?

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

I'm planning to use that pattern for [1], similar to what we do for
initial content loading, using a BundleTracker [2] to track bundles.

The use case is multiple bundles providing partial GraphQL schemas as
text file resources to a service that aggregates them.

It's been a long time since I created a module that uses this
technique, is that still the recommended way of doing such things?

-Bertrand

[1] https://github.com/apache/sling-whiteboard/tree/master/sling-org-apache-sling-graphql-schema
[2] https://docs.osgi.org/javadoc/r4v42/org/osgi/util/tracker/BundleTracker.html

Re: OSGi extender pattern for a new module?

[Eric Norman <en...@apache.org>]

Hi Bertrand,

I think it is fine.  I recently used an extender pattern to solve
SLING-10135 and it seemed to work pretty well.

Regards,
Eric


On Fri, Jun 25, 2021 at 2:33 AM Bertrand Delacretaz <bd...@apache.org>
wrote:

> Hi,
>
> I'm planning to use that pattern for [1], similar to what we do for
> initial content loading, using a BundleTracker [2] to track bundles.
>
> The use case is multiple bundles providing partial GraphQL schemas as
> text file resources to a service that aggregates them.
>
> It's been a long time since I created a module that uses this
> technique, is that still the recommended way of doing such things?
>
> -Bertrand
>
> [1]
> https://github.com/apache/sling-whiteboard/tree/master/sling-org-apache-sling-graphql-schema
> [2]
> https://docs.osgi.org/javadoc/r4v42/org/osgi/util/tracker/BundleTracker.html
>

Re: OSGi extender pattern for a new module?

[Julian Sedding <js...@gmail.com>]

Hi Bertrand

I would argue that the extender pattern is still very useful for such
scenarios where bundles provide some sort of meta-information that
should be centrally interpreted.

Two examples in Sling that come to my mind are Sling Models (for model
classes via a manifest header) and Sling JUnit Core (for a test-class
regexp via bundle header and for JUnit Jupiter TestEngines that are
available via java's ServiceLoader). I guess this list is not
exhaustive.

Regards
Julian

On Fri, Jun 25, 2021 at 11:33 AM Bertrand Delacretaz
<bd...@apache.org> wrote:
>
> Hi,
>
> I'm planning to use that pattern for [1], similar to what we do for
> initial content loading, using a BundleTracker [2] to track bundles.
>
> The use case is multiple bundles providing partial GraphQL schemas as
> text file resources to a service that aggregates them.
>
> It's been a long time since I created a module that uses this
> technique, is that still the recommended way of doing such things?
>
> -Bertrand
>
> [1] https://github.com/apache/sling-whiteboard/tree/master/sling-org-apache-sling-graphql-schema
> [2] https://docs.osgi.org/javadoc/r4v42/org/osgi/util/tracker/BundleTracker.html

Re: OSGi extender pattern for a new module?

[Radu Cotescu <ra...@apache.org>]

Hi Bertrand,

> On 25 Jun 2021, at 11:32, Bertrand Delacretaz <bd...@apache.org> wrote:
> 
> Hi,
> 
> I'm planning to use that pattern for [1], similar to what we do for
> initial content loading, using a BundleTracker [2] to track bundles.

A BundleTracker is also the core of running Sling with precompiled scripts, provided by several client bundles.


> 
> The use case is multiple bundles providing partial GraphQL schemas as
> text file resources to a service that aggregates them.

To make sure that everything works as expected I’d create a capability in o.a.s.graphql.schema that the bundles which provide schema extensions would require, in order to create the wiring in between the bundles. This way you’ll have a limited number of bundles that would trigger the BundleTracker and you also create a weak contract.

> 
> It's been a long time since I created a module that uses this
> technique, is that still the recommended way of doing such things?
> 
> -Bertrand
> 
> [1] https://github.com/apache/sling-whiteboard/tree/master/sling-org-apache-sling-graphql-schema
> [2] https://docs.osgi.org/javadoc/r4v42/org/osgi/util/tracker/BundleTracker.html


Regards,
Radu