Henry,
I see this behavior deploying with YARN 2.7.1, HDP 2.3. But I'm not
sure you understood my issue.
* The logback jar dependency is only picked up if it is on the classpath
when the bundle is created.
* With logback in my twill client classpath, the appmaster starts fine.
However without logback in my client classpath the appmaster will get a
ClassNotFoundException.
* We use log4j and with logback in my client classpath, it takes over
the slf4j bindings and I lose control of the client logging.
So my question was about whether this is expected or if there is a
well-known procedure for working around it. It seems there should be a
way to tell the twill system to where to find the appmaster dependencies
without having them in the classpath of the twill client.
Thanks!
-Martin
On 02/08/2017 08:09 PM, Henry Saputra wrote:
But the logback dependency should be included in the jar packaging that
YARN client sends for Twill ApplicationMaster.
Are you seeing this behavior in deploying Twill app in latest YARN?
- Henry
On Wed, Feb 8, 2017 at 12:30 PM, Martin Serrano <mar...@attivio.com> wrote:
Hey Devs,
It seems like the twill project goes through some pain to try to insulate
itself logging frameworks. I see use of the slf4j API. However, the
appmaster code has a dependency on logback via the
org.apache.twill.internal.logging.Loggings class. The appmaster will
not start up without this dependency present. With the dependency code as
it is now, there is no way to include the logback jar in the generated
bundle without it being on the current classpath. I've created a ticket
(TWILL-215) to make a missing dependency trigger an exception at bundle
generation time rather than appmaster execution time.
When the logback jar is on my classpath, my client code picks up logback
instead of our current logger (log4j). Is this what is expected? Is there
any known workaround? It seems like there may be a case for specifying
dependencies of the appmaster that are located outside of the current jvm
classpath.
Thanks,
Martin
