No, we haven't been perfectly consistent in using a logger. At the time we were more concerned with controlling error reporting by severity level than with being able to filter CLI/progress messages. The few instances of System.err remaining in the code appear to be debugging tools, either in methods that are not used during normal operation, commented out, or behind `if(DEBUG)` fences.
The logging API we use for errors is actually built into the JAXP standard which Xalan's primary API contributed to/converged with: `javax.xml.transform.ErrorListener`. Typically we use the instance created by the `TransformerImpl` instance which launches the processor, retrieved via `TransformerImpl.getErrorListener()`. There are few convenience wrappers and accessors for this in `TransformerImpl`, and you will see calls to JAXP TransformerImpl.getMsgMgr() which wind up coming back through this system.
(The fact that we also predate -- and influenced -- JAXP means that we're less than perfectly consistent about which layer of that stack we access.)
The I18n layer is `org.apache.xalan.res.XSLMessages` and `org.apache.xalan.res.XSLTErrorResources` . The latter provides enum values for the internationalized error messages; the former is a formatter which retrieves the language-specific string and drops values into the appropriate slots. Note that adding new errors to Xalan involves translating them into roughly 20 languages; that involved a lot of expensive human translator time so we tried to reuse existing messages whenever appropriate. These days Google Translate *might* be good enough to handle new messages, but I'd still want native speakers to sanity-check the results since Google can be embarrassingly wrong.
Example of usage, randomly grabbed from ElemElement.java:
```
// Only validate if an AVT was used.
if ((nodeName != null) && (!m_name_avt.isSimple()) &&
(!XML11Char.isXML11ValidQName(nodeName)))
{
transformer.getMsgMgr().warn(
this, XSLTErrorResources.WG_ILLEGAL_ATTRIBUTE_VALUE,
new Object[]{ Constants.ATTRNAME_NAME, nodeName });
nodeName = null;
}
```
There should be javadoc for all of this, though I'm not sure how
self-evident any of it is without the background or examples -- but
there are no shortage of examples.
Yes, if we were rewriting Xalan from scratch now we would do many things differently. Real world 20-year-old barely-maintained code. It has older solutions, and vestages of even older ones, and incomplete migration to newer ones, Cleaning that sort of thing up tends to be among the lowest priorities in the backlog, as long as it's working.
The good news is that we may not be vulnerable to the recently discovered Log4J security issue; we predated Log4J too. Sometimes there are advantages to being a dinosaur; ask any bird.
-- ` /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. Feel free to call him on it.
OpenPGP_0xFFBAFF963D937815.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
