Usually logging frameworks support configuring different levels of logging at
different package levels. While I am +1 for having a clear separation of
TRACE level messages vs DEBUG level messages
Sanjaya
Actually this problem is not local to parameter manipulation... it
exists in Axiom as well and maybe elsewhere..
e.g.
1816 [Axis2 Task] DEBUG org.apache.axiom.om.impl.MTOMXMLStreamWriter -
Call Stack =DEBUG_FRAME =
org.apache.axiom.om.util.CommonUtils.callStackToString(CommonUtils.java:80)
DEBUG_FRAME =
org.apache.axiom.om.impl.MTOMXMLStreamWriter.<init>(MTOMXMLStreamWriter.java:91)
DEBUG_FRAME =
org.apache.axiom.om.impl.llom.OMNodeImpl.serialize(OMNodeImpl.java:462)
DEBUG_FRAME =
org.apache.axis2.transport.http.SOAPMessageFormatter.writeTo(SOAPMessageFormatter.java:77)
Also consider this fragment:
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - There are
no child elements that match the unqualifed name: module
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - Now
looking for child elements that have the same local name.
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - There are
no child elements that match the unqualifed name: transportSender
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - Now
looking for child elements that have the same local name.
743 [main] DEBUG org.apache.axiom.om.impl.llom.OMElementImpl - There are
no child elements that match the unqualifed name: transportReceiver
....
Stack traces as strings and these types of very low level messages I
think should be at TRACE..
.. that type of a configuration could help reduce too many unrelated log
messages in the log when troubleshooting a problem.
The problem is that the log level is inherited by the Axis2 log level..
and it wont be nice to expect users to explicitly exclude this category
asankha
On Friday 14 November 2008, Asankha C. Perera wrote:
Hi All
I am seeing loads and loads of the following log message, which dumps
the thread stack whenever a Parameter was added.. This severely clutters
the log files, and makes it difficult to troubleshoot any other problems.
Although this level of debug information would be valuable to nail down
some issues local to this area, I do not think this should be left
enabled when Axis2 log level is debug.. ideally this could be only at a
TRACE level, probably when another switch is turned on as well.
asankha
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
==================
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Parameter add on object
[EMAIL PROTECTED]
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Key =hotdeployment
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Value =true
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Value Class = java.lang.String
720 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Value Classloader = null
721 [main] DEBUG org.apache.axis2.description.ParameterIncludeImpl -
Call Stack = DEBUG_FRAME =
org.apache.axis2.util.JavaUtils.callStackToString(JavaUtils.java:564)
DEBUG_FRAME =
org.apache.axis2.description.ParameterIncludeImpl.debugParameterAdd(Paramet
erIncludeImpl.java:315) DEBUG_FRAME =
org.apache.axis2.description.ParameterIncludeImpl.addParameter(ParameterInc
ludeImpl.java:106) DEBUG_FRAME =
org.apache.axis2.description.AxisDescription.addParameter(AxisDescription.j
ava:102) DEBUG_FRAME =
org.apache.axis2.deployment.DescriptionBuilder.processParameters(Descriptio
nBuilder.java:568) DEBUG_FRAME =
org.apache.axis2.deployment.AxisConfigBuilder.populateConfig(AxisConfigBuil
der.java:101) DEBUG_FRAME =
org.apache.axis2.deployment.DeploymentEngine.populateAxisConfiguration(Depl
oymentEngine.java:707) ...
... ## TRUNCATED ## ..
...
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
