Hello Scott,
I got the chance to dig in further and it appears the underlying 3rd party library (okhttp-digest) uses "android.util.Log" to log a couple cases such as the one you are running into[1]. The only dependency okhttp-digest lists in it's pom is OkHttp[2] (also true for the latest version[3]). So while OkHttp doesn't assume you're running on Android, okhttp-digest (okhttp's recommended solution for doing Digest Authentication) does. I will open an issue for okhttp-digest and raise a Jira for us to upgrade OkHttp and okhttp-digest versions if/when a fix is implemented. If okhttp-digest chooses not to change logger and OkHttp continues to only use that interceptor we will need to reassess the processor/feature. [1] https://github.com/rburgst/okhttp-digest/blob/d8ea75368ad802aefc92f8b096736a03b953f0e4/src/main/java/com/burgstaller/okhttp/AuthenticationCacheInterceptor.java#L34 [2] https://www.versioneye.com/java/com.burgstaller:okhttp-digest/0.6 [3] https://www.versioneye.com/java/com.burgstaller:okhttp-digest/1.5 Sorry for not catching this in testing and thank you for your patience, Joe - - - - - - Joseph Percivall linkedin.com/in/Percivall e: [email protected] On Wednesday, June 29, 2016 1:51 PM, Scott Stroud <[email protected]> wrote: I manually put in the okhttp-digest-1.5.jar and its required okhttp-3.2.0.jar. But unfortunately I think the package structure changed in the okhttp jar and the InvokeHttp processor code fails then because it refers to an old package structure then too. I could've missed something in my patching process as well since it was very manual. Unfortunately I do not have the time right now to make all the updates to resolve this. But I do think this is a significant bug if InvokeHTTP does not support digest authentication (across batches). org.apache.nifi.processor.Processor: Provider org.apache.nifi.processors.standard.InvokeHTTP could not be instantiated java.util.ServiceConfigurationError: org.apache.nifi.processor.Processor: Provider org.apache.nifi.processors.standard.InvokeHTTP could not be instantiated at java.util.ServiceLoader.fail(ServiceLoader.java:232) ~[na:1.8.0_72] at java.util.ServiceLoader.access$100(ServiceLoader.java:185) ~[na:1.8.0_72] at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384) ~[na:1.8.0_72] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) ~[na:1.8.0_72] at java.util.ServiceLoader$1.next(ServiceLoader.java:480) ~[na:1.8.0_72] at org.apache.nifi.nar.ExtensionManager.loadExtensions(ExtensionManager.java:107) ~[nifi-nar-utils-0.6.1.jar:0.6.1] at org.apache.nifi.nar.ExtensionManager.discoverExtensions(ExtensionManager.java:88) ~[nifi-nar-utils-0.6.1.jar:0.6.1] at org.apache.nifi.NiFi.<init>(NiFi.java:120) ~[nifi-runtime-0.6.1.jar:0.6.1] at org.apache.nifi.NiFi.main(NiFi.java:227) ~[nifi-runtime-0.6.1.jar:0.6.1] Caused by: java.lang.NoClassDefFoundError: com/squareup/okhttp/Authenticator at java.lang.Class.getDeclaredConstructors0(Native Method) ~[na:1.8.0_72] at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) ~[na:1.8.0_72] at java.lang.Class.getConstructor0(Class.java:3075) ~[na:1.8.0_72] at java.lang.Class.newInstance(Class.java:412) ~[na:1.8.0_72] at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) ~[na:1.8.0_72] ... 6 common frames omitted Caused by: java.lang.ClassNotFoundException: com.squareup.okhttp.Authenticator at java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[na:1.8.0_72] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_72] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_72] ... 11 common frames omitted On Tue, Jun 28, 2016 at 2:16 PM, Joe Percivall <[email protected]> wrote: Okhttp has elected to not have built-in support for Digest Auth[1] and instead relies on third-party support offered by the okhttp-digest interceptor[2]. Something in this dependency (com.burgstaller.okhttp.AuthenticationCacheInterceptor from the stacktrace) is causing problems with the logs. > >Without digging in fully I notice that we are on version 0.6 (released in >December 2015) and the current release of okhttp-digest is 1.5 (released last >Month). This issue may be resolved in the latest release. > >Scott are you in a position to try upgrading the version to see if it does fix >the issue? > >[1] https://github.com/square/okhttp/issues/205 >[2] https://github.com/rburgst/okhttp-digest > >Joe > >- - - - - - >Joseph Percivall >linkedin.com/in/Percivall >e: [email protected] > > > > >On Tuesday, June 28, 2016 1:34 PM, Joe Witt <[email protected]> wrote: > > > >scott > >glad you found a path to keep making progress for the moment. > >anyone else in community familiar with okhttp that can help look into >this and raise the appropriate JIRA? > >Thanks >Joe > > >On Tue, Jun 28, 2016 at 10:24 AM, Scott Stroud <[email protected]> wrote: >> I confirmed that its only an issue for digest, so I switched to basic for >> the moment and moved on. >> >> I also noticed I was not having the (digest) issue on the first batch of the >> InvokeHttp and it failed on subsequent batch attempts (and kept retrying & >> failing). >> >> On Tue, Jun 28, 2016 at 1:18 PM, Scott Stroud <[email protected]> wrote: >>> >>> Is this only an issue for digest authentication? >>> >>> On Tue, Jun 28, 2016 at 11:05 AM, Scott Stroud <[email protected]> >>> wrote: >>>> >>>> If your sense is its triggering this based on http headers (or body) >>>> characteristics, I can play with those since its my own service thats being >>>> called. Thanks. >>>> >>>> On Tue, Jun 28, 2016 at 10:43 AM, Joey Frazee <[email protected]> >>>> wrote: >>>>> >>>>> OkHttp which InvokeHTTP is using has some Android support, including >>>>> logging. It's almost as if it's detected the wrong platform. >>>>> >>>>> Not an answer but the Android reference is probably from there. >>>>> >>>>> > On Jun 28, 2016, at 7:37 AM, Joe Witt <[email protected]> wrote: >>>>> > >>>>> > Scott >>>>> > >>>>> > What is throwing me off is the android reference there in the class >>>>> > name. In the logs/nifi-app.log are you seeing the full stack traces >>>>> > that follow those messages. If not we will want to turn those on and >>>>> > see them unless someone has a better idea. >>>>> > >>>>> > Thanks >>>>> > Joe >>>>> > >>>>> >> On Tue, Jun 28, 2016 at 7:27 AM, Scott Stroud <[email protected]> >>>>> >> wrote: >>>>> >> java version "1.8.0_72" >>>>> >> >>>>> >> Java(TM) SE Runtime Environment (build 1.8.0_72-b15) >>>>> >> >>>>> >> Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode) >>>>> >> >>>>> >> >>>>> >>> On Tue, Jun 28, 2016 at 10:27 AM, Joe Witt <[email protected]> >>>>> >>> wrote: >>>>> >>> >>>>> >>> Agreed - it should work out of the box. >>>>> >>> >>>>> >>> When you run 'java -version' can you please share the output. >>>>> >>> >>>>> >>> Thanks >>>>> >>> Joe >>>>> >>> >>>>> >>> On Tue, Jun 28, 2016 at 7:23 AM, Scott Stroud >>>>> >>> <[email protected]> >>>>> >>> wrote: >>>>> >>>> Im attempting to use the InvokeHTTP component with the 0.6.1 >>>>> >>>> release and >>>>> >>>> keep seeing this error. My JAVA_HOME is 1.8.0_72-b15 on my Mac. >>>>> >>>> Im >>>>> >>>> sure I >>>>> >>>> could go find the jar and manually add it to the classpath, but I >>>>> >>>> assume >>>>> >>>> it >>>>> >>>> should work OOB straight from the NiFi download or maybe its some >>>>> >>>> path >>>>> >>>> nuance to my local system. Any insight is appreciated. >>>>> >>>> >>>>> >>>> InvokeHTTP[id=908a3005-b216-4458-aeee-489e6ec7c462] failed to >>>>> >>>> process >>>>> >>>> session due to java.lang.NoClassDefFoundError: android/util/Log: >>>>> >>>> java.lang.NoClassDefFoundError: android/util/Log >>>>> >>>> 09:50:51 EDTWARNING908a3005-b216-4458-aeee-489e6ec7c462 >>>>> >>>> InvokeHTTP[id=908a3005-b216-4458-aeee-489e6ec7c462] Processor >>>>> >>>> Administratively Yielded for 1 sec due to processing failure >>>>> >>>> 09:50:54 EDTWARNING908a3005-b216-4458-aeee-489e6ec7c462 >>>>> >>>> InvokeHTTP[id=908a3005-b216-4458-aeee-489e6ec7c462] Processor >>>>> >>>> Administratively Yielded for 1 sec due to processing failure >>>>> >>>> 09:50:54 EDTERROR908a3005-b216-4458-aeee-489e6ec7c462 >>>>> >>>> InvokeHTTP[id=908a3005-b216-4458-aeee-489e6ec7c462] >>>>> >>>> InvokeHTTP[id=908a3005-b216-4458-aeee-489e6ec7c462] failed to >>>>> >>>> process >>>>> >>>> session due to java.lang.NoClassDefFoundError: android/util/Log: >>>>> >>>> java.lang.NoClassDefFoundError: android/util/Log >>>>> >> >>>>> >> >>>> >>>> >>> >> >
