As the author of the original WxLog package (which is not open-source to the best of my knowledge) it seems an ill-advised idea to publish an incompatible package under the same name.

It comes with the risk of at least confusing customers and potentially even causing production issues.

Now to the criticism of shipping duplicate jars. That is indeed a bad idea, if the jars are truly duplicates. On the other hand there is the aspect of versions. Given that at least historically Integration Server has often lagged behind with updating external jars (like Log4j2 or various Apache Commons libraries) it may indeed be the safer way to ship your own stuff and activate the package class loader for that package.

But I agree that shipping jars in the `./code/jars/static/` dir is something to be very careful with, given that those classes end up in the global server class loader.

Lastly, I am "surprised" by this claim on GitHub:

It is indeed correct that a package under the name WxLog has been used in production by several high-profile customers for more than 10 years (again, I am the author of this).

But it has nothing to do with this project on GitHub. The latter is obviously a fresh implementation, that even has auto-generated comments in catch blocks. Together with the fact that the code repo (as of this writing) only contains 5 commits makes me weary about its maturity.

As much as I try to not go negative in forums and social media, I make an exception here and join @Gerardo Lisboa in his verdict: This package is not production ready.

It may well serve as a code sample, although in this case I would be selfish enough to recommend my own (https://github.com/JahnTech/webmethods-is-log4jdemo).

As the author of the original WxLog package (which is not open-source to the best of my knowledge) it seems an ill-advised idea to publish an incompatible package under the same name.

It comes with the risk of at least confusing customers and potentially even causing production issues.

Now to the criticism of shipping duplicate jars. That is indeed a bad idea, if the jars are truly duplicates. On the other hand there is the aspect of versions. Given that at least historically Integration Server has often lagged behind with updating external jars (like Log4j2 or various Apache Commons libraries) it may indeed be the safer way to ship your own stuff and activate the package class loader for that package.

But I agree that shipping jars in the `./code/jars/static/` dir is something to be very careful with, given that those classes end up in the global server class loader.

Lastly, I am "surprised" by this claim on GitHub:

It is indeed correct that a package under the name WxLog has been used in production by several high-profile customers for more than 10 years (again, I am the author of this).

But it has nothing to do with this project on GitHub. The latter is obviously a fresh implementation, that even has auto-generated comments in catch blocks. Together with the fact that the code repo (as of this writing) only contains 5 commits makes me weary about its maturity.

As much as I try to not go negative in forums and social media, I make an exception here and join @Gerardo Lisboa in his verdict: This package is not production ready.

It may well serve as a code sample, although in this case I would be selfish enough to recommend my own (https://github.com/JahnTech/webmethods-is-log4jdemo).