[JIRA] Resolved: (JXT-88) AbstractXMLObject unnecessarily creates a new QName in getElementQName

[Brent Putman (JIRA)]

     [ https://issues.shibboleth.net/jira/browse/JXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brent Putman resolved JXT-88.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 1.3.5

getElementQname fixed in r757.

I don't see any instances in this class of log trace being used inefficiently that require wrapping in isTraceEnabled. If you are referring to calls like this:

log.trace("Releasing cached DOM reprsentation for {}", getElementQName());

that is not inefficient.  SLF4J does not do the parameter interpolation into the message string until after it's determined whether logging will fire for that logger and category. That optimization is one of the major advantages over for example log4j.

If on the other hand things being passed to the log call are expensive operations (as opposed to just a getter), then I agree that that warrants wrapping in isTraceEnabled, isDebugEnabled, etc.

If you were referring to instances of potentially inefficient logging in another class or classes, please open another issue for those.

> AbstractXMLObject unnecessarily creates a new QName in getElementQName
> ----------------------------------------------------------------------
>
>                 Key: JXT-88
>                 URL: https://issues.shibboleth.net/jira/browse/JXT-88
>             Project: XMLTooling - Java
>          Issue Type: Bug
>    Affects Versions: 1.3.4
>            Reporter: anli.shundi at idp.protectnetwork.org
>            Assignee: Brent Putman
>            Priority: Minor
>             Fix For: 1.3.5
>
>
> Since QName is immutable the member should be instead returned.
> Talking about optimizations: it would be preferable to check isTraceEnabled before concatenating & passing arguments to trace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira