[hibernate-dev] logging
As hopefully everyone is aware by now we have switched over to use JBoss
Logging for our logging api in 4.0. JBoss Logging provides 2 unique
capabilities that we for sure wanted to leverage and I think I am just
now starting to come to grasp with. So I wanted to discuss some stuff
related to them.
The first capability is built in i18n support.
The second is the idea of keyed messages. Each message has a consistent
alphanumeric key by by which you can, for example, refer to the
condition that caused the particular log message in say documentation.
Additionally as with most logging frameworks, you have a notion of a
logger or category.
All logging ends up targeting different audiences. Some messages are
meant directly for the developer and are meant to aid them during
development ("hey you messed up this mapping construct"). Others are
meant to help admin/support folks understand what is going on in a
running system that might be causing problems.
In my opinion, there are other natural things to do here depending on
which audience is being targeted. Take category names, for example; for
developer-centric messages I think using the name of the originating
class (current scheme) makes the most sense; but for other audiences
having consistently named categories that can survive package
reorganization and so can be better documented in user docs is a bug win.
There is an inherent design decision in JBoss Logging that if you use
the stuff in the most straight forward way, you end up limited to a
single category scheme and limiting yourself to trace and debug logging
for the developer audience and info/warn/error for "admin" audience. So
the question I ask is whether we want to just go that route, or if we
want to invest in a quite possibly over-engineered approach were we
cater to this idea of separate channels.
The big issue to me is the lack of granularity in "developer targeted
messages". This goes hand in hand with quick dev/test cycles. As an
illustration, I cranked up logging to (mostly) TRACE during a run of the
hibernate-core test suite, which took approx 13 minutes. Dropping that
log level back down to INFO and the test suite ran in 2 minutes. That
is significant.
What would the alternative look like?
Well in JBoss Logging, i18n is provided by means of a proxied interface.
Hibernate defines this interface and provides it to JBoss Logging:
@MessageLogger( projectCode = "HHH" )
public interface CoreMessageLogger extends BasicLogger {
@LogMessage(level=INFO)
@Message(value="Hello %s", id=1)
void sayHello(String name);
...
}
CoreMessageLogger log = Logger.getMessageLogger(
CoreMessageLogger.class,
this.getClass()
);
(the second argument is the category name, here our class name)
So again, with just those pieces we have the intended JBoss Logging
setup. You would have a boat load of messages at TRACE/DEBUG the
develop needs to see so they still need to "crank up the logging". Now
luckily the category is still friendly here in that respect since they
can define which classes/packages on which to crank up the logging.
So an alternative is to use this notion of channels:
@MessageLogger( projectCode = "HHH" )
public interface CoreAdminMessageLogger extends BasicLogger {
@LogMessage(level=INFO)
@Message(value="Hello %s", id=1)
void sayHello(String name);
...
}
@MessageLogger( projectCode = "HHH" )
public interface CoreDevMessageLogger extends BasicLogger {
@LogMessage(level=INFO)
@Message(value="Loading the HelloComponent implementation %s", id=501)
void loadingHelloComponent(String implementationName);
...
}
CoreAdminMessageLogger adminLog = Logger.getMessageLogger(
CoreAdminMessageLogger.class,
"org.hibernate.core.hello"
);
CoreDevMessageLogger devLog = Logger.getMessageLogger(
CoreDevMessageLogger.class,
this.getClass()
);
I realize this all seems over-engineered in many ways. I do see *some*
benefit. I guess the decision I need help weighing is whether this
amount of benefit out-weighs the "complexity".
Thoughts?
--
Steve Ebersole
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] logging
What's the implication to the logged message content behind using a class name vs. a subsystem name as a category? Would it be correct to assume the class name/line number would only appear in the message if you use the class name as a category? Or is that something more tied to the underlying logging implementation? JPAV ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] logging
category is what you use to configure logging in the major logging frameworks. No, class name and line number are part of what is called "location information" which is usually a formatting option. But its expensive, as it generally means the logging framework creating an Exception and looking through its stack trace. On 04/12/2011 11:24 AM, John Verhaeg wrote: > What's the implication to the logged message content behind using a class > name vs. a subsystem name as a category? Would it be correct to assume the > class name/line number would only appear in the message if you use the class > name as a category? Or is that something more tied to the underlying logging > implementation? > > JPAV > > > > -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] cacheable files
Do we want to make caching of files a flag for processing all of the xml files? Currently we have methods: addFile(String path) addFile(File file) addCacheableFile(String path) addCacheableFile(File file) Could we instead condense these and allow configuration of whether to try and cache xml files? -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] cacheable files
Hm, if we move to jaxb are those generated binding classes serializable? On 04/12/2011 02:41 PM, Hardy Ferentschik wrote: > > > > > On Apr 12, 2011, at 21:26, Steve Ebersole wrote: > >> Do we want to make caching of files a flag for processing all of the xml >> files? >> >> Currently we have methods: >> addFile(String path) >> addFile(File file) >> addCacheableFile(String path) >> addCacheableFile(File file) >> >> Could we instead condense these and allow configuration of whether to >> try and cache xml files? > > Sounds like a good idea to me. -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] cacheable files
> Do we want to make caching of files a flag for processing all of the xml > files? > > Currently we have methods: > addFile(String path) > addFile(File file) > addCacheableFile(String path) > addCacheableFile(File file) > > Could we instead condense these and allow configuration of whether to > try and cache xml files? This was my original implementation but it was changed to this explicit API with the reasoning that doing this caching should be an explicit act of intent and not just a simple flag working globally. Note, if more than just xml based metadata could be cached that would be awesome - but that might be better solved via something like AS7 annotation index mechanism. /max http://about.me/maxandersen ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] cacheable files
On 04/12/2011 06:01 PM, Max Rydahl Andersen wrote: > This was my original implementation but it was changed to this explicit API > with the reasoning > that doing this caching should be an explicit act of intent and not just a > simple flag working globally. But isn't the user explicitly saying "cache them all" the same on this point? To me it really comes down to whether there is a valid use case for caching some, but not all. > Note, if more than just xml based metadata could be cached that would be > awesome - but that might be > better solved via something like AS7 annotation index mechanism. funny you should say that... ;) -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] cacheable files
2011/4/13 Steve Ebersole : > On 04/12/2011 06:01 PM, Max Rydahl Andersen wrote: >> This was my original implementation but it was changed to this explicit API >> with the reasoning >> that doing this caching should be an explicit act of intent and not just a >> simple flag working globally. > > But isn't the user explicitly saying "cache them all" the same on this > point? To me it really comes down to whether there is a valid use case > for caching some, but not all. +1 for all or nothing. If it's possible / makes sense, and as I see the implementation is checking anyway for file timestamps, I don't see why any more fine grained control could be needed. Should it be on by default? (BTW looking at implementation it seems the IOStreams are never closed - I'm making a patch) >> Note, if more than just xml based metadata could be cached that would be >> awesome - but that might be >> better solved via something like AS7 annotation index mechanism. > > funny you should say that... ;) > > -- > Steve Ebersole > http://hibernate.org > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] cacheable files
Sanne for 3.6 cool, but be aware that we are redoing all of this ATM in master On 04/12/2011 06:15 PM, Sanne Grinovero wrote: > 2011/4/13 Steve Ebersole: >> On 04/12/2011 06:01 PM, Max Rydahl Andersen wrote: >>> This was my original implementation but it was changed to this explicit API >>> with the reasoning >>> that doing this caching should be an explicit act of intent and not just a >>> simple flag working globally. >> >> But isn't the user explicitly saying "cache them all" the same on this >> point? To me it really comes down to whether there is a valid use case >> for caching some, but not all. > > +1 for all or nothing. > If it's possible / makes sense, and as I see the implementation is > checking anyway for file timestamps, I don't see why any more fine > grained control could be needed. > Should it be on by default? > (BTW looking at implementation it seems the IOStreams are never closed > - I'm making a patch) > >>> Note, if more than just xml based metadata could be cached that would be >>> awesome - but that might be >>> better solved via something like AS7 annotation index mechanism. >> >> funny you should say that... ;) >> >> -- >> Steve Ebersole >> http://hibernate.org >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> -- Steve Ebersole http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
