[External] : Re: Inconsistency with service loading by layer or by class loader

[David Lloyd]

On Mon, Dec 16, 2024 at 10:40 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

> I am very much trying to understand the points you’re raising, but the
> scenario of a dynamic container you’re describing is complicated, and I’m
> trying to get to the bottom of the issue.
>

Very well.

So far I’ve seen two components of concern. The container itself and some
> regular library that is loaded by the container and uses a ServiceLoader.
>
> Now, when Alan suggested "Have you looked at changing these frameworks to
> work with modules and specify a module layer to ServiceLoader.load?” you
> responded that “frameworks” — the container and/or the regular
> ServiceLoader-using library — need to work both on the module path and the
> classpath, which is what piqued my interest, as I’m interested in the JDK’s
> runtime configurations.
>

Yes, and furthermore, such a change is too broad to be practical. We don't
have direct control over most of these frameworks.


> For the sake of simplicity, let’s say that the container itself is modular
> and is only ever used on the module path, and put aside the question of why
> this should or shouldn’t be the case. We’ll focus on the “regular”
> ServiceLoader-using library.
>

Perfect.

Being a regular library, it doesn’t itself construct module layers and it
> creates a ServiceLoader of the ClassLoader variety.
>
> Is the problem you’re describing that of the regular library not being
> able to find one of its service providers because that service provider
> would have been placed by the container in a separate module layer to that
> of the library itself?
>

Yes.

If so, can you describe how that situation could arise? To prove to you
> that I am trying to understand your situation, here’s how I think that
> might happen:
>
> Say the library in question is a logging facade that relies on logging
> service providers, and it happens to be used by both the user application
> and the container. Because it is used by the container, the container will
> load the library, and its logging provider in some container layer. But
> when the library is loaded again by the user application, in some user
> application layer, that copy won’t find the provider in the container’s
> parent layer.
>
> Is that the situation you’re describing?
>

No.

The model I'm working with is such that we are loading every single module
(whether they are within our container or the user's application) into a
separate layer, as has been previously recommended as the way to meet
requirements like ours, with our class loaders handling all inter-module
linkage concerns. Everything works exactly as we want in this scenario:
modules are able to be lazily loaded and linked (just like classes); our
integrity constraints are enforced locally per module on demand, rather
than globally across the whole layer (again, just like classes); and, we
get our nice stack traces and encapsulation behaviors. However there is one
exception, and that is that service loading does not work for any module,
since no modules can find their implementations, regardless of what we do
with class loading. This is what I'm trying to address.

This was never a problem before we tried integrating JPMS, because outside
of JPMS we can manage service dependencies as a variation on regular module
dependencies due to their usage of regular resource files (I can get into
the mechanics of this if you are interested but it's beside the point;
suffice it to say that it has worked well to date).

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241216/5a7aa6a4/attachment.htm>