Proper logging #19
Comments
|
Do you know a way to set logging level for messages in XSLT? Also, I've found that naming as many XProc steps as possible (with the |
|
Setting logging level for xsl:message, don't think Calabash provides something like that. We should probably make our own pf:message template/function for that. Another thing is that AFAIK messages in XProc/XSLT are always send to event bus, and messages in Java are always send directly to SLF4J logger. There could be the need for sending to event bus from Java (and maybe for sending directly to SLF4J from XProc/XSLT although that's less likely). |
|
Calabash always makes xsl:message into INFO: see XSLT.java#L356 |
|
In order to log messages per job, from Java, some non-trivial changes are needed. In XProc/XSLT it is always known where messages have to go (what the current job is), because each job has its own Calabash runtime and each runtime has its own message listener. In Java however we don't know what the current job is. In order to know, objects that produce messages either have to be recreated for each new job, or their methods have to have a job object argument. The former sounds more feasible. In practice, this would mean that instead of connecting (with OSGi) TransformProvider objects, we would be connecting PerJob objects, where PerJob is an extra indirection for getting the instance belonging to the current job. |
The main purpose is to be able to create job messages from Java. JobContext currently implements the SLF4J Logger interface. Messages sent to this logger should be forwarded to the framework's message event bus. The idea is that eventually we'll get JobContext objects from the framework, but for the time being I construct my own JobContext that uses a hack with Calabash's XProcMessageListener. See issue #19
The main purpose is to be able to create job messages from Java. JobContext currently implements the SLF4J Logger interface. Messages sent to this logger should be forwarded to the framework's message event bus. The idea is that eventually we'll get JobContext objects from the framework, but for the time being I construct my own JobContext that uses a hack with Calabash's XProcMessageListener. See issue #19
in order to improve user experience and to make debugging easier.
The text was updated successfully, but these errors were encountered: