raner / loginject Goto Github PK

Right now, the API, SPI, and all service implementations are all in the org.loginject package. This is obviously not a good situation, and the various classes should be broken up into separate packages.

Instead of

loginject(Logger.class, LogManager::getLogger, currentClass())

one should be able to write

loginject(LogManager::getLogger, currentClass())

By calling the supplied method reference, it is possible to obtain a logger instance and to determine its class.
The only problem is that many logging frameworks use logger interfaces that are implemented by internal classes. loginject needs to determine interface candidates and provide bindings for all of them.

loginject currently has a few problems when building locally:

• Maven build on a new machine fails without private key (similar to Projo Issue #37)
• loginject does not compile on Java 11 (similar to Projo Issue #38)

Hi,
I wanted to use your guice extension it seems really good but sadly I can't instanciate it.

Module module = loginject(Logger.class, LogManager::getLogger, currentClass()).as(Module.class);

I have a compilation error :

Non-static method cannot be referenced from a static context

any idea ?

Thank you for your answer

A new project was created for loginject in the Central Repository: https://issues.sonatype.org/browse/OSSRH-26875

The POMs need to be modified to enable a first release.

static class TestClass
{
    @Inject
    Logger injectedLogger;
}

static class SubClass1 extends TestClass {}

static class SubClass2 extends TestClass {}

Currently, for the above scenario, a Logger for TestClass is injected into SubClass1 and SubClass2.
Instead, the subclasses should have their own loggers specific to the type.

This feature can definitely be implemented for Guice and HK2, but most likely not for Dagger (maybe via some trickery with MembersInjector, but Dagger's static nature makes these sort of injections difficult).

Coding standards could be enforced in a number of different ways:

• Checkstyle
• Using Eclipse JDT compiler

Currently, it is not possible to implement a custom LogInjectionService because the interface is not public

Logging is a cross-cutting concern, so it makes sense to offer basic support to achieve logging in an AOP fashion.

Though Guice 3.0 is nowadays long out-of-date, a number of projects are still "stuck" on this old version of Guice (the most notable one probably being Xtext).
LogInject's Guice (4.x) implementation leverages the com.google.inject.spi.ProvisionListener, which is not present in Guice 3.0.
If Guice 3.0 has a similar mechanism, it would be nice to offer a loginject adapter for Guice 3.0 as well.

As it turns out, just returning an AutowireCandidateResolver that handles just loginject dependencies and returns null for all other dependencies does not quite work.
I recently tried to use loginject in the following manner on Spring 5.3.19:

class Configuration
{
  @Value("${host.url}")
  String hostUrl;

  @Inject
  Logger logger;
}

If I added loginject to the Spring configuration injection of the field annotated with @Value no longer worked.

Having test projects that are specific to a particular logging system and test all DI framework adapters (e.g., loginject-test-log4j) is a problematic approach for a number of reasons. For example, Dagger and Dagger 2 use the same package name, so it is not possible to have both DI frameworks on the classpath at the same time. Also, in the DI-specific tests that are part of each DI adapter, there is a considerable amount of code duplication for setting up the test scenarios.

Ideas:

• Have a common project as a test dependency that contains all test scenarios (without bindings)
• Each DI adapter provides bindings for the test scenario
• Maybe introduce an abstraction to the various instantiation APIs, so that shared tests can be run for each DI adapter, provided that there is a binding and an instantiation adapter implementation
• The shared test scenario project could depend on all tested logging frameworks
• Utilize JUnit parameterized testing to support Cartesian product of (all DI adapters) x (all logging frameworks)