rmannibucau commented on issue #8321:
URL: https://github.com/apache/hop/issues/8321#issuecomment-5662049983

   @mattcasters the journey was a but cumbersome, I started from enabling otel 
javaagent (and basically several auto instrumentation flavors in k8s), then 
ensuring the integration will be engine friendly (spark, flink, local runner - 
beam, as well as standalone case with a log collector) sticking to a natural 
logging configuration for dev and ops. 100% ack this is *not* the hop 
GUI/server case which has specific needs but these are also real consumers of 
apache hop.
   
   The thought path I took is why would the gui and server be specific since at 
the end they do share the same needs than the others. So leaning to ensure hop 
can get structured logging (collector friendly) I decided to try to abstract 
its log publish flow behind the natural API which was in the project (slf4j) 
which is all env friendly.
   
   I understand it can be a big change for historical users but ideally there 
shoudln't be much impact except the few env var and it enables so much new 
cases without duplicating logging code paths that it is a huge win for the 
project IMHO since it will avoid to start to be inconsistent between both paths 
in the future (we had that issue at some point with Apache TomEE which was 
using 4-5 logging framework due to its aggregation of deps and prod was missing 
3/4 of the logs regularly, trying to avoid it can happen by design there).


-- 
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]

Reply via email to