remove logback.xml from cssbox jar

[Ali Cheaito]

Hello,

First I want to thank you for publishing this great software. It is one of
very few available Open Source options out there for someone looking to
render html in Java.

Now to the matter at hand. I noticed the presence of a logback.xml
configuration file inside of cssbox.jar. This type of setup can cause
issues in Java EE applications. The file would conflict with the one in the
Web Application if both used logback, potentially causing logging
inconsistencies. Imagine if the CssBox dependencies (xerces, antlr, etc..)
also packaged their own logback.xml. You would've had a lot of trouble
figuring out why cssbox's logback does not function as intended.

Generally, only the end user would be the one to decide on:

• What logging implementation to use (logback, log4j, etc)
• Configuring the loggers (logback.xml, log4j.properties, etc)

With that in mind, I would also remove logback-classic and logback-core
from the lib folder and let the end user supply their logging
implementation.

Thanks!

[Radek Burget]

Hi, this seems a very reasonable comment, thanks for pointing this out. However, what about the users who are not using any logging API in their application? I am afraid that I will receive complaints about missing dependencies and the configuration file. Is there a usual way how this is solved?

[Ali Cheaito]

For apps that are do not provide a logging implementation, slf4j will display the following warning:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Following the link in the warning will help them get a logging implementation in place to get rid of the warning and view cssbox logging statements. Regardless, their application will work just fine.
Additionally, you can mention in the cssbox documentation site the need for providing an slf4j implementation and what the cssbox logger names are, to allow end-user full control over these loggers when/if they decide to have a logging framework in place.

This approach should work for most clients. A typical application's logback.xml or log4j.properties contain logger configuration for multiple third party jars in use (e.g: org.apache, httpclient.wire, etc).

So, as you can see, including the logging implemenation has a good potential of causing issues, but excluding it will only yield the warning above.

[Radek Burget]

Many thanks for clarification. I have removed the logback dependency and the configuration file from the git repo. They won't be contained in the next release package.