[jira] [Commented] (NIFI-2991) JSON.org license is now CatX

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649836#comment-15649836
 ] 

Joseph Witt commented on NIFI-2991:
---

Well, this is not good.  I have analyzed all documented references to the 
json.org license or anything from the json.org site both in our codebase and in 
our resulting convenience binary.  There are some perfectly fine references but 
the following things are an issue and require follow-on action.  I will spawn 
JIRAs for a number of these items for the 0.x line and might do the same for 
the 1.x line for the specifically scoped items treating this as the 1.x parent 
issue.

* nifi-assembly
** any such references will need to be updated as the following deps are changed
* nifi-aws-nar
** not a problem on 1.x line as we're using 1.11.x aws sdk and their NOTICE now 
removes this entry
*** "JSON parsing and utility functions from JSON.org - Copyright 2002 
JSON.org."
** ACTION: For 1.x we just need to update the nifi-aws-nar notice and 
nifi-assembly notice to remove that reference
** is a problem on the 0.x line as we use 1.10.32 aws sdk and it has a source 
dependency on the cat-x code.  We have to switch to AWS 1.11 line.
** ACTION: File a JIRA for 0.x line to move to 1.11.x aws sdk to resolve the 
cat-x json.org dependency
* nifi-social-media-nar
** The offending item is in the twitter4j library which is a binary dependency 
for us.
** The Twitter4J source uses some of the now category X json.org source code 
and their NOTICE does reference it as well.
** I do not believe we can have this dependency then as-is since twitter4J is 
effectively a combination of ASLv2 + CatX.
** ACTION: For 1.x we have to solve this somehow as we have a binary dependency 
on Twitter4J which has a source dependency on this CatX item.
** ACTION: For 0.x file a JIRA to address this similar to what we do for 1.x.  
* nifi-flume-nar
** same problem as the nifi-social-media-nar.
** ACTION: For 1.x remove 'flume-twitter-source' from nifi-flume-processor 
dependency and document that it is no longer supported due to licensing issue.
** ACTION: File a JIRA on 0.x to do the same as we did for 1.x
* nifi-hive-nar
** 
./nar/extensions/nifi-hive-nar-1.1.0-SNAPSHOT.nar-unpacked/META-INF/bundled-dependencies/json-20090211.jar
** nifi-hive-processors depends on hive-jdbc which depends on hive-common which 
depends on json library.
** ACTION: For 1.x this must be solved somehow and the dependency needs to be 
reflected in the LICENSE/NOTICE
** ACTION: For 0.x if we have the hive processors a new JIRA must be filed and 
same resolution provided.
* nifi-standard-nar
** 
./nar/extensions/nifi-standard-nar-1.1.0-SNAPSHOT.nar-unpacked/META-INF/bundled-dependencies/json-20160810.jar
** nifi-standard-processors depends on org.everit.json which depends on the now 
cat-x JSON library.  Further, this/these deps don't appear to be reflected in 
the nifi-standard-nar
** ACTION: For 1.x this must be solved somehow...
** ACTION: For 0.x a new JIRA must be filed to tackle this in the same manner 
it is solved in 1.x

> JSON.org license is now CatX
> 
>
> Key: NIFI-2991
> URL: https://issues.apache.org/jira/browse/NIFI-2991
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Sean Busbey
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.1.0
>
>
> per [update resolved legal|http://www.apache.org/legal/resolved.html#json]:
> {quote}
> CAN APACHE PRODUCTS INCLUDE WORKS LICENSED UNDER THE JSON LICENSE?
> No. As of 2016-11-03 this has been moved to the 'Category X' license list. 
> Prior to this, use of the JSON Java library was allowed. See Debian's page 
> for a list of alternatives.
> {quote}
> I don't know how many of our versions include stuff under this license, it's 
> definitely currently in master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2971) bcprov and commons-lang usage in application classloader

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649776#comment-15649776
 ] 

ASF GitHub Bot commented on NIFI-2971:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1172
  
@olegz i'll take care of merging because I'll need to squash and rebase 
beforehand.  Will do once +1 received.


> bcprov and commons-lang usage in application classloader
> 
>
> Key: NIFI-2971
> URL: https://issues.apache.org/jira/browse/NIFI-2971
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Tools and Build
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.1.0
>
>
> In reviewing NIFI-2954 it was noticed that the work in NIFI-1831 led to 
> bcprov and commons-lang3 entering the root application classloader which 
> pollutes all classloaders.  The only things that should be in the root 
> classloader are logging libraries, the nifi api, and a way to bootstrap the 
> application.
> These dependencies need to get moved into the nar and executed via the nifi 
> startup routine



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1172: NIFI-2971 moved properties loading into its own bootstrap ...

[joewitt]

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/1172
  
@olegz i'll take care of merging because I'll need to squash and rebase 
beforehand.  Will do once +1 received.


---
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.
---

[jira] [Commented] (NIFI-2971) bcprov and commons-lang usage in application classloader

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649763#comment-15649763
 ] 

ASF GitHub Bot commented on NIFI-2971:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1172
  
Cool, will look and merge in the AM


> bcprov and commons-lang usage in application classloader
> 
>
> Key: NIFI-2971
> URL: https://issues.apache.org/jira/browse/NIFI-2971
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Tools and Build
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.1.0
>
>
> In reviewing NIFI-2954 it was noticed that the work in NIFI-1831 led to 
> bcprov and commons-lang3 entering the root application classloader which 
> pollutes all classloaders.  The only things that should be in the root 
> classloader are logging libraries, the nifi api, and a way to bootstrap the 
> application.
> These dependencies need to get moved into the nar and executed via the nifi 
> startup routine



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1172: NIFI-2971 moved properties loading into its own bootstrap ...

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1172
  
Cool, will look and merge in the AM


---
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.
---

[jira] [Created] (NIFI-3008) Enable EL on BASE_DIRECTORY and FILENAME properties

[Jeff Storck (JIRA)]

Jeff Storck created NIFI-3008:
-

 Summary: Enable EL on BASE_DIRECTORY and FILENAME properties
 Key: NIFI-3008
 URL: https://issues.apache.org/jira/browse/NIFI-3008
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Extensions
Affects Versions: 1.0.0
Reporter: Jeff Storck
Assignee: Jeff Storck


Enable Expression Language on the BASE_DIR and FILENAME properties to allow 
usage of values in the Variable Registry.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2971) bcprov and commons-lang usage in application classloader

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649619#comment-15649619
 ] 

Joseph Witt commented on NIFI-2971:
---

[~ozhurakousky] just pushed a new commit which ensures failures to create 
bootstrap loader will cause termination with explanation of cause.  Fixed RPM 
generation to ensure all matching deps in lib and lib/bootstrap .  I think it 
is good to go now

> bcprov and commons-lang usage in application classloader
> 
>
> Key: NIFI-2971
> URL: https://issues.apache.org/jira/browse/NIFI-2971
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Tools and Build
>Affects Versions: 1.0.0
>Reporter: Joseph Witt
>Assignee: Joseph Witt
>Priority: Blocker
> Fix For: 1.1.0
>
>
> In reviewing NIFI-2954 it was noticed that the work in NIFI-1831 led to 
> bcprov and commons-lang3 entering the root application classloader which 
> pollutes all classloaders.  The only things that should be in the root 
> classloader are logging libraries, the nifi api, and a way to bootstrap the 
> application.
> These dependencies need to get moved into the nar and executed via the nifi 
> startup routine



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2923) Add expression language support to Kerberos parameters used by processors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649616#comment-15649616
 ] 

ASF GitHub Bot commented on NIFI-2923:
--

Github user mauriziocolleluori commented on the issue:

https://github.com/apache/nifi/pull/1148
  
I have recompiled and added expression language support (with expected 
evaluation on read) for both principal and keytab. However when I add any 
expression language to one of such attributes (in a Hive or HDFS processor on a 
kerberized Nifi instance) a tooltip says that the attribute has not been set. 
It looks like some UI validation is still not recognising the expression 
language as valid. How do I overcome this problem? Thank you.


> Add expression language support to Kerberos parameters used by processors
> -
>
> Key: NIFI-2923
> URL: https://issues.apache.org/jira/browse/NIFI-2923
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Maurizio Colleluori
>Priority: Minor
>
> Kerberos properties (e.g. principal, keytab) available as attributes in 
> certain processors (e.g. HDFS processors) only accept a constant value. 
> Support for expression language could be enabled and allow for 
> parameterisation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1148: NIFI-2923 Add expression language support to Kerberos para...

[mauriziocolleluori]

Github user mauriziocolleluori commented on the issue:

https://github.com/apache/nifi/pull/1148
  
I have recompiled and added expression language support (with expected 
evaluation on read) for both principal and keytab. However when I add any 
expression language to one of such attributes (in a Hive or HDFS processor on a 
kerberized Nifi instance) a tooltip says that the attribute has not been set. 
It looks like some UI validation is still not recognising the expression 
language as valid. How do I overcome this problem? Thank you.


---
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.
---

[jira] [Created] (NIFI-3007) Failed to import a template with a processor with no relationships

[Richard St. John (JIRA)]

Richard St. John created NIFI-3007:
--

 Summary: Failed to import a template with a processor with no 
relationships 
 Key: NIFI-3007
 URL: https://issues.apache.org/jira/browse/NIFI-3007
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.0
 Environment: OSX
Reporter: Richard St. John


I have a custom processor, AutoTerminator, that does not contain any 
relationships.  When exporting a template with this processor, the resultant 
XML does not contain a  tag.  Furthermore, when this template 
is reimported, it fails with the following error: "Unable to import the 
specified template: null"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1458) Add scriptable ReportingTask

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649294#comment-15649294
 ] 

ASF GitHub Bot commented on NIFI-1458:
--

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1045
  
I think most everything was hashed out sufficiently. If you make the 
changes you indicated above, I'll run locally, verify `contrib-check`, and 
test, and provide the +1. 


> Add scriptable ReportingTask
> 
>
> Key: NIFI-1458
> URL: https://issues.apache.org/jira/browse/NIFI-1458
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Matt Burgess
>Assignee: Matt Burgess
> Fix For: 1.1.0
>
>
> Now that NIFI-210 adds scriptable Processors (and scripted onTrigger bodies), 
> a great extension would be to add a scriptable ReportingTask. This would 
> enable users to script their own ReportingTasks using the various supported 
> scripting languages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1045: NIFI-1458: Added ScriptedReportingTask

[alopresto]

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1045
  
I think most everything was hashed out sufficiently. If you make the 
changes you indicated above, I'll run locally, verify `contrib-check`, and 
test, and provide the +1. 


---
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 #1045: NIFI-1458: Added ScriptedReportingTask

[alopresto]

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

https://github.com/apache/nifi/pull/1045#discussion_r87113621
  
--- Diff: 
nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/reporting/script/ScriptedReportingTask.java
 ---
@@ -0,0 +1,197 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.reporting.script;
+
+import com.yammer.metrics.core.VirtualMachineMetrics;
+import org.apache.commons.io.IOUtils;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.components.ValidationResult;
+import org.apache.nifi.controller.ConfigurationContext;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.processors.script.ScriptEngineConfigurator;
+import org.apache.nifi.processors.script.ScriptUtils;
+import org.apache.nifi.reporting.AbstractReportingTask;
+import org.apache.nifi.reporting.ReportingContext;
+import org.apache.nifi.util.StringUtils;
+
+import javax.script.Bindings;
+import javax.script.ScriptContext;
+import javax.script.ScriptEngine;
+import javax.script.ScriptException;
+import javax.script.SimpleBindings;
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.nio.charset.Charset;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.List;
+import java.util.Map;
+
+/**
+ * A Reporting task whose body is provided by a script (via supported 
JSR-223 script engines)
+ */
+@Tags({"reporting", "script", "execute", "groovy", "python", "jython", 
"jruby", "ruby", "javascript", "js", "lua", "luaj"})
+@CapabilityDescription("Provides reporting and status information to a 
script. ReportingContext, ComponentLog, and VirtualMachineMetrics objects are 
made available "
++ "as variables (context, log, and vmMetrics, respectively) to the 
script for further processing. The context makes various information available 
such "
++ "as events, provenance, bulletins, controller services, process 
groups, Java Virtual Machine metrics, etc.")
+public class ScriptedReportingTask extends AbstractReportingTask {
+
+protected volatile ScriptUtils scriptUtils = new ScriptUtils();
+protected volatile String scriptToRun = null;
+protected volatile VirtualMachineMetrics vmMetrics;
+
+/**
+ * Returns a list of property descriptors supported by this processor. 
The list always includes properties such as
+ * script engine name, script file name, script body name, script 
arguments, and an external module path. If the
+ * scripted processor also defines supported properties, those are 
added to the list as well.
+ *
+ * @return a List of PropertyDescriptor objects supported by this 
processor
+ */
+@Override
+protected List getSupportedPropertyDescriptors() {
+synchronized (scriptUtils.isInitialized) {
+if (!scriptUtils.isInitialized.get()) {
+scriptUtils.createResources();
+}
+}
+
+return Collections.unmodifiableList(scriptUtils.descriptors);
+}
+
+/**
+ * Returns a PropertyDescriptor for the given name. This is for the 
user to be able to define their own properties
+ * which will be available as variables in the script
+ *
+ * @param propertyDescriptorName used to lookup if any property 
descriptors exist for that name
+ * @return a PropertyDescriptor object corresponding to the specified 
dynamic property name
+ */
+@Override
+

[jira] [Created] (NIFI-3006) Allow dynamic PropertyDescriptors to auto-populate name/displayName

[Andy LoPresto (JIRA)]

Andy LoPresto created NIFI-3006:
---

 Summary: Allow dynamic PropertyDescriptors to auto-populate 
name/displayName
 Key: NIFI-3006
 URL: https://issues.apache.org/jira/browse/NIFI-3006
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core Framework
Affects Versions: 1.0.0
Reporter: Andy LoPresto
Priority: Minor


As discussed during a review of [PR 
1045|https://github.com/apache/nifi/pull/1045#discussion_r83525123], it would 
be useful to allow dynamic {{PropertyDescriptor}} s to automatically populate 
either the {{.name}} or {{.displayName}} field from the user-provided value. 
This would likely involve writing utility methods for either {{humanize()}} 
and/or {{symbolize()}}. 

---
>From the PR comment:

Obviously the name is provided by the user at runtime, but should we still try 
to define a {{displayName}} for the {{PropertyDescriptor}}? I could see three 
possibilities:

* {{name}} and {{displayName}} are identical -- not much value
* {{name}} is as provided, {{displayName}} is the parameter passed through a 
{{humanize()}}-type method (see below)
* {{displayName}} is as provided, {{name}} is the parameter passed through a 
{{symbolize()}}-type method (see below)

The transform methods {{humanize()}}/{{symbolize()}} could be as simple as 
title-casing and adding/removing spaces at word boundary guesses. 

I'm not sure how much energy this is worth investing, as these property names 
are not constants which will be retained across instances of the processor, but 
I think they still would lose the state persisted in the {{flow.xml.gz}} if it 
was somehow modified. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1458) Add scriptable ReportingTask

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649292#comment-15649292
 ] 

ASF GitHub Bot commented on NIFI-1458:
--

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

https://github.com/apache/nifi/pull/1045#discussion_r87113621
  
--- Diff: 
nifi-nar-bundles/nifi-scripting-bundle/nifi-scripting-processors/src/main/java/org/apache/nifi/reporting/script/ScriptedReportingTask.java
 ---
@@ -0,0 +1,197 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.reporting.script;
+
+import com.yammer.metrics.core.VirtualMachineMetrics;
+import org.apache.commons.io.IOUtils;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.components.ValidationResult;
+import org.apache.nifi.controller.ConfigurationContext;
+import org.apache.nifi.logging.ComponentLog;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.processors.script.ScriptEngineConfigurator;
+import org.apache.nifi.processors.script.ScriptUtils;
+import org.apache.nifi.reporting.AbstractReportingTask;
+import org.apache.nifi.reporting.ReportingContext;
+import org.apache.nifi.util.StringUtils;
+
+import javax.script.Bindings;
+import javax.script.ScriptContext;
+import javax.script.ScriptEngine;
+import javax.script.ScriptException;
+import javax.script.SimpleBindings;
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.nio.charset.Charset;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.List;
+import java.util.Map;
+
+/**
+ * A Reporting task whose body is provided by a script (via supported 
JSR-223 script engines)
+ */
+@Tags({"reporting", "script", "execute", "groovy", "python", "jython", 
"jruby", "ruby", "javascript", "js", "lua", "luaj"})
+@CapabilityDescription("Provides reporting and status information to a 
script. ReportingContext, ComponentLog, and VirtualMachineMetrics objects are 
made available "
++ "as variables (context, log, and vmMetrics, respectively) to the 
script for further processing. The context makes various information available 
such "
++ "as events, provenance, bulletins, controller services, process 
groups, Java Virtual Machine metrics, etc.")
+public class ScriptedReportingTask extends AbstractReportingTask {
+
+protected volatile ScriptUtils scriptUtils = new ScriptUtils();
+protected volatile String scriptToRun = null;
+protected volatile VirtualMachineMetrics vmMetrics;
+
+/**
+ * Returns a list of property descriptors supported by this processor. 
The list always includes properties such as
+ * script engine name, script file name, script body name, script 
arguments, and an external module path. If the
+ * scripted processor also defines supported properties, those are 
added to the list as well.
+ *
+ * @return a List of PropertyDescriptor objects supported by this 
processor
+ */
+@Override
+protected List getSupportedPropertyDescriptors() {
+synchronized (scriptUtils.isInitialized) {
+if (!scriptUtils.isInitialized.get()) {
+scriptUtils.createResources();
+}
+}
+
+return Collections.unmodifiableList(scriptUtils.descriptors);
+}
+
+/**
+ * Returns a PropertyDescriptor for the given name. This is for the 
user to be able to define their own properties
+ * which will be available as variables in the script
+ *
+ * 

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649009#comment-15649009
 ] 

ASF GitHub Bot commented on NIFI-401:
-

Github user asfgit closed the pull request at:

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


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649010#comment-15649010
 ] 

ASF GitHub Bot commented on NIFI-401:
-

Github user asfgit closed the pull request at:

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


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649011#comment-15649011
 ] 

ASF GitHub Bot commented on NIFI-401:
-

Github user asfgit closed the pull request at:

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


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649007#comment-15649007
 ] 

ASF subversion and git services commented on NIFI-401:
--

Commit 7eca2037bd602ecd2b26281d91ac3af9bc72a3f5 in nifi's branch 
refs/heads/master from Brian Eugley
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=7eca203 ]

NIFI-401

Signed-off-by: jpercivall 


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-401:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #512: NIFI-401

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1117: NIFI-401

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1185: NIFI-401: Decouple Scheduling Strategy from Executi...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648927#comment-15648927
 ] 

ASF GitHub Bot commented on NIFI-401:
-

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1185
  
+1

Visually verified code and did a contrib check build. In standealone and 
clustered tested all the different scheduling strategies and Execution options, 
all worked as expected. Thanks @mcgilman and @beugley for finally knocking this 
out. I will merge it in.


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1185: NIFI-401: Decouple Scheduling Strategy from Execution Node

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1185
  
+1

Visually verified code and did a contrib check build. In standealone and 
clustered tested all the different scheduling strategies and Execution options, 
all worked as expected. Thanks @mcgilman and @beugley for finally knocking this 
out. I will merge it in.


---
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.
---

[jira] [Created] (NIFI-3005) Add versioning to NIFI docs

[Haimo Liu (JIRA)]

Haimo Liu created NIFI-3005:
---

 Summary: Add versioning to NIFI docs
 Key: NIFI-3005
 URL: https://issues.apache.org/jira/browse/NIFI-3005
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Documentation & Website
Affects Versions: 0.7.1, 1.0.0
Reporter: Haimo Liu


Given that we now have 0.x baseline and 1.x baseline, we should consider adding 
versioning to NIFi docs, allowing users to easily browse different doc versions 
according to their needs. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648838#comment-15648838
 ] 

ASF GitHub Bot commented on NIFI-401:
-

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1185
  
@JPercivall PR is updated. Thanks again!


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1185: NIFI-401: Decouple Scheduling Strategy from Execution Node

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1185
  
@JPercivall PR is updated. Thanks again!


---
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.
---

[jira] [Created] (NIFI-3004) Improve StandardSSLContextService customValidate

[Michael Moser (JIRA)]

Michael Moser created NIFI-3004:
---

 Summary: Improve StandardSSLContextService customValidate
 Key: NIFI-3004
 URL: https://issues.apache.org/jira/browse/NIFI-3004
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.0.0
Reporter: Michael Moser
Priority: Minor


The StandardSSLContextService customValidate() method can be called many times 
in one validation cycle, so it must be efficient.  Currently, it calls 
validateStore() on keystore and truststore, which opens each file and verifies 
it can be read and the password is correct.  If that works then it calls 
verifySslConfig() which creates 3 sample SSLContext objects.

Improve this by remembering when customValidate() has been successful and 
avoiding doing another full validation either for a very small amount of time 
or until one of the Property values changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #952: Nifi 2673: Add MERGE support on processor ConvertJSONTOSQL

[brosander]

Github user brosander commented on the issue:

https://github.com/apache/nifi/pull/952
  
If the standard syntax works for MS SQL Server, we could even make that the 
default implementation on the interface itself.  That way any ANSI-compliant 
database types would "just work".


---
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.
---

[jira] [Updated] (NIFI-3002) Remove legacy code for retrieving Site To Site details

[Matt Gilman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Gilman updated NIFI-3002:
--
Status: Patch Available  (was: In Progress)

> Remove legacy code for retrieving Site To Site details
> --
>
> Key: NIFI-3002
> URL: https://issues.apache.org/jira/browse/NIFI-3002
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> Earlier versions of Apache NiFi could potentially enter a distributed 
> deadlock when load balancing with a Remote Process Group. Retrieval of these 
> details was obtained within the framework as a remote call was technically 
> unnecessary.  Subsequently, these actions were made asynchronous but the port 
> retrieval was left in place. This could lead to some confusion as the UI may 
> report some ports as available when technically policies may prevent data 
> transfers. By removing the legacy code, the UI will accurately reflect the 
> port availability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1189: Remove legacy site to site code to ensure port avai...

[mcgilman]

GitHub user mcgilman opened a pull request:

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

Remove legacy site to site code to ensure port availability is accurate

NIFI-3002:
- Removing legacy code when retrieving site to site details when the target 
instance is this local NiFi.
- Ensures the UI accurately reflects available remote ports.
NIFI-2603:
- Fixing color of remote input/output port status in connection label.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mcgilman/nifi NIFI-3002

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1189.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1189


commit 11d54aa8b4a31e81b020740d5d07df4ae23862ef
Author: Matt Gilman 
Date:   2016-11-08T20:57:21Z

NIFI-3002:
- Removing legacy code when retrieving site to site details when the target 
instance is this local NiFi.
- Ensures the UI accurately reflects available remote ports.
NIFI-2603:
- Fixing color of remote output port status in connection label.




---
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.
---

[jira] [Commented] (NIFI-3002) Remove legacy code for retrieving Site To Site details

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648770#comment-15648770
 ] 

ASF GitHub Bot commented on NIFI-3002:
--

GitHub user mcgilman opened a pull request:

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

Remove legacy site to site code to ensure port availability is accurate

NIFI-3002:
- Removing legacy code when retrieving site to site details when the target 
instance is this local NiFi.
- Ensures the UI accurately reflects available remote ports.
NIFI-2603:
- Fixing color of remote input/output port status in connection label.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mcgilman/nifi NIFI-3002

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1189.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1189


commit 11d54aa8b4a31e81b020740d5d07df4ae23862ef
Author: Matt Gilman 
Date:   2016-11-08T20:57:21Z

NIFI-3002:
- Removing legacy code when retrieving site to site details when the target 
instance is this local NiFi.
- Ensures the UI accurately reflects available remote ports.
NIFI-2603:
- Fixing color of remote output port status in connection label.




> Remove legacy code for retrieving Site To Site details
> --
>
> Key: NIFI-3002
> URL: https://issues.apache.org/jira/browse/NIFI-3002
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> Earlier versions of Apache NiFi could potentially enter a distributed 
> deadlock when load balancing with a Remote Process Group. Retrieval of these 
> details was obtained within the framework as a remote call was technically 
> unnecessary.  Subsequently, these actions were made asynchronous but the port 
> retrieval was left in place. This could lead to some confusion as the UI may 
> report some ports as available when technically policies may prevent data 
> transfers. By removing the legacy code, the UI will accurately reflect the 
> port availability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #952: Nifi 2673: Add MERGE support on processor ConvertJSONTOSQL

[patricker]

Github user patricker commented on the issue:

https://github.com/apache/nifi/pull/952
  
Paul is on vacation, but I worked with him on this.

After looking over the syntax I can see why this worked for us but not for 
others.  It looks like we used a syntax for Teradata that allows you to MERGE 
single rows, `USING VALUES`, that isn't done the same way on other platforms.  
We derived it from the standard MERGE syntax, but didn't notice when we 
deviated from the standard.  

For reference: the syntax for MS SQL Server seems to be 
http://stackoverflow.com/a/5981300/328968.

I don't see any issues with moving this into a `DatabaseAdapter`, but it 
would also make sense to me to have a default, maybe something closer to the MS 
SQL one(?) that could be used if no `DatabaseAdapter` is found. I'm not sure 
where it makes sense for that default implementation to live.


---
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.
---

[jira] [Commented] (NIFI-2724) JMX Processor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648764#comment-15648764
 ] 

ASF GitHub Bot commented on NIFI-2724:
--

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

https://github.com/apache/nifi/pull/1016#discussion_r87081671
  
--- Diff: 
nifi-nar-bundles/nifi-jmx-bundle/nifi-jmx-processors/src/main/java/org/apache/nifi/processors/jmx/GetJMX.java
 ---
@@ -0,0 +1,385 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.jmx;
+
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.InputRequirement.Requirement;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.PropertyValue;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.SeeAlso;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.io.OutputStreamCallback;
+import org.apache.nifi.processor.util.StandardValidators;
+
+import javax.json.Json;
+import javax.json.JsonBuilderFactory;
+import javax.management.MBeanAttributeInfo;
+import javax.management.MBeanInfo;
+import javax.management.MBeanServerConnection;
+import javax.management.ObjectName;
+import javax.management.remote.JMXConnector;
+import javax.management.remote.JMXConnectorFactory;
+import javax.management.remote.JMXServiceURL;
+import javax.management.ReflectionException;
+import javax.management.InstanceNotFoundException;
+import javax.management.IntrospectionException;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+import java.util.Map;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.Hashtable;
+import java.util.ListIterator;
+import java.util.concurrent.BlockingQueue;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicLong;
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;
+
+@Tags({"JMX"})
+@InputRequirement(Requirement.INPUT_FORBIDDEN)
+@SeeAlso({})
+@CapabilityDescription(
+"Connects to the JMX RMI Url on the configured hostname and port.  
"
++ "All domains are queried and can be filtered by 
providing the full domain name "
++ "and optional MBean type as whitelist or blacklist 
parameters.\n\n"
++ "Blacklist example to exclude all types that start with 
'Memory' and GarbageCollector from the "
++ "java.lang domain and everything from the 
java.util.logging domain:"
++ "\n\njava.lang:Memory.* 
GarbageCollector,java.util.logging")
+public class GetJMX extends AbstractProcessor {
+
+public static final PropertyDescriptor HOSTNAME = new 
PropertyDescriptor
+.Builder().name("Hostname")
+.description("The JMX Hostname or IP address")
+.required(true)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+.build();
+
+public static final PropertyDescriptor PORT = new PropertyDescriptor
+.Builder().name("Port")
+.description("The JMX Port")
+

[GitHub] nifi pull request #1016: NIFI-2724 New JMX Processor

[brianburnett]

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

https://github.com/apache/nifi/pull/1016#discussion_r87081671
  
--- Diff: 
nifi-nar-bundles/nifi-jmx-bundle/nifi-jmx-processors/src/main/java/org/apache/nifi/processors/jmx/GetJMX.java
 ---
@@ -0,0 +1,385 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.processors.jmx;
+
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.InputRequirement.Requirement;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.PropertyValue;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.SeeAlso;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessorInitializationContext;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.io.OutputStreamCallback;
+import org.apache.nifi.processor.util.StandardValidators;
+
+import javax.json.Json;
+import javax.json.JsonBuilderFactory;
+import javax.management.MBeanAttributeInfo;
+import javax.management.MBeanInfo;
+import javax.management.MBeanServerConnection;
+import javax.management.ObjectName;
+import javax.management.remote.JMXConnector;
+import javax.management.remote.JMXConnectorFactory;
+import javax.management.remote.JMXServiceURL;
+import javax.management.ReflectionException;
+import javax.management.InstanceNotFoundException;
+import javax.management.IntrospectionException;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.List;
+import java.util.Set;
+import java.util.Map;
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.Hashtable;
+import java.util.ListIterator;
+import java.util.concurrent.BlockingQueue;
+import java.util.concurrent.LinkedBlockingQueue;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicLong;
+import java.util.concurrent.locks.Lock;
+import java.util.concurrent.locks.ReentrantLock;
+
+@Tags({"JMX"})
+@InputRequirement(Requirement.INPUT_FORBIDDEN)
+@SeeAlso({})
+@CapabilityDescription(
+"Connects to the JMX RMI Url on the configured hostname and port.  
"
++ "All domains are queried and can be filtered by 
providing the full domain name "
++ "and optional MBean type as whitelist or blacklist 
parameters.\n\n"
++ "Blacklist example to exclude all types that start with 
'Memory' and GarbageCollector from the "
++ "java.lang domain and everything from the 
java.util.logging domain:"
++ "\n\njava.lang:Memory.* 
GarbageCollector,java.util.logging")
+public class GetJMX extends AbstractProcessor {
+
+public static final PropertyDescriptor HOSTNAME = new 
PropertyDescriptor
+.Builder().name("Hostname")
+.description("The JMX Hostname or IP address")
+.required(true)
+.addValidator(StandardValidators.NON_EMPTY_VALIDATOR)
+.build();
+
+public static final PropertyDescriptor PORT = new PropertyDescriptor
+.Builder().name("Port")
+.description("The JMX Port")
+.required(true)
+.addValidator(StandardValidators.PORT_VALIDATOR)
+.build();
+
+public static final PropertyDescriptor WHITELIST = new 
PropertyDescriptor
+

[jira] [Created] (NIFI-3003) Move to Hadoop 2.7.x client libs

[Bryan Bende (JIRA)]

Bryan Bende created NIFI-3003:
-

 Summary: Move to Hadoop 2.7.x client libs
 Key: NIFI-3003
 URL: https://issues.apache.org/jira/browse/NIFI-3003
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Bryan Bende
Assignee: Bryan Bende
Priority: Minor


We should upgrade the Hadoop libraries NAR to use the Hadoop 2.7.x client libs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2684) Validation error messages should refer to propertyDescriptor using its displayName

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648689#comment-15648689
 ] 

ASF GitHub Bot commented on NIFI-2684:
--

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

https://github.com/apache/nifi/pull/1002#discussion_r87074726
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/components/AbstractConfigurableComponent.java
 ---
@@ -91,7 +91,9 @@ private PropertyDescriptor getPropertyDescriptor(final 
PropertyDescriptor specDe
 value = descriptor.getDefaultValue();
 }
 if (value == null && descriptor.isRequired()) {
-results.add(new 
ValidationResult.Builder().valid(false).input(null).subject(descriptor.getName()).explanation(descriptor.getName()
 + " is required").build());
+ValidationResult.Builder builder = new 
ValidationResult.Builder().valid(false).input(null).subject(descriptor.getDisplayName());
--- End diff --

Shouldn't the setting of subject to getDisplayName() only be done if it is 
not null (like you've done in the next line down)?


> Validation error messages should refer to propertyDescriptor using its 
> displayName
> --
>
> Key: NIFI-2684
> URL: https://issues.apache.org/jira/browse/NIFI-2684
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Andre
>Assignee: Andre
> Fix For: 1.1.0
>
>
> When certain validation violation are triggered, 
> {{AbstractConfigurableComponent}} refers to the descriptor using  
> {{descriptor.getName()}} 
> the result is that error messages end up referring to properties by sometimes 
> cryptic names (instead of the "pretty names" defined in {{.displayName}} )
> Users would be better of if we used {{displayName}} on error messages when 
> available, but to fallback to names in case displayName is null.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1002: NIFI-2684 - Change AbstractConfigurableComponent to...

[mattyb149]

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

https://github.com/apache/nifi/pull/1002#discussion_r87074726
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/components/AbstractConfigurableComponent.java
 ---
@@ -91,7 +91,9 @@ private PropertyDescriptor getPropertyDescriptor(final 
PropertyDescriptor specDe
 value = descriptor.getDefaultValue();
 }
 if (value == null && descriptor.isRequired()) {
-results.add(new 
ValidationResult.Builder().valid(false).input(null).subject(descriptor.getName()).explanation(descriptor.getName()
 + " is required").build());
+ValidationResult.Builder builder = new 
ValidationResult.Builder().valid(false).input(null).subject(descriptor.getDisplayName());
--- End diff --

Shouldn't the setting of subject to getDisplayName() only be done if it is 
not null (like you've done in the next line down)?


---
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-minifi pull request #50: MINIFI-107 - Process group support

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/nifi-minifi/pull/50


---
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.
---

[jira] [Commented] (NIFI-2724) JMX Processor

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648632#comment-15648632
 ] 

Joseph Witt commented on NIFI-2724:
---

have removed the fix version for now.  Once the review cycle nears merge the 
fix version can be placed on the next appropriate release.

> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2724) JMX Processor

[Joseph Witt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-2724:
--
Fix Version/s: (was: 1.1.0)

> JMX Processor
> -
>
> Key: NIFI-2724
> URL: https://issues.apache.org/jira/browse/NIFI-2724
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Affects Versions: 1.0.0
> Environment: All platforms with Java RMI support for JMX
>Reporter: Brian Burnett
>Assignee: Andre
>Priority: Minor
>  Labels: processor
> Attachments: 0001-NIFI-2724-New-JMX-Processor.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The JMX Processor feature addition includes only GetJMX without 
> SecurityManager capabilities at this time.  The processor in its current 
> state is capable of pulling MBean Property and Attribute values from a remote 
> RMI Server.  Each set of Mbean data is wrapped in a JSON formatted FlowFile 
> for downstream processing.  It has the ability to control content with 
> whitelist and blacklist properties.
> Possible use for this processor and the reason it was created is to help make 
> sense of Kafka server metrics.
> Will followup with a SecurityManager Context Service and PutJMX Processor.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2954) Bouncycastle dependencies are duplicated throughout NARs

[Joseph Witt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-2954:
--
Fix Version/s: (was: 1.1.0)

> Bouncycastle dependencies are duplicated throughout NARs
> 
>
> Key: NIFI-2954
> URL: https://issues.apache.org/jira/browse/NIFI-2954
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.0.0
>Reporter: Aldrin Piri
>Assignee: Joseph Witt
>
> I was working with some of the NiFi dependencies for incorporation with/use 
> by MiNiFi and saw that several libraries were duplicated throughout all NARs.
> Of note were the bouncycastle dependencies which, together, are ~4MB in size.
> {code}
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:23]
> $ find {lib,work} -type f -name '*bcprov-jdk15on*' | wc -l
>   54
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:28]
> $ find {lib,work} -type f -name '*bcpkix*' | wc -l
>   53
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:33]
> $ ls -lash 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcprov-jdk15on-1.54.jar
> 3.2M -rw-r--r-- 1 apiri admin 3.2M Oct  4 12:24 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcprov-jdk15on-1.54.jar
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:39]
> $ ls -lash 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcpkix-jdk15on-1.54.jar
> 660K -rw-r--r-- 1 apiri admin 658K Oct  4 12:24 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcpkix-jdk15on-1.54.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2954) Bouncycastle dependencies are duplicated throughout NARs

[Joseph Witt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-2954:
--
Status: Open  (was: Patch Available)

> Bouncycastle dependencies are duplicated throughout NARs
> 
>
> Key: NIFI-2954
> URL: https://issues.apache.org/jira/browse/NIFI-2954
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.0.0
>Reporter: Aldrin Piri
>Assignee: Joseph Witt
> Fix For: 1.1.0
>
>
> I was working with some of the NiFi dependencies for incorporation with/use 
> by MiNiFi and saw that several libraries were duplicated throughout all NARs.
> Of note were the bouncycastle dependencies which, together, are ~4MB in size.
> {code}
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:23]
> $ find {lib,work} -type f -name '*bcprov-jdk15on*' | wc -l
>   54
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:28]
> $ find {lib,work} -type f -name '*bcpkix*' | wc -l
>   53
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:33]
> $ ls -lash 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcprov-jdk15on-1.54.jar
> 3.2M -rw-r--r-- 1 apiri admin 3.2M Oct  4 12:24 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcprov-jdk15on-1.54.jar
> # apiri @ computer in /usr/local/opt/nifi/libexec [17:20:39]
> $ ls -lash 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcpkix-jdk15on-1.54.jar
> 660K -rw-r--r-- 1 apiri admin 658K Oct  4 12:24 
> work/nar/framework/nifi-framework-nar-1.0.0.nar-unpacked/META-INF/bundled-dependencies/bcpkix-jdk15on-1.54.jar
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[Matt Burgess (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Burgess updated NIFI-2764:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
> Fix For: 1.1.0
>
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-1582) New processor to update attributes with state

[Joseph Percivall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Percivall updated NIFI-1582:
---
Status: Patch Available  (was: Open)

> New processor to update attributes with state
> -
>
> Key: NIFI-1582
> URL: https://issues.apache.org/jira/browse/NIFI-1582
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>
> This idea was sparked by a thread on the user list and should allow basic 
> data science:
> I expect that in the future I’ll need something a little more sophisticated 
> but for now my problem is very simple:
> I want to be able to trigger an alert (only once) when an attribute in an 
> incoming stream, for instance, goes over a predefined threshold. The 
> Processor should then trigger (only once again) another trigger when the 
> signal goes back to normal (below threshold). Basically a RouteByAttribute 
> but with memory.
> Thanks 
> Claudio
> 
> Hello Claudio,
> Your use-case actually could leverage a couple of recently added features to 
> create a really cool open-source processor. The two key features that were 
> added are State Management and the ability to reference processor specific 
> variables in expression language. You can take a look at RouteText to see 
> both in action. 
> By utilizing both you can create a processor that is configured with multiple 
> Expression language expressions. There would be dynamic properties which 
> would accept expression language and then store the evaluated value via state 
> management. Then there would be a routing property (that supports expression 
> language) that could simply add an attribute to the flowfile with the 
> evaluated value which would allow it to be used by flowing processors for 
> routing.
> This would allow you to do your use-case where you store the value for the 
> incoming stream and route differently once you go over a threshold. It could 
> even allow more complex use-cases. One instance, I believe, would be possible 
> is to have a running average and standard deviation and route data to 
> different locations based on it's standard deviation.
> You can think of this like an UpdateAttribute with the ability to store and 
> calculate variables using expression language.
> Joe



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (NIFI-2823) tls-toolkit standalone should allow DN specification

[Yolanda M. Davis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yolanda M. Davis reassigned NIFI-2823:
--

Assignee: Yolanda M. Davis  (was: Bryan Rosander)

> tls-toolkit standalone should allow DN specification
> 
>
> Key: NIFI-2823
> URL: https://issues.apache.org/jira/browse/NIFI-2823
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bryan Rosander
>Assignee: Yolanda M. Davis
> Fix For: 1.1.0
>
>
> When running the tls-toolkit in standalone mode, users should be able to 
> specify a DN for the nifi instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[Matt Burgess (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Burgess updated NIFI-2764:
---
Fix Version/s: 1.1.0

> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
> Fix For: 1.1.0
>
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648611#comment-15648611
 ] 

ASF subversion and git services commented on NIFI-2764:
---

Commit 4b4e099f2ecd990f67f0afc994ecc4d46cbfc595 in nifi's branch 
refs/heads/master from patricker
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=4b4e099 ]

NIFI-2764

Signed-off-by: Matt Burgess 

NIFI-2764: Updated call to convertToAvroStream in TestJdbcCommon

This closes #1009


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
> Fix For: 1.1.0
>
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648614#comment-15648614
 ] 

ASF GitHub Bot commented on NIFI-2764:
--

Github user asfgit closed the pull request at:

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


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
> Fix For: 1.1.0
>
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2823) tls-toolkit standalone should allow DN specification

[Yolanda M. Davis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yolanda M. Davis updated NIFI-2823:
---
 Assignee: Bryan Rosander
Fix Version/s: 1.1.0
Affects Version/s: 1.0.0
   Status: Patch Available  (was: Open)

Patch is available: https://github.com/apache/nifi/pull/1066

[~YolandaMDavis] will review

> tls-toolkit standalone should allow DN specification
> 
>
> Key: NIFI-2823
> URL: https://issues.apache.org/jira/browse/NIFI-2823
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
> Fix For: 1.1.0
>
>
> When running the tls-toolkit in standalone mode, users should be able to 
> specify a DN for the nifi instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648612#comment-15648612
 ] 

ASF subversion and git services commented on NIFI-2764:
---

Commit 4b4e099f2ecd990f67f0afc994ecc4d46cbfc595 in nifi's branch 
refs/heads/master from patricker
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=4b4e099 ]

NIFI-2764

Signed-off-by: Matt Burgess 

NIFI-2764: Updated call to convertToAvroStream in TestJdbcCommon

This closes #1009


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
> Fix For: 1.1.0
>
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648610#comment-15648610
 ] 

ASF GitHub Bot commented on NIFI-2764:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/1009
  
+1 LGTM, thank you for the contribution! Merging to master


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
> Fix For: 1.1.0
>
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1009: NIFI-2764 - MS SQL TINYINT Avro Issue

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 issue #1009: NIFI-2764 - MS SQL TINYINT Avro Issue

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/1009
  
+1 LGTM, thank you for the contribution! Merging to 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.
---

[jira] [Commented] (NIFI-2926) Add a user-centric view for authorization policies

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648596#comment-15648596
 ] 

ASF GitHub Bot commented on NIFI-2926:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1188
  
Reviewing...


> Add a user-centric view for authorization policies
> --
>
> Key: NIFI-2926
> URL: https://issues.apache.org/jira/browse/NIFI-2926
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>  Labels: UI, authorization
>
> The UI for managing authorizations in 1.0.0 is policy-centric, meaning in 
> order to view which access privileges a specific user has, you need to 
> navigate to each individual policy and see if the user has been added to it.
> We should add a view to the UI where you can select a user and then see all 
> the access policies that he/she has.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1188: [NIFI-2926] add policy action item to the user table and a...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1188
  
Reviewing...


---
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.
---

[jira] [Commented] (NIFI-2823) tls-toolkit standalone should allow DN specification

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648587#comment-15648587
 ] 

ASF GitHub Bot commented on NIFI-2823:
--

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/1066
  
@brosander will review


> tls-toolkit standalone should allow DN specification
> 
>
> Key: NIFI-2823
> URL: https://issues.apache.org/jira/browse/NIFI-2823
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>
> When running the tls-toolkit in standalone mode, users should be able to 
> specify a DN for the nifi instance



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1066: NIFI-2823 - Adding nifiDnPrefix, nifiDnSuffix options to s...

[YolandaMDavis]

Github user YolandaMDavis commented on the issue:

https://github.com/apache/nifi/pull/1066
  
@brosander will review


---
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.
---

[jira] [Assigned] (NIFI-3001) The authorizers.xml file should be parsed for new users/node identities even if users.xml already exists.

[Bryan Bende (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Bende reassigned NIFI-3001:
-

Assignee: Bryan Bende

> The authorizers.xml file should be parsed for new users/node identities even 
> if users.xml already exists.
> -
>
> Key: NIFI-3001
> URL: https://issues.apache.org/jira/browse/NIFI-3001
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Matthew Clarke
>Assignee: Bryan Bende
>
> The intent of having an users.xml and authorizations.xml file is so that the 
> users.xml file can be used/copied to multiple systems for reuse. 
> The problem is when standing up a new system/cluster with a pre-populated 
> users.xml file, NiFi does not update it on startup. A new system is very 
> likely to have new node identities defined in the authorizers.xml file that 
> will not exist in the ported users.xml file.
> My thought is that on every startup NiFi should parse the "node identities" 
> from the authorizers.xml file and add them if missing to the users.xml file 
> and grant those added users to the /proxy resource in the authorizations.xml. 
>  This reduces complications users can experience when adding additional nodes 
> to a pre-existing cluster.
> The "Initial admin" and "legacy authorized-users.xml" settings in the 
> authorizers.xml file should only ever be parsed once and only if a 
> authorizations.xml file does not exist.   If the authorizations.xml file does 
> not exist, these users should be added to the existing users.xml file (or 
> create one if does not exist) and granted the initial admin related policy 
> resources in the authorizations.xml file.  By setting it up this way if an 
> "admin" is removed from the UI at some later time a restart of NiFi will not 
> result in that user being added back in to the existing authorizations.xml or 
> users.xml.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3002) Remove legacy code for retrieving Site To Site details

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-3002:
-

 Summary: Remove legacy code for retrieving Site To Site details
 Key: NIFI-3002
 URL: https://issues.apache.org/jira/browse/NIFI-3002
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Reporter: Matt Gilman
Assignee: Matt Gilman
 Fix For: 1.1.0


Earlier versions of Apache NiFi could potentially enter a distributed deadlock 
when load balancing with a Remote Process Group. Retrieval of these details was 
obtained within the framework as a remote call was technically unnecessary.  
Subsequently, these actions were made asynchronous but the port retrieval was 
left in place. This could lead to some confusion as the UI may report some 
ports as available when technically policies may prevent data transfers. By 
removing the legacy code, the UI will accurately reflect the port availability.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2673) Add MERGE support on processor ConvertJSONTOSQL

[Joseph Witt (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648490#comment-15648490
 ] 

Joseph Witt commented on NIFI-2673:
---

removed the fix version for now as this is still working through the 
contribution and review process.  Let's put a fix version on once it is ready 
to be merged.

Thanks

> Add MERGE support on processor ConvertJSONTOSQL
> ---
>
> Key: NIFI-2673
> URL: https://issues.apache.org/jira/browse/NIFI-2673
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Paul Gibeault
>Priority: Minor
>  Labels: features
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Update ConvertJSONToSQL to add support for ANSI SQL MERGE 
> https://en.wikipedia.org/wiki/Merge_(SQL)
> This would simplify workflows that manage ingestion of slowly changing 
> dimensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2998) Add validator to Avro Record Name in InferAvroSchema

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648505#comment-15648505
 ] 

ASF subversion and git services commented on NIFI-2998:
---

Commit 63bda32a8befe7f0da01a6c543462f6b2b2daced in nifi's branch 
refs/heads/master from [~mattyb149]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=63bda32 ]

NIFI-2998: Add validator to Avro Record Name in InferAvroSchema

This closes #1187


> Add validator to Avro Record Name in InferAvroSchema
> 
>
> Key: NIFI-2998
> URL: https://issues.apache.org/jira/browse/NIFI-2998
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>  Labels: avro, beginner, beginners, easyfix, starter
> Fix For: 1.1.0
>
>
> The Avro Record Name property in the InferAvroSchema processor is required to 
> be non-empty, but no checking is done to ensure the record name is valid for 
> Avro.
> Avro naming rules: https://avro.apache.org/docs/1.7.7/spec.html#Names
> The validator should accept the name if Expression Language is used (noting 
> in the documentation for the property that the value of the expression must 
> adhere to the Avro naming rules), or validate the property value against the 
> Avro naming rules if Expression Language is not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2998) Add validator to Avro Record Name in InferAvroSchema

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2998:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Add validator to Avro Record Name in InferAvroSchema
> 
>
> Key: NIFI-2998
> URL: https://issues.apache.org/jira/browse/NIFI-2998
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>  Labels: avro, beginner, beginners, easyfix, starter
> Fix For: 1.1.0
>
>
> The Avro Record Name property in the InferAvroSchema processor is required to 
> be non-empty, but no checking is done to ensure the record name is valid for 
> Avro.
> Avro naming rules: https://avro.apache.org/docs/1.7.7/spec.html#Names
> The validator should accept the name if Expression Language is used (noting 
> in the documentation for the property that the value of the expression must 
> adhere to the Avro naming rules), or validate the property value against the 
> Avro naming rules if Expression Language is not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2998) Add validator to Avro Record Name in InferAvroSchema

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648507#comment-15648507
 ] 

ASF GitHub Bot commented on NIFI-2998:
--

Github user asfgit closed the pull request at:

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


> Add validator to Avro Record Name in InferAvroSchema
> 
>
> Key: NIFI-2998
> URL: https://issues.apache.org/jira/browse/NIFI-2998
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>  Labels: avro, beginner, beginners, easyfix, starter
> Fix For: 1.1.0
>
>
> The Avro Record Name property in the InferAvroSchema processor is required to 
> be non-empty, but no checking is done to ensure the record name is valid for 
> Avro.
> Avro naming rules: https://avro.apache.org/docs/1.7.7/spec.html#Names
> The validator should accept the name if Expression Language is used (noting 
> in the documentation for the property that the value of the expression must 
> adhere to the Avro naming rules), or validate the property value against the 
> Avro naming rules if Expression Language is not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2998) Add validator to Avro Record Name in InferAvroSchema

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2998:
---
Fix Version/s: 1.1.0

> Add validator to Avro Record Name in InferAvroSchema
> 
>
> Key: NIFI-2998
> URL: https://issues.apache.org/jira/browse/NIFI-2998
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>  Labels: avro, beginner, beginners, easyfix, starter
> Fix For: 1.1.0
>
>
> The Avro Record Name property in the InferAvroSchema processor is required to 
> be non-empty, but no checking is done to ensure the record name is valid for 
> Avro.
> Avro naming rules: https://avro.apache.org/docs/1.7.7/spec.html#Names
> The validator should accept the name if Expression Language is used (noting 
> in the documentation for the property that the value of the expression must 
> adhere to the Avro naming rules), or validate the property value against the 
> Avro naming rules if Expression Language is not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1187: NIFI-2998: Add validator to Avro Record Name in Inf...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[jira] [Created] (NIFI-3001) The authorizers.xml file should be parsed for new users/node identities even if users.xml already exists.

[Matthew Clarke (JIRA)]

Matthew Clarke created NIFI-3001:


 Summary: The authorizers.xml file should be parsed for new 
users/node identities even if users.xml already exists.
 Key: NIFI-3001
 URL: https://issues.apache.org/jira/browse/NIFI-3001
 Project: Apache NiFi
  Issue Type: Improvement
Affects Versions: 1.0.0
Reporter: Matthew Clarke


The intent of having an users.xml and authorizations.xml file is so that the 
users.xml file can be used/copied to multiple systems for reuse. 

The problem is when standing up a new system/cluster with a pre-populated 
users.xml file, NiFi does not update it on startup. A new system is very likely 
to have new node identities defined in the authorizers.xml file that will not 
exist in the ported users.xml file.

My thought is that on every startup NiFi should parse the "node identities" 
from the authorizers.xml file and add them if missing to the users.xml file and 
grant those added users to the /proxy resource in the authorizations.xml.  This 
reduces complications users can experience when adding additional nodes to a 
pre-existing cluster.

The "Initial admin" and "legacy authorized-users.xml" settings in the 
authorizers.xml file should only ever be parsed once and only if a 
authorizations.xml file does not exist.   If the authorizations.xml file does 
not exist, these users should be added to the existing users.xml file (or 
create one if does not exist) and granted the initial admin related policy 
resources in the authorizations.xml file.  By setting it up this way if an 
"admin" is removed from the UI at some later time a restart of NiFi will not 
result in that user being added back in to the existing authorizations.xml or 
users.xml.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648503#comment-15648503
 ] 

ASF GitHub Bot commented on NIFI-401:
-

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1185
  
Will do! Thanks for reviewing and thanks to @beugley doing most of the work 
on this PR.


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1185: NIFI-401: Decouple Scheduling Strategy from Execution Node

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1185
  
Will do! Thanks for reviewing and thanks to @beugley doing most of the work 
on this PR.


---
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 issue #1187: NIFI-2998: Add validator to Avro Record Name in InferAvroS...

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1187
  
+1, merging


---
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.
---

[jira] [Commented] (NIFI-2998) Add validator to Avro Record Name in InferAvroSchema

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648500#comment-15648500
 ] 

ASF GitHub Bot commented on NIFI-2998:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1187
  
+1, merging


> Add validator to Avro Record Name in InferAvroSchema
> 
>
> Key: NIFI-2998
> URL: https://issues.apache.org/jira/browse/NIFI-2998
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>  Labels: avro, beginner, beginners, easyfix, starter
>
> The Avro Record Name property in the InferAvroSchema processor is required to 
> be non-empty, but no checking is done to ensure the record name is valid for 
> Avro.
> Avro naming rules: https://avro.apache.org/docs/1.7.7/spec.html#Names
> The validator should accept the name if Expression Language is used (noting 
> in the documentation for the property that the value of the expression must 
> adhere to the Avro naming rules), or validate the property value against the 
> Avro naming rules if Expression Language is not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648496#comment-15648496
 ] 

ASF GitHub Bot commented on NIFI-401:
-

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

https://github.com/apache/nifi/pull/1185#discussion_r87060956
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/scheduling/ExecutionNode.java ---
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.scheduling;
+
+/**
+ * Defines the Nodes where a given Component will be scheduled to run.
+ */
+public enum ExecutionNode {
--- End diff --

Could you add documentation about this to the user guide (near "Scheduling 
Strategy")?


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-401) New Scheduling strategy (On primary node - CRON )

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648497#comment-15648497
 ] 

ASF GitHub Bot commented on NIFI-401:
-

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

https://github.com/apache/nifi/pull/1185#discussion_r87047335
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/canvas/nf-processor-configuration.js
 ---
@@ -53,17 +53,11 @@ nf.ProcessorConfiguration = (function () {
 }
 
 // conditionally support event driven
-if (nf.Canvas.isClustered()) {
+if (processor.config['schedulingStrategy'] === 
'PRIMARY_NODE_ONLY') {
 strategies.push({
 text: 'On primary node',
 value: 'PRIMARY_NODE_ONLY',
-description: 'Processor will be scheduled on the primary 
node on an interval defined by the run schedule.'
-});
-} else if (processor.config['schedulingStrategy'] === 
'PRIMARY_NODE_ONLY') {
-strategies.push({
-text: 'On primary node',
-value: 'PRIMARY_NODE_ONLY',
-description: 'Processor will be scheduled on the primary 
node on an interval defined by the run schedule.',
+description: 'Processor will be scheduled on the primary 
node on an interval defined by the run schedule. This option has been 
deprecated, please use the Execution Node below.',
--- End diff --

Minor typo (missing a noun after 'Node'), should read: "please use the 
'Execution Node' option below."


> New Scheduling strategy (On primary node - CRON )
> -
>
> Key: NIFI-401
> URL: https://issues.apache.org/jira/browse/NIFI-401
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Matthew Clarke
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
> Attachments: initial prototype .png
>
>
> Currently the only scheduling strategy supported when a processor is set to 
> use "On primary Node" is Timer Driven.   There should be a second option to 
> allow cron driven On primary Node scheduling strategy.  This would allow 
> users to more control over when a given primary node only processor runs. 
> This would prevent these processors from running when configuration changes 
> or instance restarts occur.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1185: NIFI-401: Decouple Scheduling Strategy from Executi...

[JPercivall]

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

https://github.com/apache/nifi/pull/1185#discussion_r87047335
  
--- Diff: 
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/canvas/nf-processor-configuration.js
 ---
@@ -53,17 +53,11 @@ nf.ProcessorConfiguration = (function () {
 }
 
 // conditionally support event driven
-if (nf.Canvas.isClustered()) {
+if (processor.config['schedulingStrategy'] === 
'PRIMARY_NODE_ONLY') {
 strategies.push({
 text: 'On primary node',
 value: 'PRIMARY_NODE_ONLY',
-description: 'Processor will be scheduled on the primary 
node on an interval defined by the run schedule.'
-});
-} else if (processor.config['schedulingStrategy'] === 
'PRIMARY_NODE_ONLY') {
-strategies.push({
-text: 'On primary node',
-value: 'PRIMARY_NODE_ONLY',
-description: 'Processor will be scheduled on the primary 
node on an interval defined by the run schedule.',
+description: 'Processor will be scheduled on the primary 
node on an interval defined by the run schedule. This option has been 
deprecated, please use the Execution Node below.',
--- End diff --

Minor typo (missing a noun after 'Node'), should read: "please use the 
'Execution Node' option below."


---
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.
---

[jira] [Updated] (NIFI-2673) Add MERGE support on processor ConvertJSONTOSQL

[Joseph Witt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joseph Witt updated NIFI-2673:
--
Fix Version/s: (was: 1.1.0)

> Add MERGE support on processor ConvertJSONTOSQL
> ---
>
> Key: NIFI-2673
> URL: https://issues.apache.org/jira/browse/NIFI-2673
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Paul Gibeault
>Priority: Minor
>  Labels: features
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Update ConvertJSONToSQL to add support for ANSI SQL MERGE 
> https://en.wikipedia.org/wiki/Merge_(SQL)
> This would simplify workflows that manage ingestion of slowly changing 
> dimensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648484#comment-15648484
 ] 

ASF GitHub Bot commented on NIFI-2764:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/1009
  
Reviewing...


> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1009: NIFI-2764 - MS SQL TINYINT Avro Issue

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/1009
  
Reviewing...


---
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.
---

[jira] [Updated] (NIFI-2764) JdbcCommon Avro Can't Process Java Short Types

[Matt Burgess (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Burgess updated NIFI-2764:
---
Status: Patch Available  (was: Open)

> JdbcCommon Avro Can't Process Java Short Types
> --
>
> Key: NIFI-2764
> URL: https://issues.apache.org/jira/browse/NIFI-2764
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>
> Microsoft SQL Server returns TINYINT values as Java Short's.  Avro is unable 
> to write datum's of this type and throws an exception when trying to.
> This currently breaks QueryDatabaseTable at the very least when querying MS 
> SQL Server with TINYINT's in the ResultSet.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi issue #1187: NIFI-2998: Add validator to Avro Record Name in InferAvroS...

[olegz]

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1187
  
Reviewing. . .


---
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.
---

[jira] [Updated] (NIFI-2926) Add a user-centric view for authorization policies

[Scott Aslan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Aslan updated NIFI-2926:
--
Status: Patch Available  (was: In Progress)

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

> Add a user-centric view for authorization policies
> --
>
> Key: NIFI-2926
> URL: https://issues.apache.org/jira/browse/NIFI-2926
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>  Labels: UI, authorization
>
> The UI for managing authorizations in 1.0.0 is policy-centric, meaning in 
> order to view which access privileges a specific user has, you need to 
> navigate to each individual policy and see if the user has been added to it.
> We should add a view to the UI where you can select a user and then see all 
> the access policies that he/she has.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2998) Add validator to Avro Record Name in InferAvroSchema

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648475#comment-15648475
 ] 

ASF GitHub Bot commented on NIFI-2998:
--

Github user olegz commented on the issue:

https://github.com/apache/nifi/pull/1187
  
Reviewing. . .


> Add validator to Avro Record Name in InferAvroSchema
> 
>
> Key: NIFI-2998
> URL: https://issues.apache.org/jira/browse/NIFI-2998
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>  Labels: avro, beginner, beginners, easyfix, starter
>
> The Avro Record Name property in the InferAvroSchema processor is required to 
> be non-empty, but no checking is done to ensure the record name is valid for 
> Avro.
> Avro naming rules: https://avro.apache.org/docs/1.7.7/spec.html#Names
> The validator should accept the name if Expression Language is used (noting 
> in the documentation for the property that the value of the expression must 
> adhere to the Avro naming rules), or validate the property value against the 
> Avro naming rules if Expression Language is not present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-3000) Avro processors should support logical types

[Matt Burgess (JIRA)]

Matt Burgess created NIFI-3000:
--

 Summary: Avro processors should support logical types
 Key: NIFI-3000
 URL: https://issues.apache.org/jira/browse/NIFI-3000
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Extensions
Reporter: Matt Burgess


Most/All of the Avro processors cannot currently handle logical types such as 
fixed and date types. The current version of Avro used is 1.7.7, which only 
supports decimal and fixed logical types 
(https://avro.apache.org/docs/1.7.7/spec.html#Logical+Types). If this version 
is to be retained, then support for decimal and fixed logical types should be 
added wherever possible.

However I think a better option is to upgrade to Avro 1.8.x and support all the 
corresponding logical types 
(https://avro.apache.org/docs/1.8.0/spec.html#Logical+Types). This would 
involve regression testing and possibly breaking changes (although hopefully 
not from the user perspective).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (NIFI-2972) SQL-to-Avro processors do not convert SMALLINT correctly

[Matt Burgess (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Burgess resolved NIFI-2972.

   Resolution: Duplicate
Fix Version/s: (was: 1.0.0)

This looks like a duplicate of NIFI-2764

> SQL-to-Avro processors do not convert SMALLINT correctly
> 
>
> Key: NIFI-2972
> URL: https://issues.apache.org/jira/browse/NIFI-2972
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Ken Hui
>
> When using ExecuteSQL processors to query MS SQL, Avro did not handle 
> SMALLINT object correctly.
> It triggers the following errors:
> 11:57:39 PDT ERROR
> ExecuteSQL[id=01581003-3e41-1bf0-bec1-62c4dfa38133]
> ExecuteSQL[id=01581003-3e41-1bf0-bec1-62c4dfa38133] failed to process due to 
> org.apache.avro.file.DataFileWriter$AppendWriteException:
> org.apache.avro.AvroRuntimeException: Unknown datum type 
> java.lang.Short:1800; rolling back session:
> org.apacheavro.file.DataFileWriter$AppendWriteException:
> org.apache.avro.AvroRuntimeException: Unknown datum type java.lang.Short:1800



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (NIFI-2999) In NiFI Cluster, new cluster coordinator election could result in all nodes being dropped.

[Matthew Clarke (JIRA)]

Matthew Clarke created NIFI-2999:


 Summary: In NiFI Cluster, new cluster coordinator election could 
result in all nodes being dropped.
 Key: NIFI-2999
 URL: https://issues.apache.org/jira/browse/NIFI-2999
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.0
Reporter: Matthew Clarke


When NiFi elects a new cluster coordinator, the newly elected coordinator 
starts accepting heartbeats from the cluster nodes. If another cluster 
coordinator election occurs later which results in the original Node being 
elected as the cluster coordinator once again, old heartbeat messages exist 
which will trigger all nodes to be dropped due to their age exceeding the 
threshold for last received heartbeat.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2841) SplitAvro Processor is Broken

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2841:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> SplitAvro Processor is Broken
> -
>
> Key: NIFI-2841
> URL: https://issues.apache.org/jira/browse/NIFI-2841
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: David Hicks
>Assignee: Bryan Bende
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: NIFI-2841.patch
>
>
> This is largely the fault of the Avro DataFileStream reader, but it's making 
> the processor unusable.  The problem appears to occur when you make the 
> following series of calls (which happens because of the splitSize comparison):
> reader.next() -> returns last element
> reader.hasNext() -> returns false
> reader.hasNext() -> returns true
> reader.next() -> EOFException
> org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
> SplitAvro[id=22e03ca4-0151-4474-92fc-040e1fe12ab9]: java.io.EOFException
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2013)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1.process(SplitAvro.java:250)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1851)
>  ~[na:na]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1822)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter.split(SplitAvro.java:236)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processors.avro.SplitAvro.onTrigger(SplitAvro.java:202) 
> ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  [nifi-api-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.io.EOFException: null
>   at 
> org.apache.avro.io.BinaryDecoder.ensureBounds(BinaryDecoder.java:473) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:128) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:363)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:355)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:157) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:193)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:183)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:151) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:142) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.file.DataFileStream.next(DataFileStream.java:233) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> 

[jira] [Commented] (NIFI-2841) SplitAvro Processor is Broken

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648439#comment-15648439
 ] 

ASF subversion and git services commented on NIFI-2841:
---

Commit 78020825e9edfee1842e3d642ef762e5be1ab4bd in nifi's branch 
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=7802082 ]

NIFI-2841 Refactoring logic in SplitAvro RecordSplitter to avoid making two 
calls in a row to reader.hasNext()

This closes #1088


> SplitAvro Processor is Broken
> -
>
> Key: NIFI-2841
> URL: https://issues.apache.org/jira/browse/NIFI-2841
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: David Hicks
>Assignee: Bryan Bende
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: NIFI-2841.patch
>
>
> This is largely the fault of the Avro DataFileStream reader, but it's making 
> the processor unusable.  The problem appears to occur when you make the 
> following series of calls (which happens because of the splitSize comparison):
> reader.next() -> returns last element
> reader.hasNext() -> returns false
> reader.hasNext() -> returns true
> reader.next() -> EOFException
> org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
> SplitAvro[id=22e03ca4-0151-4474-92fc-040e1fe12ab9]: java.io.EOFException
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2013)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1.process(SplitAvro.java:250)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1851)
>  ~[na:na]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1822)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter.split(SplitAvro.java:236)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processors.avro.SplitAvro.onTrigger(SplitAvro.java:202) 
> ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  [nifi-api-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.io.EOFException: null
>   at 
> org.apache.avro.io.BinaryDecoder.ensureBounds(BinaryDecoder.java:473) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:128) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:363)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:355)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:157) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:193)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:183)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> 

[jira] [Commented] (NIFI-2841) SplitAvro Processor is Broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648441#comment-15648441
 ] 

ASF GitHub Bot commented on NIFI-2841:
--

Github user asfgit closed the pull request at:

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


> SplitAvro Processor is Broken
> -
>
> Key: NIFI-2841
> URL: https://issues.apache.org/jira/browse/NIFI-2841
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: David Hicks
>Assignee: Bryan Bende
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: NIFI-2841.patch
>
>
> This is largely the fault of the Avro DataFileStream reader, but it's making 
> the processor unusable.  The problem appears to occur when you make the 
> following series of calls (which happens because of the splitSize comparison):
> reader.next() -> returns last element
> reader.hasNext() -> returns false
> reader.hasNext() -> returns true
> reader.next() -> EOFException
> org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
> SplitAvro[id=22e03ca4-0151-4474-92fc-040e1fe12ab9]: java.io.EOFException
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2013)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1.process(SplitAvro.java:250)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1851)
>  ~[na:na]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1822)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter.split(SplitAvro.java:236)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processors.avro.SplitAvro.onTrigger(SplitAvro.java:202) 
> ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  [nifi-api-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.io.EOFException: null
>   at 
> org.apache.avro.io.BinaryDecoder.ensureBounds(BinaryDecoder.java:473) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:128) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:363)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:355)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:157) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:193)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:183)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:151) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:142) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.file.DataFileStream.next(DataFileStream.java:233) 

[GitHub] nifi pull request #1088: NIFI-2841 Refactoring logic in SplitAvro RecordSpli...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[jira] [Commented] (NIFI-2841) SplitAvro Processor is Broken

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648422#comment-15648422
 ] 

ASF GitHub Bot commented on NIFI-2841:
--

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

https://github.com/apache/nifi/pull/1088#discussion_r87056058
  
--- Diff: 
nifi-nar-bundles/nifi-avro-bundle/nifi-avro-processors/src/main/java/org/apache/nifi/processors/avro/SplitAvro.java
 ---
@@ -267,7 +267,8 @@ public void process(InputStream rawIn) throws 
IOException {
 }
 
 // while records are left, start a new split by 
spawning a FlowFile
-while (reader.hasNext()) {
+final AtomicReference hasNextHolder = new 
AtomicReference(reader.hasNext());
--- End diff --

Yeah, you right and in the end it's more of a stylistic comment. So, I am 
good.


> SplitAvro Processor is Broken
> -
>
> Key: NIFI-2841
> URL: https://issues.apache.org/jira/browse/NIFI-2841
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: David Hicks
>Assignee: Bryan Bende
>Priority: Critical
> Fix For: 1.1.0
>
> Attachments: NIFI-2841.patch
>
>
> This is largely the fault of the Avro DataFileStream reader, but it's making 
> the processor unusable.  The problem appears to occur when you make the 
> following series of calls (which happens because of the splitSize comparison):
> reader.next() -> returns last element
> reader.hasNext() -> returns false
> reader.hasNext() -> returns true
> reader.next() -> EOFException
> org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
> SplitAvro[id=22e03ca4-0151-4474-92fc-040e1fe12ab9]: java.io.EOFException
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2013)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1.process(SplitAvro.java:250)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1851)
>  ~[na:na]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1822)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter.split(SplitAvro.java:236)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processors.avro.SplitAvro.onTrigger(SplitAvro.java:202) 
> ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  [nifi-api-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.io.EOFException: null
>   at 
> org.apache.avro.io.BinaryDecoder.ensureBounds(BinaryDecoder.java:473) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:128) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:363)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:355)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> 

[jira] [Commented] (NIFI-2926) Add a user-centric view for authorization policies

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648407#comment-15648407
 ] 

ASF GitHub Bot commented on NIFI-2926:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-2926] add policy action item to the user table and add user cen…

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.

…tric policy dialog with user policy listing table compolete with GoTo 
action.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scottyaslan/nifi NIFI-2926

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1188.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1188


commit 4c441a7b5c57bbe1be6d08127965f67db8ed161e
Author: Scott Aslan 
Date:   2016-11-08T18:20:51Z

[NIFI-2926] add policy action item to the user table and add user centric 
policy dialog with user policy listing table compolete with GoTo action.




> Add a user-centric view for authorization policies
> --
>
> Key: NIFI-2926
> URL: https://issues.apache.org/jira/browse/NIFI-2926
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>  Labels: UI, authorization
>
> The UI for managing authorizations in 1.0.0 is policy-centric, meaning in 
> order to view which access privileges a specific user has, you need to 
> navigate to each individual policy and see if the user has been added to it.
> We should add a view to the UI where you can select a user and then see all 
> the access policies that he/she has.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] nifi pull request #1188: [NIFI-2926] add policy action item to the user tabl...

[scottyaslan]

GitHub user scottyaslan opened a pull request:

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

[NIFI-2926] add policy action item to the user table and add user cen…

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.

…tric policy dialog with user policy listing table compolete with GoTo 
action.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scottyaslan/nifi NIFI-2926

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/1188.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1188


commit 4c441a7b5c57bbe1be6d08127965f67db8ed161e
Author: Scott Aslan 
Date:   2016-11-08T18:20:51Z

[NIFI-2926] add policy action item to the user table and add user centric 
policy dialog with user policy listing table compolete with GoTo action.




---
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 issue #952: Nifi 2673: Add MERGE support on processor ConvertJSONTOSQL

[mattyb149]

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/952
  
It's a real bummer that an ANSI "standard" such as MERGE is done 
differently by so many databases :( If there isn't an application of the 
standard MERGE syntax that applies to many databases (or the functionality is 
desired for DBs that don't support the standard), then I like Bryan's 
suggestion of using the DatabaseAdapter interface. We could add a method such 
as getMergeStatement() to DatabaseAdapter, with no-op (or exception-throwing) 
default implementation (on the interface or the subclasses), then implement for 
Oracle (which has a DatabaseAdapter already) and add a TeradataDatabaseAdapter 
subclass to implement their version of the syntax. Thoughts?

Also, it sounds like the community is gearing up for a 1.1.0 release soon, 
do you think you'd have any updates ready in the near-term? If not (which is 
totally fine btw), could we push the Fix Version for the Jira to 1.2.0?


---
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 #1156: NIFI-2909 and NIFI-1712 Per-Instance ClassLoading

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[jira] [Commented] (NIFI-2909) Provide a framework mechanism for loading additional classpath resources

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648346#comment-15648346
 ] 

ASF GitHub Bot commented on NIFI-2909:
--

Github user asfgit closed the pull request at:

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


> Provide a framework mechanism for loading additional classpath resources
> 
>
> Key: NIFI-2909
> URL: https://issues.apache.org/jira/browse/NIFI-2909
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
> Fix For: 1.1.0
>
>
> We currently have several components with a property for specifying 
> additional classpath resources (DBCP connection pool, scripting processors, 
> JMS). Each of these components is responsible for handling this in its own 
> way. 
> The framework should provide a more integrated solution to make it easier for 
> component developers to deal with this scenario. Some requirements that need 
> to be met by this solution:
> - Multiple instances of the same component with different resources added to 
> the classpath and not interfering with each other (i.e. two DBCP connection 
> pools using different drivers)
> - Ability to modify the actual ClassLoader of the component to deal with 
> frameworks that use Class.forName() without passing in a ClassLoader, meaning 
> if a processor loads class A and class A calls Class.forName(classBName), 
> then class B needs to be available in the ClassLoader that loaded the 
> processor's class which in turn loaded class A
> - A component developer should be able to indicate that a given 
> PropertyDescriptor represents a classpath resource and the framework should 
> take care of the ClassLoader manipulation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (NIFI-2909) Provide a framework mechanism for loading additional classpath resources

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-2909:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Provide a framework mechanism for loading additional classpath resources
> 
>
> Key: NIFI-2909
> URL: https://issues.apache.org/jira/browse/NIFI-2909
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
> Fix For: 1.1.0
>
>
> We currently have several components with a property for specifying 
> additional classpath resources (DBCP connection pool, scripting processors, 
> JMS). Each of these components is responsible for handling this in its own 
> way. 
> The framework should provide a more integrated solution to make it easier for 
> component developers to deal with this scenario. Some requirements that need 
> to be met by this solution:
> - Multiple instances of the same component with different resources added to 
> the classpath and not interfering with each other (i.e. two DBCP connection 
> pools using different drivers)
> - Ability to modify the actual ClassLoader of the component to deal with 
> frameworks that use Class.forName() without passing in a ClassLoader, meaning 
> if a processor loads class A and class A calls Class.forName(classBName), 
> then class B needs to be available in the ClassLoader that loaded the 
> processor's class which in turn loaded class A
> - A component developer should be able to indicate that a given 
> PropertyDescriptor represents a classpath resource and the framework should 
> take care of the ClassLoader manipulation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-2909) Provide a framework mechanism for loading additional classpath resources

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648344#comment-15648344
 ] 

ASF subversion and git services commented on NIFI-2909:
---

Commit d1d053725b72d91fbfca1a2e86691e9c9a1a3f2f in nifi's branch 
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d1d0537 ]

NIFI-2909 Adding per-instance class loading capability through 
@RequiresInstanceClassLoading annotation
NIFI-1712 Applying per-instance class loading to HBaseClientService to allow 
specifying Phoenix Client JAR

-Refactoring the ClassLoading so that every processor, controller service, and 
reporting task gets an InstanceClassLoader with a parent of the NAR 
ClassLoader, and only components with @RequiresInstanceClassLoading will make a 
copy of the NAR ClassLoader resources, and addressing some review feedback

This closes #1156


> Provide a framework mechanism for loading additional classpath resources
> 
>
> Key: NIFI-2909
> URL: https://issues.apache.org/jira/browse/NIFI-2909
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
> Fix For: 1.1.0
>
>
> We currently have several components with a property for specifying 
> additional classpath resources (DBCP connection pool, scripting processors, 
> JMS). Each of these components is responsible for handling this in its own 
> way. 
> The framework should provide a more integrated solution to make it easier for 
> component developers to deal with this scenario. Some requirements that need 
> to be met by this solution:
> - Multiple instances of the same component with different resources added to 
> the classpath and not interfering with each other (i.e. two DBCP connection 
> pools using different drivers)
> - Ability to modify the actual ClassLoader of the component to deal with 
> frameworks that use Class.forName() without passing in a ClassLoader, meaning 
> if a processor loads class A and class A calls Class.forName(classBName), 
> then class B needs to be available in the ClassLoader that loaded the 
> processor's class which in turn loaded class A
> - A component developer should be able to indicate that a given 
> PropertyDescriptor represents a classpath resource and the framework should 
> take care of the ClassLoader manipulation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NIFI-1712) HBaseClientService unable to connect when Phoenix is installed

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648345#comment-15648345
 ] 

ASF subversion and git services commented on NIFI-1712:
---

Commit d1d053725b72d91fbfca1a2e86691e9c9a1a3f2f in nifi's branch 
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d1d0537 ]

NIFI-2909 Adding per-instance class loading capability through 
@RequiresInstanceClassLoading annotation
NIFI-1712 Applying per-instance class loading to HBaseClientService to allow 
specifying Phoenix Client JAR

-Refactoring the ClassLoading so that every processor, controller service, and 
reporting task gets an InstanceClassLoader with a parent of the NAR 
ClassLoader, and only components with @RequiresInstanceClassLoading will make a 
copy of the NAR ClassLoader resources, and addressing some review feedback

This closes #1156


> HBaseClientService unable to connect when Phoenix is installed
> --
>
> Key: NIFI-1712
> URL: https://issues.apache.org/jira/browse/NIFI-1712
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.1.0
>
>
> A user reported running HDP 2.3.2 with Phoenix installed, and NiFi 0.6.0, 
> with the following error:
>   
> 2016-03-31 13:24:23,916 INFO [StandardProcessScheduler Thread-5] 
> o.a.nifi.hbase.HBase_1_1_2_ClientService 
> HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] HBase 
> Security Enabled, logging in as principal n...@hdp.supergrp.net with keytab 
> /app/env/nifi.keytab
> 2016-03-31 13:24:23,984 WARN [StandardProcessScheduler Thread-5] 
> org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library 
> for your platform... using builtin-java classes where applicable
> 2016-03-31 13:24:24,101 INFO [StandardProcessScheduler Thread-5] 
> o.a.nifi.hbase.HBase_1_1_2_ClientService 
> HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] 
> Successfully logged in as principal n...@hdp.supergrp.net with keytab 
> /app/env/nifi.keytab
> 2016-03-31 13:24:24,177 ERROR [StandardProcessScheduler Thread-5] 
> o.a.n.c.s.StandardControllerServiceNode 
> HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] Failed to 
> invoke @OnEnabled method due to java.io.IOException: 
> java.lang.reflect.InvocationTargetException
> 2016-03-31 13:24:24,182 ERROR [StandardProcessScheduler Thread-5] 
> o.a.n.c.s.StandardControllerServiceNode
> java.io.IOException: java.lang.reflect.InvocationTargetException
> at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240)
>  ~[hbase-client-1.1.2.jar:1.1.2]
> at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:218)
>  ~[hbase-client-1.1.2.jar:1.1.2]
> at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119)
>  ~[hbase-client-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService$1.run(HBase_1_1_2_ClientService.java:215)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService$1.run(HBase_1_1_2_ClientService.java:212)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.8.0_71]
> at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_71]
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1656)
>  ~[hadoop-common-2.6.2.jar:na]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService.createConnection(HBase_1_1_2_ClientService.java:212)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService.onEnabled(HBase_1_1_2_ClientService.java:161)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_71]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_71]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_71]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_71]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
>  ~[na:na]
> at 
> 

[jira] [Updated] (NIFI-1712) HBaseClientService unable to connect when Phoenix is installed

[Oleg Zhurakousky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhurakousky updated NIFI-1712:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> HBaseClientService unable to connect when Phoenix is installed
> --
>
> Key: NIFI-1712
> URL: https://issues.apache.org/jira/browse/NIFI-1712
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.1.0
>
>
> A user reported running HDP 2.3.2 with Phoenix installed, and NiFi 0.6.0, 
> with the following error:
>   
> 2016-03-31 13:24:23,916 INFO [StandardProcessScheduler Thread-5] 
> o.a.nifi.hbase.HBase_1_1_2_ClientService 
> HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] HBase 
> Security Enabled, logging in as principal n...@hdp.supergrp.net with keytab 
> /app/env/nifi.keytab
> 2016-03-31 13:24:23,984 WARN [StandardProcessScheduler Thread-5] 
> org.apache.hadoop.util.NativeCodeLoader Unable to load native-hadoop library 
> for your platform... using builtin-java classes where applicable
> 2016-03-31 13:24:24,101 INFO [StandardProcessScheduler Thread-5] 
> o.a.nifi.hbase.HBase_1_1_2_ClientService 
> HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] 
> Successfully logged in as principal n...@hdp.supergrp.net with keytab 
> /app/env/nifi.keytab
> 2016-03-31 13:24:24,177 ERROR [StandardProcessScheduler Thread-5] 
> o.a.n.c.s.StandardControllerServiceNode 
> HBase_1_1_2_ClientService[id=e7e9b2ed-d336-34be-acb4-6c8b60c735c2] Failed to 
> invoke @OnEnabled method due to java.io.IOException: 
> java.lang.reflect.InvocationTargetException
> 2016-03-31 13:24:24,182 ERROR [StandardProcessScheduler Thread-5] 
> o.a.n.c.s.StandardControllerServiceNode
> java.io.IOException: java.lang.reflect.InvocationTargetException
> at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:240)
>  ~[hbase-client-1.1.2.jar:1.1.2]
> at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:218)
>  ~[hbase-client-1.1.2.jar:1.1.2]
> at 
> org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119)
>  ~[hbase-client-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService$1.run(HBase_1_1_2_ClientService.java:215)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService$1.run(HBase_1_1_2_ClientService.java:212)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at java.security.AccessController.doPrivileged(Native Method) 
> ~[na:1.8.0_71]
> at javax.security.auth.Subject.doAs(Subject.java:422) ~[na:1.8.0_71]
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1656)
>  ~[hadoop-common-2.6.2.jar:na]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService.createConnection(HBase_1_1_2_ClientService.java:212)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at 
> org.apache.nifi.hbase.HBase_1_1_2_ClientService.onEnabled(HBase_1_1_2_ClientService.java:161)
>  ~[nifi-hbase_1_1_2-client-service-0.6.0.jar:0.6.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_71]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[na:1.8.0_71]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[na:1.8.0_71]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_71]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:137)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:125)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotations(ReflectionUtils.java:70)
>  ~[na:na]
> at 
> org.apache.nifi.util.ReflectionUtils.invokeMethodsWithAnnotation(ReflectionUtils.java:47)
>  ~[na:na]
> at 
> org.apache.nifi.controller.service.StandardControllerServiceNode$1.run(StandardControllerServiceNode.java:285)
>  ~[na:na]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_71]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_71]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_71]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.8.0_71]
> at 
> 

[jira] [Assigned] (NIFI-2890) Provenance Repository corruption

[Joe Skora (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NIFI-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joe Skora reassigned NIFI-2890:
---

Assignee: Joe Skora

> Provenance Repository corruption
> 
>
> Key: NIFI-2890
> URL: https://issues.apache.org/jira/browse/NIFI-2890
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Brandon DeVries
>Assignee: Joe Skora
>
> It looks as thought there was a ticket to address this\[1\], but it appears 
> to not have completely addressed the issue. On an 0.6.1 instance (that 
> crashed hard), I'm getting a stack trace on startup indicating a corrupt prov 
> repo. The relevant part of the stack trace (unfortunately typed by hand, so 
> forgive the inevitable typos) is:
> {quote}
> ...
> Caused By java.lang.IllegalArgumentException: No enum constant 
> org.apahe.nifi.provenance.ProvenenceEventType.
> at java.lang/.Enum.valueOf...
> at 
> org.apache.nifi.provenance.ProvenanaceEventType.valueOf(ProvenanaceEventType.java:19)
> at
> org.apache.nifi.provenance.StandardRecordReader.nextRecord(StandardRecordReader.java:284)
> at 
> org.apache.nifi.provenance.PersistentProvenanceRepository.mergeJournals(PersistentProvenanceRepository.java:1678)
>  \[2\]
> ...
> {quote}
> In 0.x HEAD, this appears to have moved a bit\[3\]. Same is true for 
> 1.x\[4\]. In both 0.x\[5\] and 1.x\[6\], code was added to check for "bad" 
> records coming from the reader, and skip them. However, this appears to only 
> address the issue if the corrupt / bad record is the *first* record coming 
> out of a reader. If it is a subsequent record, the corruption remains.
> \[1\] https://issues.apache.org/jira/browse/NIFI-803
> \[2\] 
> https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[3\] 
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1711
> \[4\] 
> https://github.com/apache/nifi/blob/rel/nifi-0.6.1/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1678
> \[5\] 
> https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1564-L1578
> \[6\] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-provenance-repository-bundle/nifi-persistent-provenance-repository/src/main/java/org/apache/nifi/provenance/PersistentProvenanceRepository.java#L1658-L1672



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)