vy commented on PR #1401:
URL: https://github.com/apache/logging-log4j2/pull/1401#issuecomment-1550194311
## Dependency Injection (DI) vs Static Registries
> Also, saying static registries are a problem flies in the face that Log4j
has a ServiceRegistry, PropertiesUtil (the PropertyRegistry), a Plugin
registry, the LoggerContext is a registry of the application's Loggers, and the
LoggerContextSelector is a registry of the LoggerContexts.
There are several JIRA tickets and mailing list threads from users (and
committers, PMC members!) complaining that they cannot test logging without
forking a fresh JVM each time. Since we both like Spring, let me continue with
an example from there. Why do we need to inject `Environment` every time we
need to deal with it rather than using a static `PropertiesUtil` just like
Log4j does?
I think hardcoding the functionality in static registries was the right
decision when it was first introduced to Log4j; it was (still is!) convenient
to use, the core was small, and there weren't a DI system. But things have
changed, in a positive way: we now have a powerful DI system. Let's put that
into use!
> The DI system is also essentially a registry much as Spring's IOC is.
There are probably more but that is just what immediately came to mind.
Yes and with any other system run by a decent DI, you shouldn't need static
access. JTL contains the most complicated DI usage out there and there is not a
single call to static `DI.*` methods.
> You would have to provide some concrete evidence that registries are a
problem for me to buy that argument.
I have provided several examples demonstrating why static registries are bad:
1. Hinders testing
2. Hinders composition (e.g., one cannot provide a `PropertiesUtil`
implementation, etc.)
3. It is a bad-practice in a DI-backed system
I am curious to know if there is a flaw in my line of thinking.
> FWIW, it is quite easy to create an intelligently designed registry be
able to generate and use Mock objects for testing. For example, this is quite
easy to do with Spring.
Definitely! But this is all possible since nothing is statically wired but
glued together at runtime by DI.
## Scoped Values
> I am thinking of when Scoped Values come into play.
Scoped Values are indeed on the horizon and we should cater for that. We
might indeed need to massage the current Recycler API to accommodate that. In
particular, scoped values require a lambda (i.e., `ScopedValue.where(var,
val).run(Runnable)`), whereas our current recycler requires explicit
acquire/release calls. These ergonomics are pretty much orthongonal. I will try
to flesh out some Recycler API support for this.
## Requesting thread-related functionality while creating a recycler
> Or if thread inheritance is required.
I have my reservations about this Ralph. Recycler is merely an efficient
object pool. I think requesting thread-related functionality would break that
assumption and sophisticate the design. Do you have a particular use case in
mind that requires, e.g., thread inheritance?
## Having a recycler registry
> `Recycler recycler = RecyclerRegistry.get("name", spec)`
> ...
> 1. Different use cases to potentially share the same ThreadLocal
(depending on their spec declaration)
Do you have a [non-hypothetical] use case in mind for the recycler sharing
you mention?
> 1. Intelligent cleanup of all Recycler instances. This could be handled
through callbacks that are part of the interface or other mechanism as we
desire.
Let me again share a similar example from Spring. Imagine a `Tree` bean
implementing `Lifecycle`. Other beans can inject this _shared_ `Tree` bean and
they don't need to manage the lifecycle of the `Tree` – Spring will take care
of it. But, if the bean is prototype-scoped, that is, every injection point
gets a new instance, Spring will not manage the bean's lifecycle anymore. I
think what we are dealing with is somewhat analogous. If recyclers will be
shared (of which I still need to hear a use case for), I understand the
sentiment for having a single registry to shut them down. Otherwise, we can
delegate that responsibility to the component creating it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
