Re: notEmpty

[Joe Witt]

Paul,

I strongly encourage you to consider the Apache Software Foundation's
Code of Conduct as you interact with this community [1].

[1] http://www.apache.org/foundation/policies/conduct.html

Thanks
Joe

On Wed, Mar 23, 2016 at 5:58 PM, Paul Nahay  wrote:
> Wow. Thanks.
>
>
>
> This seems unnecessarily complicated using the “Advanced” feature, given it’s 
> a standard boolean evaluation I’m trying to do. But I’m glad to hear there’s 
> some way to do it.
>
>
>
> You know, assuming NiFi is written in Java (which I presume it is, if the 
> custom processors are as well), when the day comes where you realize your 
> Expression Language is simply too limited and quirky for anyone to stand any 
> longer (that day is HERE for me, now!), I would humbly suggest you guys make 
> use of Java 8 Nashorn. Then you could allow NiFi developers to embed 
> arbitrary JavaScript in your little window, rather than your crazy, 
> exists-no-where-else-on-earth E.L.
>
>
>
> Then one could simply create expressions representing “a and b are not empty 
> or c is not empty” without the complexity of the E.L. itself, or forcing one 
> to use the Advanced dialog, but using JavaScript, which is almost the world’s 
> 2nd most used programming language at this point.
>
>
>
> Paul
>
>
>
> From: Matthew Clarke [mailto:matt.clarke@gmail.com]
> Sent: Wednesday, March 23, 2016 12:26 PM
> To: Paul Nahay
> Cc: dev@nifi.apache.org
> Subject: Re: notEmpty
>
>
>
> Paul,
>
>  The expression you have above (   
> ${allAttributes('x','y'):isEmpty():not():or(${z:isEmpty():not()})})  will 
> not logically result in the same outcome as  (
> ${allAttributes('x','y','z'):isEmpty():not()}).   I understand you 
> realize this, but I just want to clarify it for the rest of the community 
> reading this thread.
>
> Assuming x and/or y are empty and z is not empty, your expression will result 
> in a true.  Your understanding of how this would be parsed is correct.
>
> assume x is blank, y = 1,  and z = 2.   so the expression would evaluate to   
> (attribute x is not empty (false) or attribute z is not empty  (true) )  and 
> (attribute y is not empty (true) or attribute z is not empty (true))  which 
> breaks down further to (false or true = true) and (true or true = true) which 
> finally results in (true and true = true).   So as you can see as long as z 
> is not empty, your expression will resolve to true.
>
>So you are correct that z would get evaluated for every attribute declared 
> in the allAttributes() function.
>
>
>To avoid evaluating z multiple times in this particular use case, you 
> would want to make use of the "Advanced" capability of the updateAttribute 
> processor.  When you open the configuration window for the UpdateAttribute 
> processor, you will notice an "Advanced" button in the lower right corner.  
> This well open the advanced configuration UI for the UpdateAttribute.   Here 
> you can essentially build if/then logic.  In your case you would add two new 
> "rules" and set the "FlowFile policy" to "use original"
>
> rule 1 would check to see if z is not empty.  The condition must evaluate to 
> "true" before the associated actions are applied.  The action could set a new 
> attribute with a value of true
> rule 2 would check to see if AllAttributes(x,y,a,b,c,etc) are not empty.   if 
> evaluated to true, the action would set the "same" attribute used in rule 1 
> to true.
>
> So essentially you are saying if this or if this set this.  If both rules 
> resolve to true and policy is set to use original, the last rule evaluated to 
> true will set the attribute.
>
> The else part of the if/then/else logic here is achieved outside of the 
> "Advanced" UI.  There you could declare the "same" attribute again but set it 
> to a value of false.
>
> The way this works If an attribute is declared both inside and outside 
> the "Advanced" UI, the value set outside the "advanced" UI will only be 
> applied to the FlowFile if it was not set by one of the rules.
>
> This process would result in evaluating z only once for each FlowFile.
>
>
>
> You can then use this newly created attribute later in your dataflow for 
> additional logic checks, routing, etc...
>
> More information on the updateAttribute "Advanced" UI can be found here:
> https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.attributes.UpdateAttribute/additionalDetails.html
>
>
>
> Matt
>
>
>
>
>
> On Wed, Mar 23, 2016 at 10:28 AM, Paul Nahay  wrote:
>
> OK, I am still confused about how to implement this boolean expression with 
> the EL:
>
> (attributes x and y are both not empty) or (attribute z is not empty)
>
> If I do this:
>
> ${allAttributes('x','y'):isEmpty():not():or(${z:isEmpty():not()})}
>
> from my understanding of your documentation about the allAttributes() 
> function, then the EL above is doing this (due to ":or()" coming right after 
> ":not()"):
>
> (attribute x 

RE: notEmpty

[Paul Nahay]

Wow. Thanks.

 

This seems unnecessarily complicated using the “Advanced” feature, given it’s a 
standard boolean evaluation I’m trying to do. But I’m glad to hear there’s some 
way to do it.

 

You know, assuming NiFi is written in Java (which I presume it is, if the 
custom processors are as well), when the day comes where you realize your 
Expression Language is simply too limited and quirky for anyone to stand any 
longer (that day is HERE for me, now!), I would humbly suggest you guys make 
use of Java 8 Nashorn. Then you could allow NiFi developers to embed arbitrary 
JavaScript in your little window, rather than your crazy, 
exists-no-where-else-on-earth E.L. 

 

Then one could simply create expressions representing “a and b are not empty or 
c is not empty” without the complexity of the E.L. itself, or forcing one to 
use the Advanced dialog, but using JavaScript, which is almost the world’s 2nd 
most used programming language at this point.

 

Paul

 

From: Matthew Clarke [mailto:matt.clarke@gmail.com] 
Sent: Wednesday, March 23, 2016 12:26 PM
To: Paul Nahay
Cc: dev@nifi.apache.org
Subject: Re: notEmpty

 

Paul,

 The expression you have above (   
${allAttributes('x','y'):isEmpty():not():or(${z:isEmpty():not()})})  will 
not logically result in the same outcome as  (
${allAttributes('x','y','z'):isEmpty():not()}).   I understand you realize 
this, but I just want to clarify it for the rest of the community reading this 
thread.

Assuming x and/or y are empty and z is not empty, your expression will result 
in a true.  Your understanding of how this would be parsed is correct.

assume x is blank, y = 1,  and z = 2.   so the expression would evaluate to   
(attribute x is not empty (false) or attribute z is not empty  (true) )  and 
(attribute y is not empty (true) or attribute z is not empty (true))  which 
breaks down further to (false or true = true) and (true or true = true) which 
finally results in (true and true = true).   So as you can see as long as z is 
not empty, your expression will resolve to true.  

   So you are correct that z would get evaluated for every attribute declared 
in the allAttributes() function.


   To avoid evaluating z multiple times in this particular use case, you would 
want to make use of the "Advanced" capability of the updateAttribute processor. 
 When you open the configuration window for the UpdateAttribute processor, you 
will notice an "Advanced" button in the lower right corner.  This well open the 
advanced configuration UI for the UpdateAttribute.   Here you can essentially 
build if/then logic.  In your case you would add two new "rules" and set the 
"FlowFile policy" to "use original"

rule 1 would check to see if z is not empty.  The condition must evaluate to 
"true" before the associated actions are applied.  The action could set a new 
attribute with a value of true
rule 2 would check to see if AllAttributes(x,y,a,b,c,etc) are not empty.   if 
evaluated to true, the action would set the "same" attribute used in rule 1 to 
true.

So essentially you are saying if this or if this set this.  If both rules 
resolve to true and policy is set to use original, the last rule evaluated to 
true will set the attribute.

The else part of the if/then/else logic here is achieved outside of the 
"Advanced" UI.  There you could declare the "same" attribute again but set it 
to a value of false.

The way this works If an attribute is declared both inside and outside the 
"Advanced" UI, the value set outside the "advanced" UI will only be applied to 
the FlowFile if it was not set by one of the rules.

This process would result in evaluating z only once for each FlowFile.

 

You can then use this newly created attribute later in your dataflow for 
additional logic checks, routing, etc...

More information on the updateAttribute "Advanced" UI can be found here:
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.attributes.UpdateAttribute/additionalDetails.html

 

Matt   

 

 

On Wed, Mar 23, 2016 at 10:28 AM, Paul Nahay  wrote:

OK, I am still confused about how to implement this boolean expression with the 
EL:

(attributes x and y are both not empty) or (attribute z is not empty)

If I do this:

${allAttributes('x','y'):isEmpty():not():or(${z:isEmpty():not()})}

from my understanding of your documentation about the allAttributes() function, 
then the EL above is doing this (due to ":or()" coming right after ":not()"):

(attribute x is not empty or attribute z is not empty) and (attribute y is not 
empty or attribute z is not empty)

I realize logically this ends up being the same thing in the end, however, the 
"z is not empty" part gets evaluated TWICE, or as many times as there are 
parameters passed to allAttributes() (i.e., if we had instead 
"allAttributes('1','2','3','4','5'), then testing z for non-emptiness occurs 
five times, not once).

Is there any way to actually express 

Apache NiFi 0.6.0 RC2 Release Helper Guide

[Aldrin Piri]

Hello Apache NiFi community,

Please find the associated guidance to help those interested in
validating/verifying the release so they can vote.

# Download latest KEYS file:
  https://dist.apache.org/repos/dist/dev/nifi/KEYS

# Import keys file:
  gpg --import KEYS

# [optional] Clear out local maven artifact repository

# Pull down nifi-0.6.0 source release artifacts for review:

  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.0/nifi-0.6.0-source-release.zip
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.0/nifi-0.6.0-source-release.zip.asc
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.0/nifi-0.6.0-source-release.zip.md5
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.0/nifi-0.6.0-source-release.zip.sha1
  wget
https://dist.apache.org/repos/dist/dev/nifi/nifi-0.6.0/nifi-0.6.0-source-release.zip.sha256

# Verify the signature
  gpg --verify nifi-0.6.0-source-release.zip.asc

# Verify the hashes (md5, sha1, sha256) match the source and what was
provided in the vote email thread
  md5sum nifi-0.6.0-source-release.zip
  sha1sum nifi-0.6.0-source-release.zip
  sha256sum nifi-0.6.0-source-release.zip

# Unzip nifi-0.6.0-source-release.zip

# Verify the build works including release audit tool (RAT) checks
  cd nifi-0.6.0
  mvn clean install -Pcontrib-check

# Verify the contents contain a good README, NOTICE, and LICENSE.

# Verify the git commit ID is correct

# Verify the RC was branched off the correct git commit ID

# Look at the resulting convenience binary as found in nifi-assembly/target

# Make sure the README, NOTICE, and LICENSE are present and correct

# Run the resulting convenience binary and make sure it works as expected

# Send a response to the vote thread indicating a +1, 0, -1 based on your
findings.

Thank you for your time and effort to validate the release!

[VOTE] Release Apache NiFi 0.6.0 (RC2)

[Aldrin Piri]

Hello Apache NiFi Community,

I am pleased to be calling this vote for the source release of Apache NiFi,
nifi-0.6.0.

The source zip, including signatures, digests, etc. can be found at:
https://repository.apache.org/content/repositories/orgapachenifi-1079/

The Git tag is nifi-0.6.0-RC2
The Git commit hash is 0b9bd20d31d7f805300254da768d91b973480151
*
https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=0b9bd20d31d7f805300254da768d91b973480151
*
https://github.com/apache/nifi/commit/0b9bd20d31d7f805300254da768d91b973480151

Checksums of nifi-0.6.0-source-release.zip:
MD5: 42dbc268668b3524eb7a56c403712a7f
SHA1: be747176565ad94ba46fcd15490f99f22dbe17ec
SHA256: 9cb7353199049660bb7905364e4a02def69186b165ebb3b13a786edb1a9d8da8

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/aldrin.asc

KEYS file available here:
https://dist.apache.org/repos/dist/release/nifi/KEYS

77 issues were closed/resolved for this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12334372
Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version0.6.0

The vote will be open for 72 hours.
Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, and test. Then
please vote:

[ ] +1 Release this package as nifi-0.6.0
[ ] +0 no opinion
[ ] -1 Do not release this package because...

Thanks!

Re: Can't add an attribute inside session read call-back

[Russell Bateman]

Hope not to make copy/paste mistakes. I can share the code snippets, but 
unfortunately not a trace. I didn't keep one and my efforts to restore 
the broken code only leave me frustrated. (I've obliterated my NAR 
several times, but the debugger tells me that the lines don't match up 
when I step through, can't set breakpoints, etc. Sorry.)


How I was doing it:

  public void onTrigger( final ProcessSession session, final 
DataExtractor filter, final String regexPattern )

  throws ProcessException
  {
final FlowFile flowfile = session.get();
*final AtomicReference< FlowFile > flowFileHolder = new 
AtomicReference<>();**

**flowFileHolder.set( flowfile );*

session.read( flowfile, new InputStreamCallback()
{
  @Override
  public void process( InputStream in ) throws IOException
  {
RegularExpressionMatch match;

try
{
  // slurp the in-coming stream to match into...
  Matcher matcher = Pattern.compile( regexPattern ).matcher( 
StreamUtilities.slurp( in, -1 ) );

  if( !matcher.find() )
throw new IOException( "Failed to match regular expression 
pattern in the document" );

  match = new RegularExpressionMatch( matcher );
}
catch( Exception e )
{
  throw new IOException( "Failed to create regular expression 
matcher with passed properties" );

}

Tagtag  = filter.buildTag( match );
String xml;
xml = ( Utilities.isEmpty( tag ) )
  ? "(No tag built for this document.)"
  : new TagUtilities( tag, true /*properties.debug*/ 
).getXmlFromTag( 0 );

*   try**
**   {**
** FlowFile flowFileWithAttributes = flowFileHolder.get();**
** flowFileWithAttributes = session.putAttribute( 
flowFileWithAttributes, "concept", xml );**

** flowFileHolder.set( flowFileWithAttributes );**
   }
   catch( Throwable e )
   {
->   e.printStackTrace();  // IllegalStateException
   }
*  }
} );

// the flowfile now has attributes we put on it...
session.transfer( flowFileHolder.get(), new 
ProcessorRelationships().getSuccess() );

  }

How I'm doing it now:

   public void onTrigger( final ProcessSession session, final
   DataExtractor filter, final String regexPattern )
throws ProcessException
   {
  FlowFile flowfile = session.get();
   *  final Stringattribute;*
   *  final AtomicReference< String > attributeHolder = new
   AtomicReference<>();*

  session.read( flowfile, new InputStreamCallback()
  {
@Override
public void process( InputStream in ) throws IOException
{
  RegularExpressionMatch match;

  try
  {
// slurp the in-coming stream to match into...
String incoming = StreamUtilities.slurp( in, -1 );
Matcher matcher = Pattern.compile( regexPattern ).matcher(
   incoming );
if( !matcher.find() )
  throw new IOException( "Failed to match regular
   expression pattern in the document" );
match = new RegularExpressionMatch( matcher );
  }
  catch( Exception e )
  {
throw new IOException( "Failed to create regular expression
   matcher with passed properties" );
  }

  Tagtag  = filter.buildTag( match );
  String xml;
  xml = ( Utilities.isEmpty( tag ) )
? "(No tag built for this document.)"
: new TagUtilities( tag, true /*properties.debug*/
   ).getXmlFromTag( 0 );
   *  attributeHolder.set( xml );*
}
  } );

  /* Can't change anything about the session right inside here:
   don't change flowfiles
   * in the callback! Set the attribute here instead of inside the
   read!
   */
   *  attribute = attributeHolder.get();*
   *  flowfile  = session.putAttribute( flowfile, "concept", attribute );*

  // the flowfile now has attributes we put on it...
  session.transfer( flowfile, new
   ProcessorRelationships().getSuccess() );
   }

On 03/23/2016 03:42 PM, Oleg Zhurakousky wrote:

Russell

This doesn’t sound right. Would you care to share a code snippet on how you set 
the attribute as well as stack trace?

Cheers
Oleg


On Mar 23, 2016, at 5:33 PM, Russell Bateman 
 wrote:

I stumbled upon something peculiar in NiFi. I had been attaching an attribute 
to a flowfile in the session.read() call-back. The NiFi unit testing framework 
tolerated this, but when I finally ran my processor for real, it blew chunks 
(IllegalStateException). I solved the problem by saving the new attribute and 
attaching it instead outside the call-back just before calling 
session.transfer().

The only reason I'm pointing this out is because I somewhat rely on unit 
testing and hope to catch this level of error/gotcha earlier than 
button-pushing 

[GitHub] nifi pull request: NIFI-1537 Added SNMP processors

[olegz]

Github user olegz commented on the pull request:

https://github.com/apache/nifi/pull/257#issuecomment-200559586
  
Pierre

You may want to rebase (merge conflicts) and push again since it's out of 
sink.
Also, aside from unit tests would you mind giving some pointers on how to 
test it outside of unit tests? A link on how to setup an environment or a short 
writeup. I am not that familiar with SNMP


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1636: Print Stacktrace When Unepected OnTr...

[olegz]

Github user olegz commented on the pull request:

https://github.com/apache/nifi/pull/285#issuecomment-200557606
  
Also, you may want to amend the commit message "Unepected"  unless its a 
new English word I haven't learned yet ;)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1636: Print Stacktrace When Unepected OnTr...

[olegz]

Github user olegz commented on the pull request:

https://github.com/apache/nifi/pull/285#issuecomment-200557146
  
Ricky

Could you please take a look at 
https://issues.apache.org/jira/browse/NIFI-1447 and see if it's what you are 
looking for? If I remember correctly we don't really want to log stack traces 
unless we're in DEBUG mode and that is what the above JIRA addresses.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Can't add an attribute inside session read call-back

[Oleg Zhurakousky]

Russell 

This doesn’t sound right. Would you care to share a code snippet on how you set 
the attribute as well as stack trace?

Cheers
Oleg

> On Mar 23, 2016, at 5:33 PM, Russell Bateman 
>  wrote:
> 
> I stumbled upon something peculiar in NiFi. I had been attaching an attribute 
> to a flowfile in the session.read() call-back. The NiFi unit testing 
> framework tolerated this, but when I finally ran my processor for real, it 
> blew chunks (IllegalStateException). I solved the problem by saving the new 
> attribute and attaching it instead outside the call-back just before calling 
> session.transfer().
> 
> The only reason I'm pointing this out is because I somewhat rely on unit 
> testing and hope to catch this level of error/gotcha earlier than 
> button-pushing testing
> 
> --in case anyone cares.
> 
> Open to comments, cat-calls, etc.
> 
> ;-)
> 
> Best regards,
> 
> Russ
> 

Re: To help fulfill NIFI-513...

[Oleg Zhurakousky]

Russell

First, thank you for taking initiative!
Indeed we need to bring that JIRA to a closure. Having said that there is 
actually a link in our Contributor Guide on interactive  debugging  
https://cwiki.apache.org/confluence/display/NIFI/Contributor+Guide#ContributorGuide-RunningNiFiinDebugmode
 which also links to a sample project which describes in details debugging in 
both Eclipse and IntelliJ https://github.com/olegz/nifi-ide-integration/, 
although it may need some TLC. Please go through it and see if you feel 
anything should be added.

Cheers
Oleg

On Mar 23, 2016, at 5:22 PM, Russell Bateman 
>
 wrote:

I needed to break down and debug a processor I'm working on. I found a JIRA 
issue a year old that's probably not been taken care of. I'd like to help.

https://issues.apache.org/jira/browse/NIFI-513

I wrote this quickie on how to set up IntelliJ or Eclipse to accomplish that. 
I'm using IntelliJ, but I'm a very old Eclipse guy and still active in the 
Eclipse forums. It's actually easier than I make it look here because I'm 
covering Eclipse as well as IntelliJ and I'm trying not to assume the person 
who follows will know too much about doing this or might never have done remote 
debugging before.

Hope this helps someone. Maybe someone in charge of the NiFi user doc could use 
this to resolve the JIRA issue.




Steps to debugging a NiFi processor you've written. See this article 
*
 to learn how remote debugging works in IntelliJ. The example uses IntelliJ to 
debug an application running in Tomcat, but it's a similar thing no matter if 
you're using Eclipse (or IntelliJ) to debug NiFi.

1. Edit /conf/bootstrap.conf/ and simply uncomment the line that starts
  out with java.arg.debug.
2. Create a Debug configuration.

  In IntelliJ IDEA, ...
   1. Do Run → Edit Configurations
   2. Click the green +.
   3. Choose Remote (because it's a remote debugging session you want
  to create.
   4. Give a Name:, something like "Local NiFi".
   5. Change the port to 8000 (this value must match the one in
  /conf/bootstrap.conf/).
   6. If you're only debugging a processor in a project with multiple
  modules, set the drop-down Search sources using module's
  classpath: to the module in which it lives.
  In Eclipse, do
   1. Do Run → Debug Configurations
   2. Choose Remote Java Application.
   3. Click on the New Launch Configuration icon (a tiny sheet of
  paper with a yellow plus sign in upper left of dialog).
   4. Give it a name like "Local NiFi".
   5. In Project:, type the name (or browse for it) of the project
  containing your processor code.
   6. Set the Port: to 8000 or whatever you established in
  /conf/bootstrap.conf/.
   7. Click Apply or, if you're ready, Debug.

3. Launch NiFi (or bounce it).
4. Set one or more breakpoints in your processor code.
5. Launch the debugger.

  In IntelliJ IDEA, do Run → Debug and choose "Local NiFi" (or
  whatever you called it) from the list presented. This brings up the
  debugger and displays, "Connected to the target VM, address
  'localhost:8000', transport: 'socket'
  In Eclipse, do Run → Debug Configurations..., scroll down and choose
  "Local NiFi" or whatever you called it. What you see should give you
  warm fuzzies, something akin to what I'm reporting seeing in
  IntelliJ IDEA.

6. Prepare data flows into your processor.
7. Start your processor; the IDE debugger should pop up stopped at the
  first breakpoint.
8. Debug away.

* 
http://blog.trifork.com/2014/07/14/how-to-remotely-debug-application-running-on-tomcat-from-within-intellij-idea/

Re: Errors in your Documentation

[Rob Moran]

Regarding the "undo" feature, just wanted to mention there is a ticket [1].
On a related note, there was also talk of confirmation dialogs as perhaps
an alternate way of catching unintended actions [2].

[1] https://issues.apache.org/jira/browse/NIFI-833
[2] https://issues.apache.org/jira/browse/NIFI-1089

Rob

On Wed, Mar 23, 2016 at 1:13 PM, Andy LoPresto 
wrote:

> Paul,
>
> Please create Jira tickets with your feature requests. I have not
> previously encountered users making this request, so I want to ensure we
> capture all of your desires for a successful implementation of this feature
> in order to accurately estimate the resources necessary for it and
> prioritize it accordingly.
>
> Please consider how you would like NiFi to indicate the current mode,
> whether this “operational” mode would allow any changes to processor
> properties and addition of new processors or simply fixes the location of
> canvas elements, the mechanism to switch between modes conveniently, if
> this would affect the UI only or the REST API as well, etc.
>
> To the best of my knowledge, we have not had any requests for a feature
> like this, nor do many/most of our users envision the environment in this
> split mode mentality. Users who should not be able to modify the flow
> usually are assigned the ROLE_MONITOR role, and those who need to
> manipulate the flow itself have not mentioned the issues you brought up.
>
>
> Andy LoPresto
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Mar 23, 2016, at 4:28 AM, Paul Nahay  wrote:
>
> Thanks. I wouldn't be able to send you any screen shots, as the system
> with NiFi is not the same as this which I can send email on.
>
> Yes, I'm asking about a feature whereby a single user can switch back and
> forth between these two modes. When I first encountered NiFi, THIS was the
> most glaring omission, in my view. The use case occurs every day by many
> people: we inadvertently move something, and since you have no "undo" (the
> 2nd most glaring omission), the canvas is screwed up. THIS HAPPENS ALL THE
> TIME. It seems an obviously need thing to me. Basically one is interacting
> with the canvas in one of two situations: "operationally", in which case
> one DOES NOT WANT ANYTHING TO MOVE, not matter how one clicks around the
> canvas, and "editing-ally", in which we DO want to move things around.
>
> Computers routinely are programmed to help us, including help us NOT do
> things we do NOT want done, including inadvertent things. Why can't NiFi
> help us with this? Why can't we say "hey, NiFi, I'm going to use you
> operationally, I'm not modifying anything", and have NiFi NOT allow things
> to be moved around?
>
> I know your answer: "So don't move things around". But given that I have
> to use the mouse when I'm using it operationally, including clicking to
> drag the entire canvas around so I can see things, it is not hard to
> understand that if I click slight off of where I intend, I can
> inadvertently move things that I do not intend to move. Again, THIS HAPPENS
> ALL THE TIME, and not just by me.
>
> PLEASE, add an "EDIT MODE/OPERATION MODE" toggle, and although I know it
> would be very difficult to do, add some for of canvas "undo", at LEAST "one
> level", letting you restore something you just deleted!
>
> Paul
>
> -Original Message-
> From: Andy LoPresto
> Sent: Mar 22, 2016 8:03 PM
> To: Paul Nahay
> Cc: dev@nifi.apache.org
> Subject: Re: Errors in your Documentation
>
> Thanks Paul.
>
> Bugs and feature requests can be submitted here [1] which will ensure they
> are seen by the entire team/community. The most helpful reports include
> screenshots when applicable, current system description, and potential use
> cases or unit tests to verify issue resolution.
>
> Very quickly, you can accomplish a “non-edit mode” by assigning
> “ROLE_MONITOR” to a user in the authorized-users.xml configuration file,
> but currently a feature whereby a single user can switch back and forth
> between those two modes instantaneously does not exist. Can you describe
> the use case where you see this being valuable? Are you having trouble and
> accidentally modifying items on the canvas?
>
> [1]
> https://issues.apache.org/jira/browse/NIFI/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
>
> Andy LoPresto
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Mar 22, 2016, at 4:55 PM, Paul Nahay  wrote:
>
> Great.
>
> I can tell you a list of things I think need to be improved in NiFi. The
> most important is having two “modes” that one is always in, an “edit mode”,
> which is basically what you have 100% of the time now, and a “non-edit
> mode”, where the user cannot move things (inadvertently) around on the
> canvas.
>
> Oh, and you desperately need an “undo”.
>
> Paul
>
> *From:* Andy LoPresto 

Re: Errors in your Documentation

[Andy LoPresto]

Paul,

Please create Jira tickets with your feature requests. I have not previously 
encountered users making this request, so I want to ensure we capture all of 
your desires for a successful implementation of this feature in order to 
accurately estimate the resources necessary for it and prioritize it 
accordingly.

Please consider how you would like NiFi to indicate the current mode, whether 
this “operational” mode would allow any changes to processor properties and 
addition of new processors or simply fixes the location of canvas elements, the 
mechanism to switch between modes conveniently, if this would affect the UI 
only or the REST API as well, etc.

To the best of my knowledge, we have not had any requests for a feature like 
this, nor do many/most of our users envision the environment in this split mode 
mentality. Users who should not be able to modify the flow usually are assigned 
the ROLE_MONITOR role, and those who need to manipulate the flow itself have 
not mentioned the issues you brought up.


Andy LoPresto
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Mar 23, 2016, at 4:28 AM, Paul Nahay  wrote:
> 
> Thanks. I wouldn't be able to send you any screen shots, as the system with 
> NiFi is not the same as this which I can send email on.
> 
> Yes, I'm asking about a feature whereby a single user can switch back and 
> forth between these two modes. When I first encountered NiFi, THIS was the 
> most glaring omission, in my view. The use case occurs every day by many 
> people: we inadvertently move something, and since you have no "undo" (the 
> 2nd most glaring omission), the canvas is screwed up. THIS HAPPENS ALL THE 
> TIME. It seems an obviously need thing to me. Basically one is interacting 
> with the canvas in one of two situations: "operationally", in which case one 
> DOES NOT WANT ANYTHING TO MOVE, not matter how one clicks around the canvas, 
> and "editing-ally", in which we DO want to move things around.
> 
> Computers routinely are programmed to help us, including help us NOT do 
> things we do NOT want done, including inadvertent things. Why can't NiFi help 
> us with this? Why can't we say "hey, NiFi, I'm going to use you 
> operationally, I'm not modifying anything", and have NiFi NOT allow things to 
> be moved around?
> 
> I know your answer: "So don't move things around". But given that I have to 
> use the mouse when I'm using it operationally, including clicking to drag the 
> entire canvas around so I can see things, it is not hard to understand that 
> if I click slight off of where I intend, I can inadvertently move things that 
> I do not intend to move. Again, THIS HAPPENS ALL THE TIME, and not just by me.
> 
> PLEASE, add an "EDIT MODE/OPERATION MODE" toggle, and although I know it 
> would be very difficult to do, add some for of canvas "undo", at LEAST "one 
> level", letting you restore something you just deleted!
> 
> Paul
> -Original Message-
> From: Andy LoPresto
> Sent: Mar 22, 2016 8:03 PM
> To: Paul Nahay
> Cc: dev@nifi.apache.org
> Subject: Re: Errors in your Documentation
> 
> Thanks Paul.
> 
> Bugs and feature requests can be submitted here [1] which will ensure they 
> are seen by the entire team/community. The most helpful reports include 
> screenshots when applicable, current system description, and potential use 
> cases or unit tests to verify issue resolution.
> 
> Very quickly, you can accomplish a “non-edit mode” by assigning 
> “ROLE_MONITOR” to a user in the authorized-users.xml configuration file, but 
> currently a feature whereby a single user can switch back and forth between 
> those two modes instantaneously does not exist. Can you describe the use case 
> where you see this being valuable? Are you having trouble and accidentally 
> modifying items on the canvas?
> 
> [1] 
> https://issues.apache.org/jira/browse/NIFI/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
>  
> 
> 
> Andy LoPresto
> alopresto.apa...@gmail.com 
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> 
>> On Mar 22, 2016, at 4:55 PM, Paul Nahay > > wrote:
>> 
>> Great.
>> 
>> I can tell you a list of things I think need to be improved in NiFi. The 
>> most important is having two “modes” that one is always in, an “edit mode”, 
>> which is basically what you have 100% of the time now, and a “non-edit 
>> mode”, where the user cannot move things (inadvertently) around on the 
>> canvas.
>> 
>> Oh, and you desperately need an “undo”.
>> 
>> Paul
>> 
>> From: Andy LoPresto [mailto:alopresto.apa...@gmail.com 
>> ]
>> Sent: Tuesday, March 22, 2016 7:51 PM
>> To: dev@nifi.apache.org ; Paul Nahay

Re: Your Distro

[dan bress]

Paul,
   Have you tried joining the mailing list using the instructions here:
https://nifi.apache.org/mailing_lists.html

I know in the past, we have had issues with people who aren't
subscribed being unable to send to the list.  This seems weird to me as
well, but since you are bringing up some concerns and making suggestions it
might be best to join the list so that they can be heard and addressed.

Dan

On Wed, Mar 23, 2016 at 9:41 AM Matthew Clarke 
wrote:

> -- Forwarded message --
> From: Paul Nahay 
> Date: Wed, Mar 23, 2016 at 10:31 AM
> Subject: Your Distro
> To: Matthew Clarke 
>
>
> This is the 2nd time I've gotten an email I sent to
> dev@nifi.apache.org
> returned to me:
>
>
>
> Hi. This is the qmail-send program at apache.org.
> I'm afraid I wasn't able to deliver your message to the following
> addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
>
> :
> ezmlm-reject: fatal: Sorry, I don't accept messages of MIME
> Content-Type 'text/html' (#5.2.3)
>

Fwd: Your Distro

[Matthew Clarke]

-- Forwarded message --
From: Paul Nahay 
Date: Wed, Mar 23, 2016 at 10:31 AM
Subject: Your Distro
To: Matthew Clarke 


This is the 2nd time I've gotten an email I sent to
dev@nifi.apache.org
returned to me:



Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
ezmlm-reject: fatal: Sorry, I don't accept messages of MIME
Content-Type 'text/html' (#5.2.3)

Fwd: More Documentation Shortcomings

[Matthew Clarke]

-- Forwarded message --
From: Paul Nahay 
Date: Wed, Mar 23, 2016 at 10:51 AM
Subject: More Documentation Shortcomings
To: Matthew Clarke 
Cc: dev@nifi.apache.org, Paul Nahay 


>https://nifi.apache.org/docs.html#

This page lists special characters for attribute names, such that attribute
names containing those characters need to be quoted.

That list of special characters OMITS the period.

However, I find I get an error if I do the following:

allAttributes(x.x,y.y)

Meaning, I have to quote these:

allAttributes('x.x','y.y')

even though your list of special characters does NOT include the period.

But this appears inconsistent, because in the same larger expression I can
write

${z.z:isEmpty():not()

and yet I do NOT get an error for my NOT putting quotes around "z.z".

SO:

1) Your documentation appears incorrect, as your special character list
seems like it SHOULD include the period, yet
2) Your EL evaluator appears to be inconsistent, requiring attributes
containing a period to be quoted, yet allowing it to be NOT quoted in
another situation.

Here is my complete expression (which I asked you about in previous email;
the "or" bothers me, since logically it is being tested at the "wrong
place" in the expression):

${allAttributes('a.a','b.b'):isEmpty():not():or(${c.c:isEmpty():not()})}

So I'm saying that your EL interpreter forces me to put quotes around "a.a"
and "b.b", but NOT around "c.c".

Very annoying, and makes me in general not trust what the Expression
Language is doing.

Please forward to your dev@nifi.apache.org team, because in addition to
everything wrong I outline above, I get my messages to
dev@nifi.apache.org returned to me.

--Paul Nahay

[GitHub] nifi pull request: NIFI-1563: Federate requests and merge response...

[markap14]

Github user markap14 closed the pull request at:

https://github.com/apache/nifi/pull/294


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: notEmpty

[Matthew Clarke]

Paul,
 The expression you have above (
*${allAttributes('x','y'):isEmpty():not():or(${z:**isEmpty():not()})} *   )
 will not logically result in the same outcome as  (  *
 ${allAttributes('x','y','z'):isEmpty():not(**)}*).   I understand you
realize this, but I just want to clarify it for the rest of the community
reading this thread.

Assuming x and/or y are empty and z is not empty, your expression will
result in a true.  Your understanding of how this would be parsed is
correct.

assume x is blank, y = 1,  and z = 2.   so the expression would evaluate to
  (attribute x is not empty (*false*) or attribute z is not empty  (*true*)
)  and (attribute y is not empty (*true*) or attribute z is not empty (
*true*))  which breaks down further to (false or true = *true*) and (true
or true = *true*) which finally results in (true and true = *true*).   So
as you can see as long as z is not empty, your expression will resolve to
true.

   So you are correct that z would get evaluated for every attribute
declared in the allAttributes() function.

   To avoid evaluating z multiple times in this particular use case, you
would want to make use of the "Advanced" capability of the updateAttribute
processor.  When you open the configuration window for the UpdateAttribute
processor, you will notice an "Advanced" button in the lower right corner.
This well open the advanced configuration UI for the UpdateAttribute.
Here you can essentially build if/then logic.  In your case you would add
two new "rules" and set the "FlowFile policy" to "use original"

rule 1 would check to see *if* z is not empty.  The condition must evaluate
to "true" before the associated actions are applied.  The action could set
a new attribute with a value of true
rule 2 would check to see *if* AllAttributes(x,y,a,b,c,etc) are not empty.
  if evaluated to true, the action would set the "same" attribute used in
rule 1 to true.

So essentially you are saying if this or if this set this.  If both rules
resolve to true and policy is set to use original, the last rule evaluated
to true will set the attribute.

The else part of the if/then/else logic here is achieved outside of the
"Advanced" UI.  There you could declare the "same" attribute again but set
it to a value of false.

The way this works If an attribute is declared both inside and outside
the "Advanced" UI, the value set outside the "advanced" UI will only be
applied to the FlowFile if it was *not* set by one of the rules.

This process would result in evaluating z only once for each FlowFile.

You can then use this newly created attribute later in your dataflow for
additional logic checks, routing, etc...

More information on the updateAttribute "Advanced" UI can be found here:
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.attributes.UpdateAttribute/additionalDetails.html

Matt


On Wed, Mar 23, 2016 at 10:28 AM, Paul Nahay  wrote:

> OK, I am still confused about how to implement this boolean expression
> with the EL:
>
> (attributes x and y are both not empty) or (attribute z is not empty)
>
> If I do this:
>
> ${allAttributes('x','y'):isEmpty():not():or(${z:isEmpty():not()})}
>
> from my understanding of your documentation about the allAttributes()
> function, then the EL above is doing this (due to ":or()" coming right
> after ":not()"):
>
> (attribute x is not empty or attribute z is not empty) and (attribute y is
> not empty or attribute z is not empty)
>
> I realize logically this ends up being the same thing in the end, however,
> the "z is not empty" part gets evaluated TWICE, or as many times as there
> are parameters passed to allAttributes() (i.e., if we had instead
> "allAttributes('1','2','3','4','5'), then testing z for non-emptiness
> occurs five times, not once).
>
> Is there any way to actually express in the NiFi EL my boolean at the top
> of my message above?
>
>
> Paul
>
>
>
> -Original Message-
> From: Matthew Clarke
> Sent: Mar 22, 2016 8:17 PM
> To: Paul Nahay
> Subject: Re: notEmpty
>
> Paul,
>  While i do agree that the addition of a notEmpty function would be
> nice, I was simply offering an alternative solution to your particular
> problem.  The solution I provided does indeed work. I built a test flow to
> verify it.
>
> I created some test files with the following attributes on them:
>
> Property:Value:
> attr1
> attr2
> attr3
> attr41
> attr52
> attr63
>
> Those files were sent to a routeOnAttribute processor where I used that
> expression language statement to find route where all attributes were not
> empty.
>
> RouteOnAttribute:
>
> Property: Value:
> AllAttributesNotEmpty
>  ${allAttributes('attr1','attr2','attr3'):isEmpty():not()} <--- I
> changed what attributes to look at in each test.
>
>
> I then varied what attribute I was looking at using the AllAttributes
> function.
> First I looked at 

Re: Closing in on the Apache NiFi 0.6.0 release

[Aldrin Piri]

All,

It looks like the items that arose from testing have been resolved and
merged into master leaving just the release for this version.  I will begin
the release process for RC2 based off of git
commit e4b7e47836edf47042973e604005058c28eed23b [1] [2]

[1]
https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=e4b7e47836edf47042973e604005058c28eed23b
[2]
https://github.com/apache/nifi/commit/e4b7e47836edf47042973e604005058c28eed23b

Thanks!



On Tue, Mar 22, 2016 at 2:11 PM, Aldrin Piri  wrote:

> Bryan, Matt,
>
> Both of these seem pretty straightforward and would be nice to capture as
> well while the Kafka tickets are resolved.
>
> Thanks for the notice!
>
> Current status has us looking at the following before I create RC2:
>
> NIFI-1664
> NIFI-1645
> NIFI-1665
> NIFI-1420
> NIFI-1666
>
> On Tue, Mar 22, 2016 at 1:57 PM, Matt Burgess  wrote:
>
>> All,
>>
>> We found an issue with the PutElasticsearch processor as well, it doesn't
>> evaluate EL expressions using the flow file attributes for the Index and
>> Document Type properties. This is a simple fix, I've written it up as
>> NIFI-1666 [1] and will have a PR very shortly. I'd like to get this into
>> 0.6.0 as well.
>>
>> Thanks,
>> Matt
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-1666
>>
>> On Tue, Mar 22, 2016 at 1:18 PM, Bryan Bende  wrote:
>>
>> > All,
>> >
>> > While testing the original RC I came across a couple of issues with the
>> new
>> > GetSplunk processor.
>> >
>> > The first issue relates to being able to specify the timezone through a
>> > processor property, so that the timezone used for searching will match
>> with
>> > splunk's timezone.
>> > The second is is that GetSplunk incorrectly clears it's state when NiFi
>> > starts up causing to pull data it has already pulled.
>> >
>> > I'd like to re-open NIFI-1420 and submit fixes for these problems
>> before we
>> > make the next RC. I should be able to do this shortly.
>> >
>> > Thanks,
>> >
>> > Bryan
>> >
>> > On Tue, Mar 22, 2016 at 11:50 AM, Aldrin Piri 
>> > wrote:
>> >
>> > > Joe,
>> > >
>> > > Looking through the associated tickets, both sound like worthwhile
>> > > additions and can hold off until those items get through reviews.
>> > >
>> > > --Aldrin
>> > >
>> > > On Tue, Mar 22, 2016 at 11:47 AM, Joe Witt 
>> wrote:
>> > >
>> > > > Aldrin,
>> > > >
>> > > > NIFI-1665 appears to correct a problematic behavior when pulling
>> from
>> > > > Kafka and when timeouts can occur.  Definitely think we should get
>> > > > this in the build.  I also see that NIFI-1645 is up and given the
>> > > > trouble that is causing for use of delimiter function we should
>> engage
>> > > > on this.
>> > > >
>> > > > Since you're working the windows build issue and these are in play
>> do
>> > > > you mind waiting a bit before sending the new RC ?
>> > > >
>> > > > Thanks
>> > > > Joe
>> > > >
>> > > > On Mon, Mar 21, 2016 at 1:42 PM, Aldrin Piri 
>> > > wrote:
>> > > > > All,
>> > > > >
>> > > > > It looks like the last ticket for 0.6.0 has been merged and
>> resolved.
>> > > > >
>> > > > > I will begin the RC process shortly working off of commit
>> > > > > 736896246cf021dbed31d4eb1e22e0755e4705f0 [1] [2].
>> > > > >
>> > > > > [1]
>> > > > >
>> > > >
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=736896246cf021dbed31d4eb1e22e0755e4705f0
>> > > > > [2]
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/nifi/commit/736896246cf021dbed31d4eb1e22e0755e4705f0
>> > > > >
>> > > > > On Mon, Mar 21, 2016 at 1:48 AM, Tony Kurc 
>> wrote:
>> > > > >
>> > > > >> The Locale issue was reviewed, confirmed as fixed by reporter and
>> > > merged
>> > > > >> in.
>> > > > >>
>> > > > >> On Sun, Mar 20, 2016 at 10:35 PM, Joe Witt 
>> > > wrote:
>> > > > >>
>> > > > >> > Team,
>> > > > >> >
>> > > > >> > There are a couple finishing touches PRs to fix a big defect in
>> > > > >> > SplitText for certain input types, improve locale handling and
>> > test
>> > > > >> > behavior for Kit bundle, and to clean up content viewing from
>> > > > >> > connections.
>> > > > >> >
>> > > > >> > Getting good input on findings folks have so please keep it
>> coming
>> > > as
>> > > > >> > that helps ensure a solid/healthy RC.
>> > > > >> >
>> > > > >> > Thanks
>> > > > >> > Joe
>> > > > >> >
>> > > > >> > On Sat, Mar 19, 2016 at 6:21 PM, Tony Kurc 
>> > > wrote:
>> > > > >> > > Recommend https://issues.apache.org/jira/browse/NIFI-1651 be
>> > > > included
>> > > > >> in
>> > > > >> > > 0.6.0
>> > > > >> > >
>> > > > >> > > On Wed, Mar 16, 2016 at 4:08 PM, Joe Witt <
>> joe.w...@gmail.com>
>> > > > wrote:
>> > > > >> > >
>> > > > >> > >> Team,
>> > > > >> > >>
>> > > > >> > >> Ok sooo close.  We have 5 tickets remaining.
>> > > > >> > >>
>> > > > >> > >> - Additional functionality/cleanup for 

[GitHub] nifi pull request: NIFI-1676: Do not allow Processor to be started...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi/pull/300


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1676: Do not allow Processor to be started...

[apiri]

Github user apiri commented on the pull request:

https://github.com/apache/nifi/pull/300#issuecomment-200414177
  
Okay, code looks good and I have played with this a bit confirming the 
anticipated behavior for those processes that linger when stopping.  +1 from me 
and can merge into master.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1676: Do not allow Processor to be started...

[apiri]

Github user apiri commented on a diff in the pull request:

https://github.com/apache/nifi/pull/300#discussion_r57181772
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/StandardProcessorNode.java
 ---
@@ -1117,8 +1117,9 @@ public void verifyCanStart() {
 
 @Override
 public void verifyCanStart(final Set 
ignoredReferences) {
-if (this.getScheduledState() == ScheduledState.RUNNING) {
-throw new IllegalStateException(this + " cannot be started 
because it is already running");
+final ScheduledState currentState = getPhysicalScheduledState();
+if (currentState != ScheduledState.STOPPED && currentState != 
ScheduledState.DISABLED) {
--- End diff --

This should be an || (or), correct?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Error at startup

[Pierre Villard]

Thanks Matt,

Logs in Maven build are all OK (SUCCESS for each module at the end). I did
a new full build and I got a similar error (not exactly the same but
related to compilation). I tried once again and this is now OK. This is
really strange that Maven is not complaining about compilation issues...
Next time I'll try to keep Maven build logs in case it appears again to
have a deeper look...

Pierre





2016-03-22 19:05 GMT+01:00 Matt Gilman :

> Pierre,
>
> The error message is really strange. It appears that a number of classes
> did not compile correctly. Was there any unexpected output during the maven
> build? I just verified the build locally on OSX and Windows 10. In Windows
> 10 I copied the zip, extracted, and executed run-nifi.bat without
> additionally configuration.
>
> Matt
>
> On Tue, Mar 22, 2016 at 10:47 AM, Pierre Villard <
> pierre.villard...@gmail.com> wrote:
>
> > I did a full build with Maven, took the generated zip
> > (nifi-0.6.0-SNAPSHOT-bin.zip), unzipped it, and executed the
> run-nifi.bat.
> > So it is a clean instance. As you said, the local-provider is correctly
> > set:
> >
> > 
> > local-provider
> >
> >
> >
> org.apache.nifi.controller.state.providers.local.WriteAheadLocalStateProvider
> > ./state/local
> > 
> >
> >
> > 2016-03-22 15:38 GMT+01:00 Matt Gilman :
> >
> > > Pierre,
> > >
> > > Are you attempting to upgrade an existing instance? If so, what version
> > are
> > > you coming from? I'm wondering if there is some configuration missing
> > after
> > > the upgrade. Are you able to start up the built assembly using default
> > > configuration?
> > >
> > > In your /conf/state-management.xml can you verify the
> > > configuration of the local-provider? By default, it's configured to
> > > use
> > >
> >
> org.apache.nifi.controller.state.providers.local.WriteAheadLocalStateProvider
> > > with a Directory property that points to ./state/local.
> > >
> > > I think the error in the logs is having trouble with that property.
> > >
> > > Matt
> > >
> > >
> > > On Tue, Mar 22, 2016 at 10:16 AM, Pierre Villard <
> > > pierre.villard...@gmail.com> wrote:
> > >
> > > > OK. Logs are here:
> > > >
> https://raw.githubusercontent.com/pvillard31/share/master/nifi-app.log
> > > >
> > > > 2016-03-22 15:12 GMT+01:00 Matt Burgess :
> > > >
> > > > > I can't see them, perhaps the attachment is being removed. Can you
> > > paste
> > > > > the text from the logs into the email?
> > > > >
> > > > > Thanks,
> > > > > Matt
> > > > >
> > > > > On Tue, Mar 22, 2016 at 10:10 AM, Pierre Villard <
> > > > > pierre.villard...@gmail.com> wrote:
> > > > >
> > > > > > Erf that's strange, I do see logs from my side.
> > > > > > Is it better?
> > > > > >
> > > > > > 2016-03-22 15:06 GMT+01:00 Oleg Zhurakousky <
> > > > > ozhurakou...@hortonworks.com>
> > > > > > :
> > > > > >
> > > > > >> Pierre, no logs ;)
> > > > > >>
> > > > > >> > On Mar 22, 2016, at 10:03 AM, Pierre Villard <
> > > > > >> pierre.villard...@gmail.com> wrote:
> > > > > >> >
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > I updated my local checkout to current master and did a
> > successful
> > > > > >> maven build. When trying to start generated binaries, I have a
> > bunch
> > > > of
> > > > > >> errors and NIFI does not start. See attached logs.
> > > > > >> >
> > > > > >> > Does someone experience the same issue?
> > > > > >> >
> > > > > >> > Thanks,
> > > > > >> > Pierre
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>