Your applications should suffer no side effects when using a custom user registry deployed as a bell. Since your UserRegistry service implementation is provided by a shared library, you should avoid referencing bellsCurLib within any <classloader/> configurations.

The <bell/> configuration references a shared library, which includes all binaries and resources required by your UserRegistry service implementation except for Open Liberty API/SPI and java packages. I'm not aware of a "cleaner" way to assemble the required dependencies into a single library jar, but you needn't deploy a single library jar as this tutorial suggests. You can cache the dependencies to a reserved location in the server environment and configure the library to also include these dependencies.

<variable name="oss.dependencies.dir" value="/some/root/path/containing/oss/jars/and/resources/" />

<library id="bellsCurLib" name="bellsCurLib">
    <file name="${server.config.dir}/resources/ol-cur.jar" />
    <fileset dir="${oss.dependencies.dir}" include="file-name-pattern-1, file-name-pattern-2, ..." />
    <folder dir="${oss.dependencies.dir}/path/containing/resources/" /> 
</library>

FYI, your shared library referenced by the bell requires the UserRegistry interface, which is an Open Liberty API of type ibm-api. The server makes this API type available to libraries by default. So, your <library/> configuration is fine in this regard -- you needn't configure the apiTypeVisibility attribute of the <library/> to make the API available to the service implementation. SPI visibility for libraries referenced by a bell is a relatively new feature. Unless your service implementation also requires SPI, you needn't configure attribute spiVisibility="true" in the <bell/>. And that begs the question: Did you find a user document that mentions attribute enableSpiVisibility? If so, please post a reference as the document contains a typo. Thanks!