deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lincoln Baxter, III" <lincolnbax...@gmail.com>
Subject Re: [DISCUSS] Logging
Date Tue, 24 Jan 2012 23:25:21 GMT
Funny, I've been meaning to mention this exact implementation but haven't
had the time. Looks like you beat me to it! You designed it so it's
probably better that way ;)

However, I think I'd like to support the argument that using a 3rd party
logging framework like SLF4J might be good for end-user-applications, but
it is not good for us to use in the framework itself. If we do this, we
just further perpetuate the logging conflict. I think what we did in
Rewrite is an elegant solution to avoid this. [1]

Use Java logging as the default logging is usually good enough, then simply
provide additional dependencies that are a drop-in integration with other
logging frameworks.

-1 to i18n and typesafe logging for version one.

~Lincoln

[1] http://search.maven.org/#search|ga|1|g%3A%22com.ocpsoft.logging%22


On Mon, Jan 23, 2012 at 7:37 AM, Christian Kaltepoth <christian@kaltepoth.de
> 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]
> 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
>



-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message