Library overriding default logging level about systemtray

[dorkbox]

This might be an issue because (currently) the RC's bundle all necessary libraries, an artifact driven by it's need to also be used for testing.

It makes sense, as it's an release candidate, to make the jar available as if it were an actual release.

This would likely solve the problem you're having, since I bundle am including logback as the implementation for SLF4j (and you are using log4j).

I will upload a single file system_tray_v3.0.jar (as a placeholder for the actual release) based upon RC9, but without any bundled 3rd party libraries.

You will need to add JNA, SLF4J API, JavaAssist (See the readme for where to download these)

[tresf]

@dorkbox I don't mind simply removing the binding if you can offer some advise how. IntelliJ shows the following:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/tres/tray/lib/logging/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/tres/tray/lib/dorkbox-3.0-rc9.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

[dorkbox]

@tresf I uploaded a jar that has everything removed that is not dorkbox specific, which should solve this issue the easiest way.

You will need to add the appropriate libraries also, and this will be the same with the release.

[tresf]

@tresf I uploaded a jar that has everything removed that is not dorkbox specific, which should solve this issue the easiest way.

Can you please provide a link? The ones I'm looking at (RC9) are about a week old.

Secondly, the HTTPS cert you are using is blocked by Chrome. Is there a reason why you're not using the github releases area to host the files? (you can even use something like Travis-CI to package this up nightly).

Lastly, I'd like to point out that several libraries that we bundle also bundle their dependencies. We're OK with this generally as the redundancies get sorted by our packaging logic, so whichever is easier -- Provide a runnable library but still let us control the Logging on our end -- OR -- provide a nodeps Jar -- is perfectly fine with us. 👍 Whatever takes the burden off of you at packaging time. 🍺

[dorkbox]

https://files2.dorkbox.com/SystemTray/system_tray_v3.0.jar

The https cert expired, this will be sorted out soon. It's not on github releases yet, because I haven't had the chance to sort it out. When it's released I'll put it on github releases.

The release of this won't package any 3rd party dependencies, and the only purpose of packaging them in the past was for quickly testing the beta on different OSes.

[tresf]

the only purpose of packaging them in the past was for quickly testing the beta on different OSes.

Understood, but like I said before, this isn't uncommon to make a standalone version for users. PDFBOX does this as does hid4java, simplersa. 👍