kriegaex commented on PR #133:
URL: https://github.com/apache/xalan-java/pull/133#issuecomment-1837372231
@vlsi: FWIW, @jkesselm just mentioned in a private chat that there seems to
be some kind of internal (not 3rd party) logging framework in use in the
project, despite me also having found ~700 occurrences of
`System\.(out|err)\.print` in the code (excluding examples and ITs). I.e., it
is not used universally. I would have expected only a handful of direct logs to
stdOut and stdErr in framework/utility methods, and everything else that is
supposed to log something or print something to the console in a CLI
application to use utility methods. Then, it would have been easy to find those
methods, used everywhere. But they are, in fact, not used everywhere. I guess,
we both did not know that such logging infrastructure exists, otherwise
probably you would have suggested it to me. then, I could have done something
like
* log a one-line warning to the info or warning channel,
* log the full stack trace to the debug or error channel.
The test could then have used the appropriate log level and an in-memory
logger and even inspect the logs from a unit test.
Joe could not tell me right away how to use this logging framework or where
to copy code from, because he has just returned to the project after a long
absence. But if it can be used outside a Xalan context (i.e. just from the
version classes), in the future we could easily change the code to log there,
even using multi-language resources according to Joe. That would, however, make
the version classes do way more than the old ones did, but it would certainly
be possible.
Because these are the very first unit tests in this project (not
externalised like the ones in _xalan-test_), I did not want to create a
precedent of a non-thread-safe test right in the first example. Like I said, it
would be super easy to set `System.err` to a `PrintStream` wrapping a
`ByteArrayOutputStream` for the duration of the test and even inspect the
logging results. The result would be a silent test (no log output to the
console), which would certainly be nice to have. But I guess, we should wait
for Joe to explain to us how to use the internal log facilities, before we
decide how to handle this in the future.
The cleanest thing would be to migrate the whole product away from internal
tool classes and use 3rd party ones, specifically designed for that task. Less
code to maintain in the long run. Same goes for the internal test framework.
But both would be huge separate PRs, nothing to be debating withing the
confines or a single, small PR like this one, which adds testing frameworks and
a handful of initial tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
