deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Porter <>
Subject Re: [DISCUSS] Logging
Date Mon, 23 Jan 2012 16:02:06 GMT
I'm pretty much at a +0 for the features now. I thought i18n would be helpful, but Mark, you
make a very good case. The type safe logging again, is a neat concept but certainly isn't
a must for logging. 

What we've stared doing in many of the JBoss projects is having error codes, like those blasted
ones from Oracle that you always have to lookup because no one knows what they are and there's
no central location for them. You can see this in weld, where I think we do a good job of
also explaining what the problem is. 

That critique aside, I think they can be a good thing as we can centralize a knowledge base
for them, and users can troubleshoot for themselves. Also with the more common ones you won't
have to read the whole log message. 

Sent from my iPhone

On Jan 23, 2012, at 5:37, Christian Kaltepoth <> wrote:

> -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]
> [2]
> 2012/1/23 John D. Ament <>:
>> 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 <> 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
>>> 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:
> Twitter:

View raw message