Avoid exceptions when dumping ctx

[barspi]

When dumping the transaction manager context entries, if an exception was thrown in the dump() of a Loggeable or the toString() of the last-resort case for printing an entry value, then the context dump would explode with the exception.

This had two problems:

1. leaving an incomplete context dump
2. leaving an invalid XML log
   For example

<log realm="org.jpos.transaction.TransactionManager" at="2024-11-21T12:38:49.741993" lifespan="130ms">
  <abort>
    ...
    <context>
    ...some ctx entries...
    ...some ctx entries...
      ACCOUNT: org.hibernate.LazyInitializationException: could not initialize proxy [org.jpos.gl.FinalAccount#1980] - no Session
    at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:176)
    at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:322)
    ... (more stack trace) ...
</log>

As can be seen, the toString() of the value for the ACCOUNT entry (some hibernate proxy in the example, but it's irrelevant to the explanation), threw an Exception.

The rest of the ctx is not dumped, but worse: </context> and </abort> are not closed.

This PR fixes that.

[alcarraz]

Perhaps it would be nice to also print an explanation of what happened, so it is clearer at a first look to the std err, that it was an exception while dumping before having to pay attention to the stack trace.

This could even be a new log event to be sent to the default logger, with the message and the exception

[ar]

It's not printing to stderr, it goes to the PrintStream, along with the rest of the message.

[alcarraz]

Last time I checked ex.printStackTrace, printed to std err.

Prints this throwable and its backtrace to the standard error stream. This method prints a stack trace for this Throwable object on the error output stream that is the value of the field System.err. The first line of output contains the result of the toString() method for this object. Remaining lines represent data previously recorded by the method fillInStackTrace(). The format of this information depends on the implementation, but the following example may be regarded as typical:

[alcarraz]

Oups, sorry, I didn't see the pint stream parameter 🤦🏼‍♂️

[barspi]

In my tests, it will appear like

      ACCOUNT: org.hibernate.LazyInitializationException: could not initialize proxy [org.jpos.gl.FinalAccount#1980] - no Session
    at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:176)
    at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:322)
    ... (more stack trace) ...

and then continue with the rest of the ctx dump as usual, closing every XML tag correctly

(at least for the toString() case... not sure the Loggeable one)