Not an issue yet, just a heavy concern.. We were trying to use a custom log4j2 Kafka appender on CloudHub and the conclusion (confirmed by Mulesoft support) was that it will never work, because the log4j2 is initialized by their application server's classloader, while the Kafka appender is shipped through our worker application, and the system classloader will not delegate to the application classloader. Well, they did not phrase it that technically, but the conclusion was that.
Now I wonder how your custom SQS log4j2 appender could behave otherwise, if it also gets packaged into the application worker's jar file. Won't we meet the exact same classloading issue when deploying to CloudHub? Or how did you get it to work, given how CloudHub works?
Note also that your artifacts are not rolled out to maven central.. Sure I can roll my own releases from source, but you might want to deploy to an official repo as well.
Not an issue yet, just a heavy concern.. We were trying to use a custom log4j2 Kafka appender on CloudHub and the conclusion (confirmed by Mulesoft support) was that it will never work, because the log4j2 is initialized by their application server's classloader, while the Kafka appender is shipped through our worker application, and the system classloader will not delegate to the application classloader. Well, they did not phrase it that technically, but the conclusion was that.
Now I wonder how your custom SQS log4j2 appender could behave otherwise, if it also gets packaged into the application worker's jar file. Won't we meet the exact same classloading issue when deploying to CloudHub? Or how did you get it to work, given how CloudHub works?
Note also that your artifacts are not rolled out to maven central.. Sure I can roll my own releases from source, but you might want to deploy to an official repo as well.