deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Kaltepoth <christ...@kaltepoth.de>
Subject Re: [DISCUSS] Logging
Date Mon, 23 Jan 2012 12:37:28 GMT
-1 for i18n and typesafe logging.

I agree with Mark that something like this doesn't make sense for
"technical logging". I would prefer to use slf4j or something similar.

An alternative to slf4j would be to create a custom minimal logging
API. Lincoln and I did this for PrettyFaces/Rewrite (see [1]). It's
based on the ServiceLoader approach to support multiple logging
frameworks (see [2] for the SPI). Per default everything is logged
using "java.util.logging" which is fine for most users. For more
advanced use cases and during development time you can simply add
another artifact to your dependencies to switch to something like
log4j.

I'm not sure if this would also be useful for DeltaSpike. I would also
be fine with slf4j. I'm just throwing out some ideas into the
discussion. :)

Christian

[1] https://github.com/ocpsoft/logging/tree/master/api/src/main/java/com/ocpsoft/logging
[2] https://github.com/ocpsoft/logging/blob/master/api/src/main/java/com/ocpsoft/logging/spi/LogAdapterFactory.java



2012/1/23 John D. Ament <john.d.ament@gmail.com>:
> Personally, logging needs to be really fast and usable anywhere in a
> non-convoluted way.  I cannot use this type of logging in a static method
> (for example) because I have to look up a bean manager, then work on
> resolving a reference to this interface.  Then I may have just wasted my
> time because the logging message's priority is below my threshold.  We also
> need to make sure logging is available in CDI extensions.  Since you can't
> always inject beans into your extension, you can't guarantee that you have
> a logger available.
>
> So to sum up...
>
> +1 to using slf4j or similar in our code, and possibly even providing
> injection points for slf4j as a part of our core, but -1 to providing
> typesafe logging or i18n style logging, since it can't be used everywhere,
> and the notes that strub raised as issues with it (granted, sometimes when
> I look at "english" log messages they don't even make sense! :-)
>
> John
>
> On Sun, Jan 22, 2012 at 10:22 PM, Ken Finnigan <ken@kenfinnigan.me> wrote:
>
>> All,
>>
>> As we approach a 0.1 release of DeltaSpike, congratulations to everyone on
>> the good work so far, I feel it's a good time to begin discussing how we
>> want to handle logging within DeltaSpike.  I certainly don't expect this
>> discussion to result in code for 0.1, but the earlier we begin this
>> discussion, then it increases the likelihood of it being ready for 0.2
>>
>> Having been heavily involved in the logging work for Solder, I know the
>> pain that can be experienced in not getting it right, and also how long it
>> can take to get right.
>>
>> I see that there are several goals that we want for logging in DeltaSpike:
>>
>>   1. Make it simple for both extension writers and end users.  If it's too
>>   difficult to implement, use or even get right, then we'll frustrate and
>>   alienate developers.
>>   2. It must perform.  We don't want to introduce large overhead to
>>   logging.
>>   3. There should be an option to allow/provide type safe logging. [1]
>>   4. An end user should be able to have DeltaSpike log against whichever
>>   logging library they want to utilize in their application.  We can
>>   certainly support a specific framework as a default, but it's important
>> to
>>   allow a developer to have the same control over how DeltaSpike is logged
>> as
>>   their own application.
>>
>> Thoughts?
>>
>> Regards
>>
>> Ken Finnigan
>>
>>
>> [1] An example of type safe logging, from Solder, is to define an interface
>> such as:
>>
>> @MessageLogger
>> public interface BirdLogger {
>>    @Log
>>    @Message("Spotted %s Hawks")
>>    void logHawksSpotted(int number);
>>
>>    @Log
>>    @Message("Spotted %s Owls")
>>    void logOwlsSpotted(int number);
>>
>>    @Log
>>    @Message("Spotted %s Bald Eagles")
>>    void logBaldEaglesSpotted(int number);
>> }
>>
>> and then create properties files for each language that you want to support
>> for these log messages.  For instance, if the interface existed in the
>> org.deltaspike.logging package, then you would create
>> org.deltaspike.logging.BirdLogger.i18n_fr.properties containing names
>> matching the methods on the above interface, and values representing
>> localized versions of the String within @Message.
>>
>> Finally, a compile time annotation processor would generate concrete
>> classes for each interface and localized version.  In the above example you
>> would end up with BirdLogger.class and BirdLogger_fr.class
>>
>> To use the logger that was generated, you then simply do something like:
>>    @Inject
>>    private BirdLogger logger;
>>
>>    public void generateLogMessage() {
>>        logger.logBaldEaglesSpotted(2);
>>    }
>>



-- 
Christian Kaltepoth
Blog: http://chkal.blogspot.com/
Twitter: http://twitter.com/chkal

Mime
View raw message