GA BLOG - BELL SPI Visibility and Configuration Properties

[dazavala]

The information you provide here will be included in the Open Liberty GA release blog post (example), which will be published on openliberty.io/blog/, and potentially elsewhere, to promote this newly released feature/function of Open Liberty. For this post to be included in the GA issue please make sure that this is completed by the end of Friday following the GM (Wednesday).

Please provide the following information the week before the GA date (to allow for review and publishing):

1. Which Liberty feature(s) does your update relate to?

   Human-readable name (eg WebSockets feature): Basic Extensions using Liberty Libraries 1.0

   Short feature name (eg websockets-1.0): bells-1.0

2. Who is the target persona? Who do you expect to use the update? eg application developer, operations.

   Liberty extensions developers

3. Provide a summary of the update, including the following points:

   • A sentence or two that introduces the update to someone new to the general technology/concept.

     This is the content I would like to post to the GA blog. Just the essentials and why we provided the new function. I'm sure it will need a few tweaks for publication. The user-doc for these enhancements provide good usage instructions and a practical example.

BELL SPI visibility for libraries, and BELL properties configuration and injection

The Basic Extensions using Liberty Libraries (BELL) 1.0 feature enables libraries to provide implementations of Liberty API interfaces using Java ServiceLoader configuration files.

22.0.0.11 introduces two capabilities that allow extension developers to provide implementations of Liberty SPI interfaces using libraries and to enable services that receive properties configured in the server.xml file.

SPI visibility for shared libraries

Shared libraries do not support access for SPI packages. The introduction of BELL SPI visibility enables libraries to provide implementations of Liberty SPI interfaces by making SPI packages accessible to shared libraries referenced in a `bell` configuration.

Use the new `spiVisibility` configuration attribute to indicate whether SPI packages are accessible to a library. Set the attribute to `true` whenever a library provides an implementation of an SPI interface:

<bell libraryRef="servicesLib" spiVisibility="true"/>

For the example above, the BELL feature loads the service implementation classes discovered in library serviceLib using a specialized classloader that can see SPI packages in addition to the library binaries and API types.

Properties configuration and injection

The introduction of BELL properties enables service implementations to receive properties declared in the `bell` configuration. The new capability obviates the use of environment variables and JVM system properties to configure BELL services.

Use the new `properties` element to configure one or more properties in a `bell` configuration. Declare each property as a `name="value"` attribute within the element. Properties are type `String` and inject into all service implementations that are enabled to receive them. The following example declares to properties, `hello` and `serverHome`.

<bell libraryRef="servicesLib">
 <properties hello="WORLD" serverHome="${server.output.dir}" />
</bell>

To enable a service implementation to receive configuration properties, define either a public method named updateBell or a public constructor in the service implementation class. The method signature must declare a single parameter of type java.util.Map<String,String>.

public YourServiceImpl(java.util.Map<String,String> bellProperties) {...}
// OR
public void updateBell(java.util.Map<String,String> bellProperties) {...}

At service creation the BELL feature discovers the method(s) and invokes it to inject an unmodifiable map containing a key/value pair for each property. For the example above, the map contains the pairs "hello"/"WORLD" and "serverHome"/"<resolved value of ${server.out.dir}>".

For more information...

To learn more about these capabilities and how they can be used to expose a custom REST endpoint, see the [BELL feature](https://openliberty.io/docs/latest/reference/feature/bells-1.0.html) and [BELL configuration](https://openliberty.io/docs/latest/reference/config/bell.html) topics at [openliberty.io](https://openliberty.io).

https://openliberty.io/docs/latest/reference/feature/bells-1.0.html
https://openliberty.io/docs/latest/reference/config/bell.html

• Briefly explain how to make your update work. Include screenshots, diagrams, and/or code snippets, and provide a server.xml snippet.

  See previous section.

• Where can they find out more about this specific update (eg Open Liberty docs, Javadoc) and/or the wider technology?

  https://openliberty.io/docs/latest/reference/feature/bells-1.0.html
  https://openliberty.io/docs/latest/reference/config/bell.html

If you have previously provided this information for an Open Liberty beta blog post and nothing has changed since the beta, just provide a link to the published beta blog post and we'll take the information from there.

What happens next?

• Add the label for the GA you're targeting: target:YY00X.
• Make sure this blog post is linked back to the Epic for this feature/function.
• Your paragraph will be included in the GA release blog post. It might be edited for style and consistency.
• You will be asked to review a draft before publication.
  • Once you've approved the code review, close this issue.
• If you would also like to write a standalone blog post about your update (highly recommended), raise an issue on the Open Liberty blogs repo. State in the issue that the blog post relates to a specific release so that we can ensure it is published on an appropriate date (it won't be the same day as the GA blog post).

[dazavala]

@ReeceNana Hello. The content I would like to post is now ready to process. Tell me what you think. -Regards.

[dazavala]

The draft of these changes has merged via PR OpenLiberty/blogs#2665. Closing the issue.