I'm not an expert on the subject, but as an outsider looking in, it seems to me 
that logging performance is a moot point - since logging is typically used as a 
debugging tool. It is unlikely that a high-demand or high-performance 
application will be doing a lot of logging.

Also, it seems you are questioning the JBoss contributors best practices in 
your post. Why not follow the best practices and let someone else worry about 
the pros and cons of static Log instances? If static Log instances cause a 
configuration problem in certain app containers, then it will be evident in the 
bug tracker - and someone down the road will make the appropriate change to fix 
the bug.

In other words, if it was me, I wouldn't worry about it.

-Adrian

--- On Thu, 9/9/10, Cardillo, Ray - IS <ray.cardi...@itt.com> wrote:

> From: Cardillo, Ray - IS <ray.cardi...@itt.com>
> Subject: Static versus Transient Logger Declarations
> To: "log4j-u...@logging.apache.org" <log4j-u...@logging.apache.org>, 
> "user@commons.apache.org" <user@commons.apache.org>
> Date: Thursday, September 9, 2010, 9:27 AM
> I have recently started a
> discussion<https://community.jboss.org/message/558408#558408>
> about the use of Static versus Transient Logger declarations
> in open source libraries that are intended to be used in
> multiple application containers (or other contexts) after
> reading the following Apache Commons Logging article:
> 
> Logging/StaticLog
> http://wiki.apache.org/commons/Logging/StaticLog
> 
> The article seems sound to me, and does a good job of
> explaining why Transient is generally the better strategy,
> should not cause any tangible performance degradation with
> most modern logging libraries, and more importantly, why it
> will actually work correctly when used in anything but the
> simplest Java application.  However, some people have
> responded to this thread by either focusing on performance
> (which seems to be a mute point in my opinion) or by
> focusing on the features of one specific Logger library
> implementation.  Both perspectives seem to be short
> sited if you are intending to create a library that can be
> used in any context (e.g., any application container,
> application, used by another library, etc).
> 
> I am asking for participation from the Apache community
> because some replies have (politely) discredited or
> dismissed the Apache article that I referenced.  If the
> article is in fact out of date, then can someone please
> verify that, and amend the Apache Commons Wiki?  If the
> article is not outdated, and is still technically accurate,
> then can someone who is intimately familiar with this topic
> step forward and help defend the position, and educate
> others who might be interested in this topic?  I would
> like to see the correct strategy employed in future work by
> this community (and other open source communities) because
> many open source libraries are incubated under bigger
> projects like JBoss AS, but intended to be used more widely
> as well.  I would hate to see the incorrect pattern
> being proliferated just because it is the "de facto norm"
> especially if there is an opportunity to help educate
> everyone about a better approach.
> 
> So in summary, I am asking for help getting facts (not
> opinions) communicated about Static versus Transient Logger
> declarations, so developers who are creating libraries that
> are intended to be used in any context (any application
> container, etc), can have a solid reference about which
> strategy is best.  Again, for easy reference, the link
> to the forum discussion is:
> 
> Better strategy for instantiation of Logger instances
> (static causes problems)
> https://community.jboss.org/message/558408#558408
> 
> 
> Thanks in advance to anyone who participates!
> 
> Ray Cardillo
> Principal Software Engineer
> ITT Corporation
> Advanced Engineering & Sciences (AES)
> Rome, NY
> 
> ________________________________
> This e-mail and any files transmitted with it may be
> proprietary and are intended solely for the use of the
> individual or entity to whom they are addressed. If you have
> received this e-mail in error please notify the sender.
> Please note that any views or opinions presented in this
> e-mail are solely those of the author and do not necessarily
> represent those of ITT Corporation. The recipient should
> check this e-mail and any attachments for the presence of
> viruses. ITT accepts no liability for any damage caused by
> any virus transmitted by this e-mail.
> 


 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to