Module naming for logging implementations

[Gregg Wonderly]

I’d like to reverse this dependency to be that in the end, I want every module in the app I construct to funnel through and use a single Logging implementation so that I can linearize the logging streams into a single stream of details that help me to understand the health and progress of my application.  I want to make sure that I can provide this logging merge apparatus without having to jump through hoops.  Yes, I need to have something that provides all APIs, but those all will be from a single module, not one module per API, because I don’t want to have to create such an layered web of modules.

Removing the logging dependency resolution from module references to ServiceLayer resolution helps me to do this by deferring the task to runtime.  I like that notion because it helps me be able to construct all the objects and implementation details, and then the logging users can find my merged logging implementation, instead of me having to reference the dependency graph and figure out how to make 5 modules accept dependency injections that allow me to make them work, when I may not know all of the details of their “activation”.

Gregg

> On Oct 26, 2017, at 5:05 PM, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> On Thu, Oct 26, 2017 at 3:03 PM, Stephen Colebourne
> <scolebourne at joda.org> wrote:
>> For most service providers, option 2 is obvious, however for logging
>> it is generally the case that only one implementation should be
>> present. If all the jar files that implement a specific logging API
>> had the same module name (option 1) then the module system could
>> ensure that only one was loaded. This is a particular concern as it is
>> not uncommon for a jar file in Maven Central to depend on a specific
>> implementation of logging when it should only be depending on the API.
> 
> This is actually a general special case (if you follow my meaning):
> that of an API which uses services to locate an implementation, yet
> typically only one implementation should be existent and used.  For
> example, I/O or other platform-dependent systems also spring to mind:
> they have a common API, but you generally only want one implementation
> (except maybe in some special cases - just like for logging).
> 
> I think that in any case, be it a singleton-ish provider case like one
> of the above or a multiple-provider case, it is always appropriate to
> choose a unique module name for implementations. It's not appropriate
> for an API to prescribe an implementation module name.
> 
> Perhaps we can enhance Jigsaw in the future with some kind of feature
> that enforces singleton implementations, if it becomes any sort of
> practical problem.
> 
> -- 
> - DML