You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Russell Bateman <ru...@perfectsearchcorp.com> on 2016/11/09 22:19:57 UTC
MockProcessorLog in NiFi 1.0.0...
I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't
figured out a way around this in my JUnit testing:
ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
(simulated)", SectionScoringIdentifierPropertiesTest.class );
MockProcessorLog causes a NoClassDefException, of course. What's the
appropriate translation?
Thanks,
Russ
Re: MockProcessorLog in NiFi 1.0.0...
Posted by Russell Bateman <ru...@perfectsearchcorp.com>.
"You should be able to simply change any reference to ProcessorLog to
ComponentLog, and it should still work in both 0.x and 1.x."
Thanks, Mark and Bryan, this fact is very reassuring and will make my
life much easier once I stop doing wrong in my code.
I'm creating some properties in JUnit tests. The methods that create
these properties are on other occasions and for other reasons called
from onTrigger()and their first argument is the logger in effect. When
performed from a JUnit test case, which test case tests aspects of the
properties themselves (for proper creation, etc.) and not the processor
itself, I have no way to get the logger than to use the constructor of a
mocked one, unless, that is, you can alert me to a statement that will
replace (as already noted) the MockProcessorLog()constructor. Is there
one? Or must I pass null?
The reason the logger is used when composing these (dynamic) properties
is to post warnings to the log of anomalies during creation that will
give our Implementation team hints on what's gone wrong when they use
the processors.
I guess I could amend the code creating the properties not to use the
passed-in logger when null. I would gently ask why MockProcessorLog()is
surfaced to my level if it's not available for my use?
Russ
On 11/10/2016 09:17 AM, Mark Payne wrote:
> Russell,
>
> In 0.x, we had the ProcessorLog class, but it really was an "empty implementation"
> that extended ComponentLog. ProcessorLog is deprecated in the 0.x branch. You should
> be able to simply change any reference to ProcessorLog to ComponentLog, and it should
> still work in both 0.x and 1.x.
>
> I don't believe you should be referencing MockProcessorLog or MockComponentLog directly.
> Rather, you should reference the ComponentLog interface. Once this is done, the code should
> work in both 0.x and 1.x.
>
> In general, unless you are referencing a deprecated class in 0.x, I don't believe you should
> have to make any code changes to move to 1.x.
>
> Thanks
> -Mark
>
>
>> On Nov 10, 2016, at 9:03 AM, Bryan Bende <bb...@gmail.com> wrote:
>>
>> Just to clarify... in 0.x there was "MockProcessorLog implements
>> ProcessorLog" which was refactored to "MockComponentLog implements
>> ComponentLog" during the 1.0 release as part of NIFI-1811.
>>
>> Also, in AbstractSessionFactoryProcessor in 0.x there was "ProcessorLog
>> getLogger()" which for 1.0 was refactored to "ComponentLog getLogger()" as
>> part of NIFI-1811.
>>
>> So I'm not sure that there would be a way to move to these changes without
>> building against 1.x.
>>
>> On Wed, Nov 9, 2016 at 5:51 PM, Russell Bateman <
>> russell.bateman@perfectsearchcorp.com> wrote:
>>
>>> Bryan,
>>>
>>> Yes, today sees my first attempt at replacing 0.7.1 with 1.0.0 (in
>>> /pom.xml/) and at fixing all the errors. I think I am saying that
>>>
>>> ComponentLog logger = getLogger();
>>>
>>> is resulting in errors, though I'm human and it could be my fault somehow.
>>>
>>> I had tried MockComponentLogback under 0.7.1, which doesn't exist there.
>>> We're standing on a code base we hope to move toward 1.x, but were also
>>> hoping, as is the case for ComponentLog, which did exist and we started
>>> migrating to it leaving ProcessorLogbehind, to retain source-code backward
>>> compatibility. In other words, build our source with 0.7.1 which is what
>>> we're running in production while with 1.x in forward (everyday)
>>> development. If we can't do this, it will mean that our move forward will
>>> be a rather more quantum (all or nothing) leap and we'll have to adjust
>>> accordingly.
>>>
>>> Thanks,
>>>
>>> Russ
>>>
>>>
>>> On 11/09/2016 03:37 PM, Bryan Bende wrote:
>>>
>>>> Hi Russell,
>>>>
>>>> As far as testing, I believe MockProcessorLog has been replaced with
>>>> MockComponentLog.
>>>>
>>>> For the second case, are you saying getLogger() is producing
>>>> NoSuchMethodErrors?
>>>>
>>>> Many processors do something like this:
>>>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/
>>>> nifi-standard-bundle/nifi-standard-processors/src/main/
>>>> java/org/apache/nifi/processors/standard/PutFile.java#L188
>>>>
>>>> -Bryan
>>>>
>>>> On Wed, Nov 9, 2016 at 5:28 PM, Russell Bateman <
>>>> russell.bateman@perfectsearchcorp.com> wrote:
>>>>
>>>> Also, I'm still having trouble with:
>>>>> public class LabIdentifier extends BaseIdentifierProcessor
>>>>> {
>>>>> // @formatter:off
>>>>> private LabIdentifierPropertiesMedical liProperties = new
>>>>> LabIdentifierPropertiesMedical();
>>>>> * private ComponentLog log = getLogger();*
>>>>>
>>>>> causing NoSuchMethodErrors. I'm not finding clear examples out there of
>>>>> people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> -------- Forwarded Message --------
>>>>> Subject: MockProcessorLog in NiFi 1.0.0...
>>>>> Date: Wed, 9 Nov 2016 15:19:57 -0700
>>>>> From: Russell Bateman <ru...@perfectsearchcorp.com>
>>>>> To: dev@nifi.apache.org
>>>>>
>>>>>
>>>>>
>>>>> I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't
>>>>> figured
>>>>> out a way around this in my JUnit testing:
>>>>>
>>>>> ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
>>>>> (simulated)", SectionScoringIdentifierPropertiesTest.class );
>>>>>
>>>>>
>>>>> MockProcessorLog causes a NoClassDefException, of course. What's the
>>>>> appropriate translation?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Russ
>>>>>
>>>>>
>>>>>
>>>>>
Re: MockProcessorLog in NiFi 1.0.0...
Posted by Mark Payne <ma...@hotmail.com>.
Russell,
In 0.x, we had the ProcessorLog class, but it really was an "empty implementation"
that extended ComponentLog. ProcessorLog is deprecated in the 0.x branch. You should
be able to simply change any reference to ProcessorLog to ComponentLog, and it should
still work in both 0.x and 1.x.
I don't believe you should be referencing MockProcessorLog or MockComponentLog directly.
Rather, you should reference the ComponentLog interface. Once this is done, the code should
work in both 0.x and 1.x.
In general, unless you are referencing a deprecated class in 0.x, I don't believe you should
have to make any code changes to move to 1.x.
Thanks
-Mark
> On Nov 10, 2016, at 9:03 AM, Bryan Bende <bb...@gmail.com> wrote:
>
> Just to clarify... in 0.x there was "MockProcessorLog implements
> ProcessorLog" which was refactored to "MockComponentLog implements
> ComponentLog" during the 1.0 release as part of NIFI-1811.
>
> Also, in AbstractSessionFactoryProcessor in 0.x there was "ProcessorLog
> getLogger()" which for 1.0 was refactored to "ComponentLog getLogger()" as
> part of NIFI-1811.
>
> So I'm not sure that there would be a way to move to these changes without
> building against 1.x.
>
> On Wed, Nov 9, 2016 at 5:51 PM, Russell Bateman <
> russell.bateman@perfectsearchcorp.com> wrote:
>
>> Bryan,
>>
>> Yes, today sees my first attempt at replacing 0.7.1 with 1.0.0 (in
>> /pom.xml/) and at fixing all the errors. I think I am saying that
>>
>> ComponentLog logger = getLogger();
>>
>> is resulting in errors, though I'm human and it could be my fault somehow.
>>
>> I had tried MockComponentLogback under 0.7.1, which doesn't exist there.
>> We're standing on a code base we hope to move toward 1.x, but were also
>> hoping, as is the case for ComponentLog, which did exist and we started
>> migrating to it leaving ProcessorLogbehind, to retain source-code backward
>> compatibility. In other words, build our source with 0.7.1 which is what
>> we're running in production while with 1.x in forward (everyday)
>> development. If we can't do this, it will mean that our move forward will
>> be a rather more quantum (all or nothing) leap and we'll have to adjust
>> accordingly.
>>
>> Thanks,
>>
>> Russ
>>
>>
>> On 11/09/2016 03:37 PM, Bryan Bende wrote:
>>
>>> Hi Russell,
>>>
>>> As far as testing, I believe MockProcessorLog has been replaced with
>>> MockComponentLog.
>>>
>>> For the second case, are you saying getLogger() is producing
>>> NoSuchMethodErrors?
>>>
>>> Many processors do something like this:
>>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/
>>> nifi-standard-bundle/nifi-standard-processors/src/main/
>>> java/org/apache/nifi/processors/standard/PutFile.java#L188
>>>
>>> -Bryan
>>>
>>> On Wed, Nov 9, 2016 at 5:28 PM, Russell Bateman <
>>> russell.bateman@perfectsearchcorp.com> wrote:
>>>
>>> Also, I'm still having trouble with:
>>>>
>>>> public class LabIdentifier extends BaseIdentifierProcessor
>>>> {
>>>> // @formatter:off
>>>> private LabIdentifierPropertiesMedical liProperties = new
>>>> LabIdentifierPropertiesMedical();
>>>> * private ComponentLog log = getLogger();*
>>>>
>>>> causing NoSuchMethodErrors. I'm not finding clear examples out there of
>>>> people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: MockProcessorLog in NiFi 1.0.0...
>>>> Date: Wed, 9 Nov 2016 15:19:57 -0700
>>>> From: Russell Bateman <ru...@perfectsearchcorp.com>
>>>> To: dev@nifi.apache.org
>>>>
>>>>
>>>>
>>>> I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't
>>>> figured
>>>> out a way around this in my JUnit testing:
>>>>
>>>> ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
>>>> (simulated)", SectionScoringIdentifierPropertiesTest.class );
>>>>
>>>>
>>>> MockProcessorLog causes a NoClassDefException, of course. What's the
>>>> appropriate translation?
>>>>
>>>> Thanks,
>>>>
>>>> Russ
>>>>
>>>>
>>>>
>>>>
>>
Re: MockProcessorLog in NiFi 1.0.0...
Posted by Bryan Bende <bb...@gmail.com>.
Just to clarify... in 0.x there was "MockProcessorLog implements
ProcessorLog" which was refactored to "MockComponentLog implements
ComponentLog" during the 1.0 release as part of NIFI-1811.
Also, in AbstractSessionFactoryProcessor in 0.x there was "ProcessorLog
getLogger()" which for 1.0 was refactored to "ComponentLog getLogger()" as
part of NIFI-1811.
So I'm not sure that there would be a way to move to these changes without
building against 1.x.
On Wed, Nov 9, 2016 at 5:51 PM, Russell Bateman <
russell.bateman@perfectsearchcorp.com> wrote:
> Bryan,
>
> Yes, today sees my first attempt at replacing 0.7.1 with 1.0.0 (in
> /pom.xml/) and at fixing all the errors. I think I am saying that
>
> ComponentLog logger = getLogger();
>
> is resulting in errors, though I'm human and it could be my fault somehow.
>
> I had tried MockComponentLogback under 0.7.1, which doesn't exist there.
> We're standing on a code base we hope to move toward 1.x, but were also
> hoping, as is the case for ComponentLog, which did exist and we started
> migrating to it leaving ProcessorLogbehind, to retain source-code backward
> compatibility. In other words, build our source with 0.7.1 which is what
> we're running in production while with 1.x in forward (everyday)
> development. If we can't do this, it will mean that our move forward will
> be a rather more quantum (all or nothing) leap and we'll have to adjust
> accordingly.
>
> Thanks,
>
> Russ
>
>
> On 11/09/2016 03:37 PM, Bryan Bende wrote:
>
>> Hi Russell,
>>
>> As far as testing, I believe MockProcessorLog has been replaced with
>> MockComponentLog.
>>
>> For the second case, are you saying getLogger() is producing
>> NoSuchMethodErrors?
>>
>> Many processors do something like this:
>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/
>> nifi-standard-bundle/nifi-standard-processors/src/main/
>> java/org/apache/nifi/processors/standard/PutFile.java#L188
>>
>> -Bryan
>>
>> On Wed, Nov 9, 2016 at 5:28 PM, Russell Bateman <
>> russell.bateman@perfectsearchcorp.com> wrote:
>>
>> Also, I'm still having trouble with:
>>>
>>> public class LabIdentifier extends BaseIdentifierProcessor
>>> {
>>> // @formatter:off
>>> private LabIdentifierPropertiesMedical liProperties = new
>>> LabIdentifierPropertiesMedical();
>>> * private ComponentLog log = getLogger();*
>>>
>>> causing NoSuchMethodErrors. I'm not finding clear examples out there of
>>> people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby.
>>>
>>> Thanks.
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: MockProcessorLog in NiFi 1.0.0...
>>> Date: Wed, 9 Nov 2016 15:19:57 -0700
>>> From: Russell Bateman <ru...@perfectsearchcorp.com>
>>> To: dev@nifi.apache.org
>>>
>>>
>>>
>>> I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't
>>> figured
>>> out a way around this in my JUnit testing:
>>>
>>> ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
>>> (simulated)", SectionScoringIdentifierPropertiesTest.class );
>>>
>>>
>>> MockProcessorLog causes a NoClassDefException, of course. What's the
>>> appropriate translation?
>>>
>>> Thanks,
>>>
>>> Russ
>>>
>>>
>>>
>>>
>
Re: MockProcessorLog in NiFi 1.0.0...
Posted by Russell Bateman <ru...@perfectsearchcorp.com>.
Bryan,
Yes, today sees my first attempt at replacing 0.7.1 with 1.0.0 (in
/pom.xml/) and at fixing all the errors. I think I am saying that
ComponentLog logger = getLogger();
is resulting in errors, though I'm human and it could be my fault somehow.
I had tried MockComponentLogback under 0.7.1, which doesn't exist there.
We're standing on a code base we hope to move toward 1.x, but were also
hoping, as is the case for ComponentLog, which did exist and we started
migrating to it leaving ProcessorLogbehind, to retain source-code
backward compatibility. In other words, build our source with 0.7.1
which is what we're running in production while with 1.x in forward
(everyday) development. If we can't do this, it will mean that our move
forward will be a rather more quantum (all or nothing) leap and we'll
have to adjust accordingly.
Thanks,
Russ
On 11/09/2016 03:37 PM, Bryan Bende wrote:
> Hi Russell,
>
> As far as testing, I believe MockProcessorLog has been replaced with
> MockComponentLog.
>
> For the second case, are you saying getLogger() is producing
> NoSuchMethodErrors?
>
> Many processors do something like this:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutFile.java#L188
>
> -Bryan
>
> On Wed, Nov 9, 2016 at 5:28 PM, Russell Bateman <
> russell.bateman@perfectsearchcorp.com> wrote:
>
>> Also, I'm still having trouble with:
>>
>> public class LabIdentifier extends BaseIdentifierProcessor
>> {
>> // @formatter:off
>> private LabIdentifierPropertiesMedical liProperties = new
>> LabIdentifierPropertiesMedical();
>> * private ComponentLog log = getLogger();*
>>
>> causing NoSuchMethodErrors. I'm not finding clear examples out there of
>> people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby.
>>
>> Thanks.
>>
>>
>> -------- Forwarded Message --------
>> Subject: MockProcessorLog in NiFi 1.0.0...
>> Date: Wed, 9 Nov 2016 15:19:57 -0700
>> From: Russell Bateman <ru...@perfectsearchcorp.com>
>> To: dev@nifi.apache.org
>>
>>
>>
>> I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't figured
>> out a way around this in my JUnit testing:
>>
>> ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
>> (simulated)", SectionScoringIdentifierPropertiesTest.class );
>>
>>
>> MockProcessorLog causes a NoClassDefException, of course. What's the
>> appropriate translation?
>>
>> Thanks,
>>
>> Russ
>>
>>
>>
Re: MockProcessorLog in NiFi 1.0.0...
Posted by Bryan Bende <bb...@gmail.com>.
Hi Russell,
As far as testing, I believe MockProcessorLog has been replaced with
MockComponentLog.
For the second case, are you saying getLogger() is producing
NoSuchMethodErrors?
Many processors do something like this:
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/PutFile.java#L188
-Bryan
On Wed, Nov 9, 2016 at 5:28 PM, Russell Bateman <
russell.bateman@perfectsearchcorp.com> wrote:
> Also, I'm still having trouble with:
>
> public class LabIdentifier extends BaseIdentifierProcessor
> {
> // @formatter:off
> private LabIdentifierPropertiesMedical liProperties = new
> LabIdentifierPropertiesMedical();
> * private ComponentLog log = getLogger();*
>
> causing NoSuchMethodErrors. I'm not finding clear examples out there of
> people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby.
>
> Thanks.
>
>
> -------- Forwarded Message --------
> Subject: MockProcessorLog in NiFi 1.0.0...
> Date: Wed, 9 Nov 2016 15:19:57 -0700
> From: Russell Bateman <ru...@perfectsearchcorp.com>
> To: dev@nifi.apache.org
>
>
>
> I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't figured
> out a way around this in my JUnit testing:
>
> ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
> (simulated)", SectionScoringIdentifierPropertiesTest.class );
>
>
> MockProcessorLog causes a NoClassDefException, of course. What's the
> appropriate translation?
>
> Thanks,
>
> Russ
>
>
>
Fwd: MockProcessorLog in NiFi 1.0.0...
Posted by Russell Bateman <ru...@perfectsearchcorp.com>.
Also, I'm still having trouble with:
public class LabIdentifier extends BaseIdentifierProcessor
{
// @formatter:off
private LabIdentifierPropertiesMedical liProperties = new
LabIdentifierPropertiesMedical();
* private ComponentLog log = getLogger();*
causing NoSuchMethodErrors. I'm not finding clear examples out there of
people using ComponentLog in 1.0.0 or my pre-1.0.0 practices were shabby.
Thanks.
-------- Forwarded Message --------
Subject: MockProcessorLog in NiFi 1.0.0...
Date: Wed, 9 Nov 2016 15:19:57 -0700
From: Russell Bateman <ru...@perfectsearchcorp.com>
To: dev@nifi.apache.org
I'm porting our 0.7.1 base forward to begin using 1.0.0. I haven't
figured out a way around this in my JUnit testing:
ComponentLog log = new MockProcessorLog( "SectionScoringIdentifier
(simulated)", SectionScoringIdentifierPropertiesTest.class );
MockProcessorLog causes a NoClassDefException, of course. What's the
appropriate translation?
Thanks,
Russ