[jira] [Commented] (MINIFI-422) Incorporate MiNiFi Java functionality as a specialized assembly of NiFI
[ https://issues.apache.org/jira/browse/MINIFI-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834573#comment-16834573 ] Joseph Percivall commented on MINIFI-422: - Hey [~aldrin], how are things going here? Taking a look at the comments in MiNiFi-494[1] and MiNFi-488[2] it appears there's progress still happening but I don't see git activity. Let me know if you want to bounce any ideas or have run into roadblocks that you could use help with. [1] https://issues.apache.org/jira/browse/MINIFI-494 [2] https://issues.apache.org/jira/browse/MINIFI-488 > Incorporate MiNiFi Java functionality as a specialized assembly of NiFI > > > Key: MINIFI-422 > URL: https://issues.apache.org/jira/browse/MINIFI-422 > Project: Apache NiFi MiNiFi > Issue Type: Task >Reporter: Aldrin Piri >Priority: Major > > At its core the Java implementation of MiNiFi has largely been a core body of > NiFi core libraries in a separate assembly with some additional extension > points, namely those of configuration (via YAML) and configuration change > listeners. > Due to working with some of the internals of NiFi that are not exactly meant > for external consumption, there has been a certain impedance with each > successive release to make use of the latest and greatest. > This ticket is to investigate and consider the incorporation of MiNiFi Java > into the NiFi code base in a manner as highlighted above, extending/adapting > the core libraries, providing some additional extension points, and then > generating a custom assembly. > The idea is that in lieu of duplicating bits of code and providing > workarounds around some of the internal APIs we can have a more streamlined > build and keep these items in lockstep with the core NiFi libraries being > more aware of changes that MiNiFi is inherently dependent upon. > To our users, there should be little perceptible change. The core means of > interaction should remain while providing a similar footprint. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFI-450) PullHttpChangeIngestor needs to properly close OkHttp response
Joseph Percivall created MINIFI-450: --- Summary: PullHttpChangeIngestor needs to properly close OkHttp response Key: MINIFI-450 URL: https://issues.apache.org/jira/browse/MINIFI-450 Project: Apache NiFi MiNiFi Issue Type: Bug Reporter: Joseph Percivall Same as NIFI-5085 and NIFI-5086, PullHttpChangeIngestor does not close the response as it should[1] [1] https://github.com/apache/nifi-minifi/blob/master/minifi-bootstrap/src/main/java/org/apache/nifi/minifi/bootstrap/configuration/ingestors/PullHttpChangeIngestor.java#L253 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFI-446) FlowStatus status queries should support accessing process groups
Joseph Percivall created MINIFI-446: --- Summary: FlowStatus status queries should support accessing process groups Key: MINIFI-446 URL: https://issues.apache.org/jira/browse/MINIFI-446 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall Process Groups were introduced in MINFI-107 and there is currently no way to get the bulletins/health/stats of the Processor group. This support should be added to the StatusConfigReporter[1] as another top-level type. [1] [https://github.com/apache/nifi-minifi/blob/master/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-framework-core/src/main/java/org/apache/nifi/minifi/status/StatusConfigReporter.java] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFI-445) FlowStatus queries does not include nested components
Joseph Percivall created MINIFI-445: --- Summary: FlowStatus queries does not include nested components Key: MINIFI-445 URL: https://issues.apache.org/jira/browse/MINIFI-445 Project: Apache NiFi MiNiFi Issue Type: Bug Affects Versions: 0.4.0, 0.3.0, 0.2.0, 0.1.0 Reporter: Joseph Percivall Querying for a processor's status that exists but is in a nested processor returns "No processor with key ". This is because FlowStatus queries were written prior to the addition of Process Group support (in MINIFI-107) and thus doesn't do a recursive search for the UUID in the nested process groups. The StatusConfigReporter[1] should be updated to recursively search for the UUID of the component. [1] https://github.com/apache/nifi-minifi/blob/master/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-framework-core/src/main/java/org/apache/nifi/minifi/status/StatusConfigReporter.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFI-441) Update Dockerfile to '0.4.0' and better align with practices set in NiFi
[ https://issues.apache.org/jira/browse/MINIFI-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381013#comment-16381013 ] Joseph Percivall commented on MINIFI-441: - Hey [~aldrin], do you by chance know which dockerfile was used and uploaded to dockerhub for 0.4.0? I'm assuming it's just what's in Github under Dockerhub with the version changed but since it's still on 0.2.0, I'm not 100%. > Update Dockerfile to '0.4.0' and better align with practices set in NiFi > > > Key: MINIFI-441 > URL: https://issues.apache.org/jira/browse/MINIFI-441 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Priority: Major > > The DockerHub Dockerfile[1] still lists 0.2.0 (even though dockerhub is up to > 0.4.0[2]). Also, it doesn't appear to follow best practices like the NiFi > Dockerfile[3] does, such as tailing the log file for exposing to the docker > log. > Lastly, there doesn't appear to be any documentation on the expected way to > pass the bootstrap.conf and config.yml files. I'm assuming that this is done > by creating a volume at the expected config location but this should be > documented since, unlike NiFi, the instance is essentially useless if a > config.yml isn't passed. > [1] > https://github.com/apache/nifi-minifi/blob/master/minifi-docker/dockerhub/Dockerfile > > [2] https://hub.docker.com/r/apache/nifi-minifi/tags/ > [3] > https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFI-441) Update Dockerfile to '0.4.0' and better align with practices set in NiFi
[ https://issues.apache.org/jira/browse/MINIFI-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-441: Summary: Update Dockerfile to '0.4.0' and better align with practices set in NiFi (was: Update Dockerfile 0.4.0 and better align with practices set in NiFi) > Update Dockerfile to '0.4.0' and better align with practices set in NiFi > > > Key: MINIFI-441 > URL: https://issues.apache.org/jira/browse/MINIFI-441 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Priority: Major > > The DockerHub Dockerfile[1] still lists 0.2.0 (even though dockerhub is up to > 0.4.0[2]). Also, it doesn't appear to follow best practices like the NiFi > Dockerfile[3] does, such as tailing the log file for exposing to the docker > log. > Lastly, there doesn't appear to be any documentation on the expected way to > pass the bootstrap.conf and config.yml files. I'm assuming that this is done > by creating a volume at the expected config location but this should be > documented since, unlike NiFi, the instance is essentially useless if a > config.yml isn't passed. > [1] > https://github.com/apache/nifi-minifi/blob/master/minifi-docker/dockerhub/Dockerfile > > [2] https://hub.docker.com/r/apache/nifi-minifi/tags/ > [3] > https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFI-441) Update Dockerfile 0.4.0 and better align with practices set in NiFi
Joseph Percivall created MINIFI-441: --- Summary: Update Dockerfile 0.4.0 and better align with practices set in NiFi Key: MINIFI-441 URL: https://issues.apache.org/jira/browse/MINIFI-441 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall The DockerHub Dockerfile[1] still lists 0.2.0 (even though dockerhub is up to 0.4.0[2]). Also, it doesn't appear to follow best practices like the NiFi Dockerfile[3] does, such as tailing the log file for exposing to the docker log. Lastly, there doesn't appear to be any documentation on the expected way to pass the bootstrap.conf and config.yml files. I'm assuming that this is done by creating a volume at the expected config location but this should be documented since, unlike NiFi, the instance is essentially useless if a config.yml isn't passed. [1] https://github.com/apache/nifi-minifi/blob/master/minifi-docker/dockerhub/Dockerfile [2] https://hub.docker.com/r/apache/nifi-minifi/tags/ [3] https://github.com/apache/nifi/blob/master/nifi-docker/dockerhub/Dockerfile -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINIFI-440) Update Admin docs online with latest version
Joseph Percivall created MINIFI-440: --- Summary: Update Admin docs online with latest version Key: MINIFI-440 URL: https://issues.apache.org/jira/browse/MINIFI-440 Project: Apache NiFi MiNiFi Issue Type: Task Reporter: Joseph Percivall Was looking at the docs online for the information about MiNiFi-216 and the nifi.properties override and noticed that it doesn't exist in the admin docs[1]. The latest System_Admin_Guide.md should be published. [1]https://nifi.apache.org/minifi/system-admin-guide.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFI-66) Migrate non-flow properties from config.yml to bootstrap
[ https://issues.apache.org/jira/browse/MINIFI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360085#comment-16360085 ] Joseph Percivall commented on MINIFI-66: Ah, I had forgotten about the design work done for the C2 protocol so far. I'll need to re-read the design page prior discussing the updating process more but I do agree that "agent" level changes would, in general, be done less. +1 on the draft doc, thanks! As for MINIFI-422, I think we would still have the same end goal but the implementation would be different. We'd just need to make sure to keep it consistent when implementing MINFI-422. > Migrate non-flow properties from config.yml to bootstrap > > > Key: MINIFI-66 > URL: https://issues.apache.org/jira/browse/MINIFI-66 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Agent Configuration/Installation, Processing > Configuration >Affects Versions: 0.0.1 >Reporter: Aldrin Piri >Assignee: Aldrin Piri >Priority: Major > > To facilitate greater ease in configuring instances, it would be helpful to > have the config.yml be a descriptor only of processing flow with the actual > instance process configuration (system properties, file locations, etc) being > migrated to something like bootstrap.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFI-66) Migrate non-flow properties from config.yml to bootstrap
[ https://issues.apache.org/jira/browse/MINIFI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358932#comment-16358932 ] Joseph Percivall commented on MINIFI-66: Thanks for the follow-up details [~aldrin], and I think we're on the same page regarding the long-term vision but a bit of disconnect in the interim. I agree that there should be some separation of the "hardware/agent" config and the flow config when looking through the lens of the Registry/higher level agent management. At that level, we can have different portions of the config that can be modified by the different roles (DFM vs. "hardware" admin) but how that makes it to the agent doesn't really matter whether it's a single file or not does it? If anything, having just one file transferred from Registry to agent would reduce complexity. --- A little bit of a disconnect when I was typing the response, I feel like I remember hearing this before, but is your envisioned goal to have a "flow.yml" and an "agent.yml" such that the "flow.yml" can be shared across all agent types while the "agent.yml" is unique for the agent type (Java vs. C++)? If so, I totally understand the want to separate the files and actually, utilizing MINIFI-424, would probably make it not too difficult to do for the java agent. We can utilize the functionality created in MINIFI-424 to populate the nifi.properties in the ConfigTransformer by having them set in the bootstrap.conf by default. Lastly, yeah, I agree that MINIFI-434 is just a stopgap while we figure out these other design decisions. Was more of a > Migrate non-flow properties from config.yml to bootstrap > > > Key: MINIFI-66 > URL: https://issues.apache.org/jira/browse/MINIFI-66 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Agent Configuration/Installation, Processing > Configuration >Affects Versions: 0.0.1 >Reporter: Aldrin Piri >Assignee: Aldrin Piri >Priority: Major > > To facilitate greater ease in configuring instances, it would be helpful to > have the config.yml be a descriptor only of processing flow with the actual > instance process configuration (system properties, file locations, etc) being > migrated to something like bootstrap.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MINIFI-66) Migrate non-flow properties from config.yml to bootstrap
[ https://issues.apache.org/jira/browse/MINIFI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358831#comment-16358831 ] Joseph Percivall edited comment on MINIFI-66 at 2/9/18 7:14 PM: [~aldrin] I may be confused (or taking an overly Java agent perspective) but I don't think this is the right direction. I would prefer we go the route of a combination of exposing the agent-specific (bootstrap) properties to the config transformer[1] and either just preserving the properties on registry update (like was done in MINFI-434[2]) or add them to the registry data model. I don't think we want to go this direction because as a user I want to be able to have the ability to change as much as possible within a warm config change as possible. With the end-goal of natively supporting having various classes of agents, if I have a bug within the "instance process configuration" of a class of agent, I don't want to have to modify it on all of them manually. Ideally, I think we'd be trying to go the other way and exposing more of the configuration that can be automatically warm re-deployed as possible. That said, is the idea to migrate the flow portion out of the config.yml to another file that is dynamically updateable? [1] https://issues.apache.org/jira/browse/MINIFI-424 [2] https://issues.apache.org/jira/browse/MINIFI-434 was (Author: jpercivall): [~aldrin] I may be confused but I don't think this is the right direction. I would prefer we go the direction of a combination of exposing the agent-specific (bootstrap) properties to the config transformer[1] and either just preserving the properties on registry update (like was done in MINFI-434[2]) or add them to the registry data model. I don't think we want to go this direction because as a user I want to be able to have the ability to change as much as possible within a warm config change as possible. With the end-goal of natively supporting having various different classes of agents, if I have a bug within the "instance process configuration" of a class of agent, I don't want to have to manually modify it on all of them. Ideally, I think we'd be trying to go the other way and exposing more of the configuration that is able to be automatically warm re-deployed as possible. That said, is the idea to migrate the flow portion out of the config.yml to another file that is dynamically updateable? [1] https://issues.apache.org/jira/browse/MINIFI-424 [2] https://issues.apache.org/jira/browse/MINIFI-434 > Migrate non-flow properties from config.yml to bootstrap > > > Key: MINIFI-66 > URL: https://issues.apache.org/jira/browse/MINIFI-66 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Agent Configuration/Installation, Processing > Configuration >Affects Versions: 0.0.1 >Reporter: Aldrin Piri >Assignee: Aldrin Piri >Priority: Major > > To facilitate greater ease in configuring instances, it would be helpful to > have the config.yml be a descriptor only of processing flow with the actual > instance process configuration (system properties, file locations, etc) being > migrated to something like bootstrap.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINIFI-66) Migrate non-flow properties from config.yml to bootstrap
[ https://issues.apache.org/jira/browse/MINIFI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358831#comment-16358831 ] Joseph Percivall commented on MINIFI-66: [~aldrin] I may be confused but I don't think this is the right direction. I would prefer we go the direction of a combination of exposing the agent-specific (bootstrap) properties to the config transformer[1] and either just preserving the properties on registry update (like was done in MINFI-434[2]) or add them to the registry data model. I don't think we want to go this direction because as a user I want to be able to have the ability to change as much as possible within a warm config change as possible. With the end-goal of natively supporting having various different classes of agents, if I have a bug within the "instance process configuration" of a class of agent, I don't want to have to manually modify it on all of them. Ideally, I think we'd be trying to go the other way and exposing more of the configuration that is able to be automatically warm re-deployed as possible. That said, is the idea to migrate the flow portion out of the config.yml to another file that is dynamically updateable? [1] https://issues.apache.org/jira/browse/MINIFI-424 [2] https://issues.apache.org/jira/browse/MINIFI-434 > Migrate non-flow properties from config.yml to bootstrap > > > Key: MINIFI-66 > URL: https://issues.apache.org/jira/browse/MINIFI-66 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Agent Configuration/Installation, Processing > Configuration >Affects Versions: 0.0.1 >Reporter: Aldrin Piri >Assignee: Aldrin Piri >Priority: Major > > To facilitate greater ease in configuring instances, it would be helpful to > have the config.yml be a descriptor only of processing flow with the actual > instance process configuration (system properties, file locations, etc) being > migrated to something like bootstrap.conf. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MINIFI-424) Expose bootstrap properties in the ConfigTransformer
[
https://issues.apache.org/jira/browse/MINIFI-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall updated MINIFI-424:
Description:
The ConfigTransformer takes in the config.yml and creates the nifi.properties
and flow.xml. In order to better support customizations on a per MiNiFi
instance for things that aren't able to reference EL, we could expose the
properties listed in the bootstrap.conf.
As an example, the bootstrap conf could have properties identifying the S2S URL
and port UUID to use. Then when MiNiFi pulls down the new config.yml it would
translate the keys to their proper values as identified in the bootstrap.conf.
The main unknown is what the "escape" identifiers would be. In EL it is "${
. }" (not sure why Jira is formatting this with new lines). This would need
to be specific enough that it doesn't collide with anything that'd be in the
config.yml.
Much further down the line, this could eventually evolve to expose ENV
variables, key/values stored in a file, and maybe even basic functions as
needed. Essentially a basic version of EL but I hesitate to call it that b/c I
don't want users to expect all of that functionality. This should really be for
things that can't be done via EL.
was:
The ConfigTransformer takes in the config.yml and creates the nifi.properties
and flow.xml. In order to better support customizations on a per MiNiFi
instance for things that aren't able to reference EL, we could expose the
properties listed in the bootstrap.conf.
As an example, the bootstrap conf could have properties identifying the S2S URL
and port UUID to use. Then when MiNiFi pulls down the new config.yml it would
translate the keys to their proper values as identified in the bootstrap.conf.
The main unknown is what the "escape" identifiers would be. In EL it is "${
. }". This would need to be specific enough that it doesn't collide with
anything that'd be in the config.yml.
Much further down the line, this could eventually evolve to expose ENV
variables, key/values stored in a file, and maybe even basic functions as
needed. Essentially a basic version of EL but I hesitate to call it that b/c I
don't want users to expect all of that functionality. This should really be for
things that can't be done via EL.
> Expose bootstrap properties in the ConfigTransformer
>
>
> Key: MINIFI-424
> URL: https://issues.apache.org/jira/browse/MINIFI-424
> Project: Apache NiFi MiNiFi
> Issue Type: New Feature
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>
> The ConfigTransformer takes in the config.yml and creates the nifi.properties
> and flow.xml. In order to better support customizations on a per MiNiFi
> instance for things that aren't able to reference EL, we could expose the
> properties listed in the bootstrap.conf.
> As an example, the bootstrap conf could have properties identifying the S2S
> URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it
> would translate the keys to their proper values as identified in the
> bootstrap.conf.
> The main unknown is what the "escape" identifiers would be. In EL it is "${
> . }" (not sure why Jira is formatting this with new lines). This would
> need to be specific enough that it doesn't collide with anything that'd be in
> the config.yml.
> Much further down the line, this could eventually evolve to expose ENV
> variables, key/values stored in a file, and maybe even basic functions as
> needed. Essentially a basic version of EL but I hesitate to call it that b/c
> I don't want users to expect all of that functionality. This should really be
> for things that can't be done via EL.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MINIFI-424) Expose bootstrap properties in the ConfigTransformer
[
https://issues.apache.org/jira/browse/MINIFI-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall updated MINIFI-424:
Description:
The ConfigTransformer takes in the config.yml and creates the nifi.properties
and flow.xml. In order to better support customizations on a per MiNiFi
instance for things that aren't able to reference EL, we could expose the
properties listed in the bootstrap.conf.
As an example, the bootstrap conf could have properties identifying the S2S URL
and port UUID to use. Then when MiNiFi pulls down the new config.yml it would
translate the keys to their proper values as identified in the bootstrap.conf.
The main unknown is what the "escape" identifiers would be. In EL it is "${
. }". This would need to be specific enough that it doesn't collide with
anything that'd be in the config.yml.
Much further down the line, this could eventually evolve to expose ENV
variables, key/values stored in a file, and maybe even basic functions as
needed. Essentially a basic version of EL but I hesitate to call it that b/c I
don't want users to expect all of that functionality. This should really be for
things that can't be done via EL.
was:
The ConfigTransformer takes in the config.yml and creates the nifi.properties
and flow.xml. In order to better support customizations on a per MiNiFi
instance for things that aren't able to reference EL, we could expose the
properties listed in the bootstrap.conf.
As an example, the bootstrap conf could have properties identifying the S2S URL
and port UUID to use. Then when MiNiFi pulls down the new config.yml it would
translate the keys to their proper values as identified in the bootstrap.conf.
The main unknown is what the "escape" identifiers would be. In EL it is
"${.}". This would need to be specific enough that it doesn't collide with
anything that'd be in the config.yml.
Much further down the line, this could eventually evolve to expose ENV
variables, key/values stored in a file, and maybe even basic functions as
needed. Essentially a basic version of EL but I hesitate to call it that b/c I
don't want users to expect all of that functionality. This should really be for
things that can't be done via EL.
> Expose bootstrap properties in the ConfigTransformer
>
>
> Key: MINIFI-424
> URL: https://issues.apache.org/jira/browse/MINIFI-424
> Project: Apache NiFi MiNiFi
> Issue Type: New Feature
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>
> The ConfigTransformer takes in the config.yml and creates the nifi.properties
> and flow.xml. In order to better support customizations on a per MiNiFi
> instance for things that aren't able to reference EL, we could expose the
> properties listed in the bootstrap.conf.
> As an example, the bootstrap conf could have properties identifying the S2S
> URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it
> would translate the keys to their proper values as identified in the
> bootstrap.conf.
> The main unknown is what the "escape" identifiers would be. In EL it is "${
> . }". This would need to be specific enough that it doesn't collide with
> anything that'd be in the config.yml.
> Much further down the line, this could eventually evolve to expose ENV
> variables, key/values stored in a file, and maybe even basic functions as
> needed. Essentially a basic version of EL but I hesitate to call it that b/c
> I don't want users to expect all of that functionality. This should really be
> for things that can't be done via EL.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MINIFI-424) Expose bootstrap properties in the ConfigTransformer
Joseph Percivall created MINIFI-424:
---
Summary: Expose bootstrap properties in the ConfigTransformer
Key: MINIFI-424
URL: https://issues.apache.org/jira/browse/MINIFI-424
Project: Apache NiFi MiNiFi
Issue Type: New Feature
Reporter: Joseph Percivall
Assignee: Joseph Percivall
The ConfigTransformer takes in the config.yml and creates the nifi.properties
and flow.xml. In order to better support customizations on a per MiNiFi
instance for things that aren't able to reference EL, we could expose the
properties listed in the bootstrap.conf.
As an example, the bootstrap conf could have properties identifying the S2S URL
and port UUID to use. Then when MiNiFi pulls down the new config.yml it would
translate the keys to their proper values as identified in the bootstrap.conf.
The main unknown is what the "escape" identifiers would be. In EL it is
"${.}". This would need to be specific enough that it doesn't collide with
anything that'd be in the config.yml.
Much further down the line, this could eventually evolve to expose ENV
variables, key/values stored in a file, and maybe even basic functions as
needed. Essentially a basic version of EL but I hesitate to call it that b/c I
don't want users to expect all of that functionality. This should really be for
things that can't be done via EL.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MINIFI-424) Expose bootstrap properties in the ConfigTransformer
[
https://issues.apache.org/jira/browse/MINIFI-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16324727#comment-16324727
]
Joseph Percivall commented on MINIFI-424:
-
Any ideas what we could use for the "escape" identifiers are welcome.
> Expose bootstrap properties in the ConfigTransformer
>
>
> Key: MINIFI-424
> URL: https://issues.apache.org/jira/browse/MINIFI-424
> Project: Apache NiFi MiNiFi
> Issue Type: New Feature
>Reporter: Joseph Percivall
>Assignee: Joseph Percivall
>
> The ConfigTransformer takes in the config.yml and creates the nifi.properties
> and flow.xml. In order to better support customizations on a per MiNiFi
> instance for things that aren't able to reference EL, we could expose the
> properties listed in the bootstrap.conf.
> As an example, the bootstrap conf could have properties identifying the S2S
> URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it
> would translate the keys to their proper values as identified in the
> bootstrap.conf.
> The main unknown is what the "escape" identifiers would be. In EL it is
> "${.}". This would need to be specific enough that it doesn't collide
> with anything that'd be in the config.yml.
> Much further down the line, this could eventually evolve to expose ENV
> variables, key/values stored in a file, and maybe even basic functions as
> needed. Essentially a basic version of EL but I hesitate to call it that b/c
> I don't want users to expect all of that functionality. This should really be
> for things that can't be done via EL.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MINIFI-422) Incorporate MiNiFi Java functionality as a specialized assembly of NiFI
[ https://issues.apache.org/jira/browse/MINIFI-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16302198#comment-16302198 ] Joseph Percivall commented on MINIFI-422: - Definitely interested in how this would pan out and I agree that it could go a long way in streamlining and promoting the MiNiFi Java development. As well as facilitating better feature parity between the two. +1 Do you foresee integrating some of the current MiNiFi specific functionality (ie. config change listeners) into core NiFi or would they stay separate? > Incorporate MiNiFi Java functionality as a specialized assembly of NiFI > > > Key: MINIFI-422 > URL: https://issues.apache.org/jira/browse/MINIFI-422 > Project: Apache NiFi MiNiFi > Issue Type: Task >Reporter: Aldrin Piri > > At its core the Java implementation of MiNiFi has largely been a core body of > NiFi core libraries in a separate assembly with some additional extension > points, namely those of configuration (via YAML) and configuration change > listeners. > Due to working with some of the internals of NiFi that are not exactly meant > for external consumption, there has been a certain impedance with each > successive release to make use of the latest and greatest. > This ticket is to investigate and consider the incorporation of MiNiFi Java > into the NiFi code base in a manner as highlighted above, extending/adapting > the core libraries, providing some additional extension points, and then > generating a custom assembly. > The idea is that in lieu of duplicating bits of code and providing > workarounds around some of the internal APIs we can have a more streamlined > build and keep these items in lockstep with the core NiFi libraries being > more aware of changes that MiNiFi is inherently dependent upon. > To our users, there should be little perceptible change. The core means of > interaction should remain while providing a similar footprint. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MINIFI-416) Integration tests fail with "Cannot start service minifi: oci runtime error"
[
https://issues.apache.org/jira/browse/MINIFI-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16289385#comment-16289385
]
Joseph Percivall commented on MINIFI-416:
-
[~jzemerick], this doesn't fail during "mvn clean install -Pcontrib-check"
because (as far as I understand) "minifi-integration-tests" is not run. When I
run "mvn -P docker clean install" it does fail.
> Integration tests fail with "Cannot start service minifi: oci runtime error"
>
>
> Key: MINIFI-416
> URL: https://issues.apache.org/jira/browse/MINIFI-416
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
>Reporter: Joseph Percivall
>
> I am attempting to run the MiNiFi integration tests and they all fail with
> the following error:
> {quote}verifyLogEntries[6: Schema Version: v2 Name:
> StressTestFramework](org.apache.nifi.minifi.integration.standalone.test.StandaloneYamlTest)
> Time elapsed: 17.289 sec <<< ERROR!
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose up -d' returned exit code 1
> The output was:
> Starting c39d2544_minifi_1 ...
> Starting c39d2544_minifi_1 ... error
> ERROR: for c39d2544_minifi_1 Cannot start service minifi: oci runtime error:
> container_linux.go:265: starting container process caused "exec: \"bash\":
> executable file not found in $PATH"
> ERROR: for minifi Cannot start service minifi: oci runtime error:
> container_linux.go:265: starting container process caused "exec: \"bash\":
> executable file not found in $PATH"
> Encountered errors while bringing up the project.
> at
> com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
> at
> com.palantir.docker.compose.execution.Command.execute(Command.java:50)
> at
> com.palantir.docker.compose.execution.DefaultDockerCompose.up(DefaultDockerCompose.java:79)
> at
> com.palantir.docker.compose.execution.DelegatingDockerCompose.up(DelegatingDockerCompose.java:45)
> at
> com.palantir.docker.compose.execution.RetryingDockerCompose.lambda$up$27(RetryingDockerCompose.java:37)
> at
> com.palantir.docker.compose.execution.Retryer.runWithRetries(Retryer.java:44)
> at
> com.palantir.docker.compose.execution.RetryingDockerCompose.up(RetryingDockerCompose.java:36)
> at
> com.palantir.docker.compose.execution.ConflictingContainerRemovingDockerCompose.up(ConflictingContainerRemovingDockerCompose.java:51)
> at
> com.palantir.docker.compose.DockerComposeRule.before(DockerComposeRule.java:149)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {quote}
> I am able to run all the other tests just fine. I'm running the RC-1 for
> 0.3.0.
> On one hand, I'm not convinced that it's not something local on
[jira] [Created] (MINIFI-417) Upgrade to NiFi 1.4.0 dependencies
Joseph Percivall created MINIFI-417: --- Summary: Upgrade to NiFi 1.4.0 dependencies Key: MINIFI-417 URL: https://issues.apache.org/jira/browse/MINIFI-417 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall Assignee: Joseph Percivall Currently, MiNiFi Java uses the 1.2.0 release of NiFi under the hood. This means it is not benefitting from the improvements in processors and other components MiNiFi inherits from core NiFi that came in 1.3.0 or 1.4.0. As pointed out by [~joewitt] here[1], there is a sizeable amount of work to keep up with the versions and potentially other options for us to explore but the interim we should at least try to keep up with NiFi. [1] https://issues.apache.org/jira/browse/MINIFI-255?focusedCommentId=16003969=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16003969 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MINIFI-416) Integration tests fail with "Cannot start service minifi: oci runtime error"
[
https://issues.apache.org/jira/browse/MINIFI-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288720#comment-16288720
]
Joseph Percivall commented on MINIFI-416:
-
This is more than likely due to the change to use Apline Linux as the base
image: https://issues.apache.org/jira/browse/MINIFI-310
> Integration tests fail with "Cannot start service minifi: oci runtime error"
>
>
> Key: MINIFI-416
> URL: https://issues.apache.org/jira/browse/MINIFI-416
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
>Reporter: Joseph Percivall
>
> I am attempting to run the MiNiFi integration tests and they all fail with
> the following error:
> {quote}verifyLogEntries[6: Schema Version: v2 Name:
> StressTestFramework](org.apache.nifi.minifi.integration.standalone.test.StandaloneYamlTest)
> Time elapsed: 17.289 sec <<< ERROR!
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose up -d' returned exit code 1
> The output was:
> Starting c39d2544_minifi_1 ...
> Starting c39d2544_minifi_1 ... error
> ERROR: for c39d2544_minifi_1 Cannot start service minifi: oci runtime error:
> container_linux.go:265: starting container process caused "exec: \"bash\":
> executable file not found in $PATH"
> ERROR: for minifi Cannot start service minifi: oci runtime error:
> container_linux.go:265: starting container process caused "exec: \"bash\":
> executable file not found in $PATH"
> Encountered errors while bringing up the project.
> at
> com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
> at
> com.palantir.docker.compose.execution.Command.execute(Command.java:50)
> at
> com.palantir.docker.compose.execution.DefaultDockerCompose.up(DefaultDockerCompose.java:79)
> at
> com.palantir.docker.compose.execution.DelegatingDockerCompose.up(DelegatingDockerCompose.java:45)
> at
> com.palantir.docker.compose.execution.RetryingDockerCompose.lambda$up$27(RetryingDockerCompose.java:37)
> at
> com.palantir.docker.compose.execution.Retryer.runWithRetries(Retryer.java:44)
> at
> com.palantir.docker.compose.execution.RetryingDockerCompose.up(RetryingDockerCompose.java:36)
> at
> com.palantir.docker.compose.execution.ConflictingContainerRemovingDockerCompose.up(ConflictingContainerRemovingDockerCompose.java:51)
> at
> com.palantir.docker.compose.DockerComposeRule.before(DockerComposeRule.java:149)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {quote}
> I am able to run all the other tests just fine. I'm running the RC-1 for
> 0.3.0.
> On one hand, I'm not convinced that it's not something local on my end since
> all the tests are failing. On the other, I see a similar
[jira] [Commented] (MINIFI-416) Integration tests fail with "Cannot start service minifi: oci runtime error"
[
https://issues.apache.org/jira/browse/MINIFI-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16288716#comment-16288716
]
Joseph Percivall commented on MINIFI-416:
-
Note that these tests pass for me using 0.2.0 so I do believe there is an issue
with the docker file for 0.3.0-RC1
> Integration tests fail with "Cannot start service minifi: oci runtime error"
>
>
> Key: MINIFI-416
> URL: https://issues.apache.org/jira/browse/MINIFI-416
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
>Reporter: Joseph Percivall
>
> I am attempting to run the MiNiFi integration tests and they all fail with
> the following error:
> {quote}verifyLogEntries[6: Schema Version: v2 Name:
> StressTestFramework](org.apache.nifi.minifi.integration.standalone.test.StandaloneYamlTest)
> Time elapsed: 17.289 sec <<< ERROR!
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose up -d' returned exit code 1
> The output was:
> Starting c39d2544_minifi_1 ...
> Starting c39d2544_minifi_1 ... error
> ERROR: for c39d2544_minifi_1 Cannot start service minifi: oci runtime error:
> container_linux.go:265: starting container process caused "exec: \"bash\":
> executable file not found in $PATH"
> ERROR: for minifi Cannot start service minifi: oci runtime error:
> container_linux.go:265: starting container process caused "exec: \"bash\":
> executable file not found in $PATH"
> Encountered errors while bringing up the project.
> at
> com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
> at
> com.palantir.docker.compose.execution.Command.execute(Command.java:50)
> at
> com.palantir.docker.compose.execution.DefaultDockerCompose.up(DefaultDockerCompose.java:79)
> at
> com.palantir.docker.compose.execution.DelegatingDockerCompose.up(DelegatingDockerCompose.java:45)
> at
> com.palantir.docker.compose.execution.RetryingDockerCompose.lambda$up$27(RetryingDockerCompose.java:37)
> at
> com.palantir.docker.compose.execution.Retryer.runWithRetries(Retryer.java:44)
> at
> com.palantir.docker.compose.execution.RetryingDockerCompose.up(RetryingDockerCompose.java:36)
> at
> com.palantir.docker.compose.execution.ConflictingContainerRemovingDockerCompose.up(ConflictingContainerRemovingDockerCompose.java:51)
> at
> com.palantir.docker.compose.DockerComposeRule.before(DockerComposeRule.java:149)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {quote}
> I am able to run all the other tests just fine. I'm running the RC-1 for
> 0.3.0.
> On one hand, I'm not convinced that it's not something local on my end since
> all the tests are failing. On the other, I see a similar error here[1]
[jira] [Created] (MINIFI-416) Integration tests fail with "Cannot start service minifi: oci runtime error"
Joseph Percivall created MINIFI-416:
---
Summary: Integration tests fail with "Cannot start service minifi:
oci runtime error"
Key: MINIFI-416
URL: https://issues.apache.org/jira/browse/MINIFI-416
Project: Apache NiFi MiNiFi
Issue Type: Bug
Reporter: Joseph Percivall
I am attempting to run the MiNiFi integration tests and they all fail with the
following error:
{quote}verifyLogEntries[6: Schema Version: v2 Name:
StressTestFramework](org.apache.nifi.minifi.integration.standalone.test.StandaloneYamlTest)
Time elapsed: 17.289 sec <<< ERROR!
com.palantir.docker.compose.execution.DockerExecutionException: 'docker-compose
up -d' returned exit code 1
The output was:
Starting c39d2544_minifi_1 ...
Starting c39d2544_minifi_1 ... error
ERROR: for c39d2544_minifi_1 Cannot start service minifi: oci runtime error:
container_linux.go:265: starting container process caused "exec: \"bash\":
executable file not found in $PATH"
ERROR: for minifi Cannot start service minifi: oci runtime error:
container_linux.go:265: starting container process caused "exec: \"bash\":
executable file not found in $PATH"
Encountered errors while bringing up the project.
at
com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
at
com.palantir.docker.compose.execution.Command.execute(Command.java:50)
at
com.palantir.docker.compose.execution.DefaultDockerCompose.up(DefaultDockerCompose.java:79)
at
com.palantir.docker.compose.execution.DelegatingDockerCompose.up(DelegatingDockerCompose.java:45)
at
com.palantir.docker.compose.execution.RetryingDockerCompose.lambda$up$27(RetryingDockerCompose.java:37)
at
com.palantir.docker.compose.execution.Retryer.runWithRetries(Retryer.java:44)
at
com.palantir.docker.compose.execution.RetryingDockerCompose.up(RetryingDockerCompose.java:36)
at
com.palantir.docker.compose.execution.ConflictingContainerRemovingDockerCompose.up(ConflictingContainerRemovingDockerCompose.java:51)
at
com.palantir.docker.compose.DockerComposeRule.before(DockerComposeRule.java:149)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
{quote}
I am able to run all the other tests just fine. I'm running the RC-1 for 0.3.0.
On one hand, I'm not convinced that it's not something local on my end since
all the tests are failing. On the other, I see a similar error here[1] and
that's supposedly due to the base layer not having any tooling.
A complete output of all the tests failing:
{quote}Tests in error:
HierarchicalC2IntegrationTest.initCertificates:94 » DockerExecution
'docker-co...
StandaloneXmlTest.verifyLogEntries[0: Schema Version: v1 Name: CsvToJson] »
DockerExecution
StandaloneXmlTest.verifyLogEntries[1: Schema Version: v1 Name:
DecompressionCircularFlow] »
[jira] [Updated] (MINIFI-184) Add Security Support
[ https://issues.apache.org/jira/browse/MINIFI-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-184: Issue Type: Improvement (was: Bug) > Add Security Support > > > Key: MINIFI-184 > URL: https://issues.apache.org/jira/browse/MINIFI-184 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: cpp-0.2.0 >Reporter: bqiu >Assignee: bqiu > Fix For: cpp-0.2.0 > > > Add Security Support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-173) Upgrade to logback 1.1.9 when available
[ https://issues.apache.org/jira/browse/MINIFI-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-173: Description: Due to this regression[1] in 1.1.8, the logback logs are printed to the command line when using SizeAndTimeBasedRollingPolicy and we use SizeAndTimeBasedRollingPolicy in our default config. http://jira.qos.ch/projects/LOGBACK/versions/11410 [1] http://jira.qos.ch/browse/LOGBACK-1236 was: Due to this regression[1] in 1.1.8, the logback logs are printed to the command line when using SizeAndTimeBasedRollingPolicy and we use SizeAndTimeBasedRollingPolicy in our default config. [1] http://jira.qos.ch/browse/LOGBACK-1236 > Upgrade to logback 1.1.9 when available > --- > > Key: MINIFI-173 > URL: https://issues.apache.org/jira/browse/MINIFI-173 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Joseph Percivall > > Due to this regression[1] in 1.1.8, the logback logs are printed to the > command line when using SizeAndTimeBasedRollingPolicy and we use > SizeAndTimeBasedRollingPolicy in our default config. > http://jira.qos.ch/projects/LOGBACK/versions/11410 > [1] http://jira.qos.ch/browse/LOGBACK-1236 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-173) Upgrade to logback 1.1.9 when available
Joseph Percivall created MINIFI-173: --- Summary: Upgrade to logback 1.1.9 when available Key: MINIFI-173 URL: https://issues.apache.org/jira/browse/MINIFI-173 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall Due to this regression[1] in 1.1.8, the logback logs are printed to the command line when using SizeAndTimeBasedRollingPolicy and we use SizeAndTimeBasedRollingPolicy in our default config. [1] http://jira.qos.ch/browse/LOGBACK-1236 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-172) "NIFI_VERSION" variable in ConfigTransformer is still set to 1.0.0
Joseph Percivall created MINIFI-172: --- Summary: "NIFI_VERSION" variable in ConfigTransformer is still set to 1.0.0 Key: MINIFI-172 URL: https://issues.apache.org/jira/browse/MINIFI-172 Project: Apache NiFi MiNiFi Issue Type: Bug Affects Versions: 0.1.0 Reporter: Joseph Percivall Assignee: Joseph Percivall Priority: Trivial When updating the underlying dependencies to nifi-1.1.0, the variable in ConfigTransformer[1] wasn't updated [1] https://github.com/apache/nifi-minifi/blob/94869042fdfeec21d0fbcc4b4c18886464972b05/minifi-bootstrap/src/main/java/org/apache/nifi/minifi/bootstrap/util/ConfigTransformer.java#L83-L83 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MINIFI-144) Upgrade logback to 1.1.8
[ https://issues.apache.org/jira/browse/MINIFI-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned MINIFI-144: --- Assignee: Joseph Percivall > Upgrade logback to 1.1.8 > > > Key: MINIFI-144 > URL: https://issues.apache.org/jira/browse/MINIFI-144 > Project: Apache NiFi MiNiFi > Issue Type: Task > Components: Core Framework >Affects Versions: 0.1.0 >Reporter: Aldrin Piri >Assignee: Joseph Percivall >Priority: Minor > > Logback currently has a bug that prevents the totalSizeCap property from > working properly. While this has been addressed it has yet to be released. > This ticket is to track that such that we can make use of the property once > that release happens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-153) Provide configuration of HTTP Site to Site proxy properties in YAML
[ https://issues.apache.org/jira/browse/MINIFI-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-153. - Resolution: Fixed > Provide configuration of HTTP Site to Site proxy properties in YAML > --- > > Key: MINIFI-153 > URL: https://issues.apache.org/jira/browse/MINIFI-153 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > In order to support site to site with HTTP over proxy server, the proxy > properties will need to be added to the Remote Process Group Schema. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-155) MQTT nar skipped due to warning: "Unable to resolve required dependency 'nifi-standard-services-api-nar'.
[ https://issues.apache.org/jira/browse/MINIFI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-155. - Resolution: Fixed Assignee: Joseph Percivall While resolving MINIFI-154[1] dependencies were moved around a bit and now there is no "minifi-standard-services-api-nar" and instead we import "nifi-standard-services-api-nar" directly. This should no longer be an issue. [1] https://issues.apache.org/jira/browse/MINIFI-154 > MQTT nar skipped due to warning: "Unable to resolve required dependency > 'nifi-standard-services-api-nar'. > - > > Key: MINIFI-155 > URL: https://issues.apache.org/jira/browse/MINIFI-155 > Project: Apache NiFi MiNiFi > Issue Type: Bug > Components: Core Framework >Affects Versions: 0.1.0 >Reporter: Andrew Lim >Assignee: Joseph Percivall > > I wanted to run flow that used PublishMQTT, a processor not shipped with > MiNiFi. > I copied the nifi-mqtt-nar-1.1.0.nar into the MiNiFi lib directory, but when > I start MiNiFi, there is a problem with the nars not liking changing > "nifi-standard-services-api-nar" to "minifi-standard-services-api-nar", > specifically: > 2016-12-05 14:11:52,857 WARN [main] org.apache.nifi.nar.NarClassLoaders > Unable to resolve required dependency 'nifi-standard-services-api-nar'. > Skipping NAR > /Users/andrewmlim/Snapshots/minifi-0.1.0/./work/nar/extensions/nifi-mqtt-nar-1.1.0-SNAPSHOT.nar-unpacked > Workaround: If I drop "nifi-standard-services-api-nar" into the lib dir, the > flow works fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-154) Support configuration/creating of Controller Services other than SSL Context Service
Joseph Percivall created MINIFI-154: --- Summary: Support configuration/creating of Controller Services other than SSL Context Service Key: MINIFI-154 URL: https://issues.apache.org/jira/browse/MINIFI-154 Project: Apache NiFi MiNiFi Issue Type: New Feature Reporter: Joseph Percivall Assignee: Joseph Percivall In order to continue towards feature parity with NiFi, MiNiFi-java should support configuring/creating any Controller Services that may be needed. Currently only SSL Context Service is able to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-143) Class Not Found Exception when running on Windows 8
Joseph Percivall created MINIFI-143:
---
Summary: Class Not Found Exception when running on Windows 8
Key: MINIFI-143
URL: https://issues.apache.org/jira/browse/MINIFI-143
Project: Apache NiFi MiNiFi
Issue Type: Bug
Reporter: Joseph Percivall
Fix For: 0.1.0
When executing run-minifi.bat script on Windows 8 I run into this exception:
{code}
C:\nifi-minifi\minifi-assembly\target\minifi-0.1.0-SNAPSHOT-bin\minifi-0.1.0-SNA
PSHOT\bin>run-minifi.bat
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/Logger
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544
)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: org.slf4j.Logger
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MINIFI-125) Implement applicable NiFi 1.0.0 bootstrap changes to MiNiFi bootstrap
[ https://issues.apache.org/jira/browse/MINIFI-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned MINIFI-125: --- Assignee: Joseph Percivall > Implement applicable NiFi 1.0.0 bootstrap changes to MiNiFi bootstrap > - > > Key: MINIFI-125 > URL: https://issues.apache.org/jira/browse/MINIFI-125 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 0.1.0 > > > There were commits improving the NiFi-bootstrap in 1.0.0. Not all of them > will be relevant to the MiNiFi bootstrap but some may be. Any applicable > changes/improvements should be applied to the MiNiFi Bootstrap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-137) Provide configuration of HTTP Site to Site properties in YAML
[ https://issues.apache.org/jira/browse/MINIFI-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-137: Fix Version/s: 0.1.0 > Provide configuration of HTTP Site to Site properties in YAML > - > > Key: MINIFI-137 > URL: https://issues.apache.org/jira/browse/MINIFI-137 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Processing Configuration >Reporter: Aldrin Piri >Assignee: Joseph Percivall > Fix For: 0.1.0 > > > With the upgrade to the NiFi 1.x API, we should be able to make use of the > HTTP Site to Site functionality. This would require some additional handling > of the configuration file such that we could enable this within MiNiFi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MINIFI-137) Provide configuration of HTTP Site to Site properties in YAML
[ https://issues.apache.org/jira/browse/MINIFI-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned MINIFI-137: --- Assignee: Joseph Percivall > Provide configuration of HTTP Site to Site properties in YAML > - > > Key: MINIFI-137 > URL: https://issues.apache.org/jira/browse/MINIFI-137 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: Processing Configuration >Reporter: Aldrin Piri >Assignee: Joseph Percivall > > With the upgrade to the NiFi 1.x API, we should be able to make use of the > HTTP Site to Site functionality. This would require some additional handling > of the configuration file such that we could enable this within MiNiFi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-136) Error messages in minifi-bootstrap.log
[
https://issues.apache.org/jira/browse/MINIFI-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall resolved MINIFI-136.
-
Resolution: Fixed
Fix Version/s: 0.1.0
> Error messages in minifi-bootstrap.log
> --
>
> Key: MINIFI-136
> URL: https://issues.apache.org/jira/browse/MINIFI-136
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
>Reporter: Bryan Rosander
>Assignee: Bryan Rosander
> Fix For: 0.1.0
>
>
> After the Funnel support was added to MiNiFi (MINIFI-47) there are now error
> messages showing up in the bootstrap log with certain templates:
> 2016-11-09 19:25:48,650 ERROR [MiNiFi logging handler]
> org.apache.nifi.minifi.StdErr [Error] :119:13: cvc-complex-type.2.4.a:
> Invalid content was found starting with element 'funnel'. One of
> '{remoteProcessGroup, connection}' is expected.
> 2016-11-09 19:25:48,681 ERROR [MiNiFi logging handler]
> org.apache.nifi.minifi.StdErr [Error] :119:13: cvc-complex-type.2.4.a:
> Invalid content was found starting with element 'funnel'. One of
> '{remoteProcessGroup, connection}' is expected.
> 2016-11-09 19:25:48,705 ERROR [MiNiFi logging handler]
> org.apache.nifi.minifi.StdErr [Error] :119:13: cvc-complex-type.2.4.a:
> Invalid content was found starting with element 'funnel'. One of
> '{remoteProcessGroup, connection}' is expected.
> 2016-11-09 19:25:48,719 ERROR [MiNiFi logging handler]
> org.apache.nifi.minifi.StdErr [Error] :119:13: cvc-complex-type.2.4.a:
> Invalid content was found starting with element 'funnel'. One of
> '{remoteProcessGroup, connection}' is expected.
> This is due to the deserializer being picky about the order of elements in
> the XML.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MINIFI-47) Funnel connections should be supported
[ https://issues.apache.org/jira/browse/MINIFI-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-47. Resolution: Fixed > Funnel connections should be supported > -- > > Key: MINIFI-47 > URL: https://issues.apache.org/jira/browse/MINIFI-47 > Project: Apache NiFi MiNiFi > Issue Type: New Feature >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > Funnel connections help flow designers to combine output from many different > processors into one connection. We should support this in MiNiFi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-135) Remove "Input Port" and "Output Port" from default config root level
Joseph Percivall created MINIFI-135: --- Summary: Remove "Input Port" and "Output Port" from default config root level Key: MINIFI-135 URL: https://issues.apache.org/jira/browse/MINIFI-135 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall Assignee: Joseph Percivall Priority: Trivial Fix For: 0.1.0 Currently Input/Output ports are supported as components but only internally as I/O to Process Groups. They are not supported on the root level as external facing ports. Currently the default config.yml is pre-populated with an empty list of "Input Ports" and "Output Ports" in the root level. Those should be removed so that it is not confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-134) Remove "test" scope from root pom Commons-IO
Joseph Percivall created MINIFI-134: --- Summary: Remove "test" scope from root pom Commons-IO Key: MINIFI-134 URL: https://issues.apache.org/jira/browse/MINIFI-134 Project: Apache NiFi MiNiFi Issue Type: Bug Affects Versions: 0.0.1 Reporter: Joseph Percivall Priority: Blocker Fix For: 0.1.0 Commons-IO being "test" scope in the root level pom overrides any transitive deps that utilize Commons-IO. This leads to "ClassNotFound" exceptions when it would be attempted to use. For example when ListenTCP hits the max connections it attempts to use Commons-IO and it throws "ClassNotFound". "test" should be removed. 2016-11-09 16:49:47,484 WARN [org.apache.nifi.processors.standard.ListenTCP [ListenTCP]] o.a.nifi.processors.standard.ListenTCP ListenTCP[id=ListenTCP] Rejecting connection from /127.0.0.1:41866 because max connections has been met 2016-11-09 16:49:47,487 ERROR [org.apache.nifi.processors.standard.ListenTCP [ListenTCP]] org.apache.nifi.minifi.MiNiFi An Unknown Error Occurred in Thread Thread[org.apache.nifi.processors.standard.ListenTCP [ListenTCP],5,main]: java.lang.NoClassDefFoundError: org/apache/commons/io/IOUtils 2016-11-09 16:49:47,494 ERROR [org.apache.nifi.processors.standard.ListenTCP [ListenTCP]] org.apache.nifi.minifi.MiNiFi java.lang.NoClassDefFoundError: org/apache/commons/io/IOUtils at org.apache.nifi.processor.util.listen.dispatcher.SocketChannelDispatcher.run(SocketChannelDispatcher.java:154) ~[nifi-processor-utils-0.6.1.jar:0.6.1] at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_65] Caused by: java.lang.ClassNotFoundException: org.apache.commons.io.IOUtils at java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[na:1.8.0_65] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_65] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) ~[na:1.8.0_65] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_65] ... 2 common frames omitted -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-28) Configurable Status Reporting Mechanism
[ https://issues.apache.org/jira/browse/MINIFI-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-28. Resolution: Fixed Fix Version/s: 0.1.0 > Configurable Status Reporting Mechanism > --- > > Key: MINIFI-28 > URL: https://issues.apache.org/jira/browse/MINIFI-28 > Project: Apache NiFi MiNiFi > Issue Type: New Feature >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 0.1.0 > > > Currently the only way to get information related to the status of the MiNiFi > flow is to access the UI or see errors in the app log. In the near future > (MINIFI-22) the UI will be removed and there will be no way to see the > general status of the flow. > Going forward there needs to be a Status Reporter interface with various > implementations to report the status of the MiNiFi instance in a configurable > manner. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-117) Maintainable Configuration Versioning
[ https://issues.apache.org/jira/browse/MINIFI-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-117. - Resolution: Fixed > Maintainable Configuration Versioning > - > > Key: MINIFI-117 > URL: https://issues.apache.org/jira/browse/MINIFI-117 > Project: Apache NiFi MiNiFi > Issue Type: Bug >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > In order to avoid a tangled web of if/else statements around every possible > permutation of config.yml and an equally complicated validation routine, we > need to utilize a versioning strategy that allows for specific parsing and > validation code for each version of the ConfigSchema. > This will allow us to determine if a schema will be compatible with an older > MiNiFi instance more easily by validating the structure of the file at a > given version while still supporting an upconvert on read to the latest > ConfigSchema while parsing at runtime. > It should also facilitate a deprecation strategy of removing older versions' > classes without needing to touch current implementation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-60) Remove clean up default minifi-resources
[ https://issues.apache.org/jira/browse/MINIFI-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-60. Resolution: Fixed > Remove clean up default minifi-resources > - > > Key: MINIFI-60 > URL: https://issues.apache.org/jira/browse/MINIFI-60 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Affects Versions: 0.0.1 >Reporter: Joseph Percivall >Assignee: Aldrin Piri >Priority: Minor > Fix For: 0.1.0 > > > In the minifi-resources module there are a number of files that are either > not used at all or replaced when the service starts (nifi.properties and > flow.xml.gz). The erroneous files should be removed. > https://github.com/apache/nifi-minifi/tree/master/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-resources/src/main/resources/conf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-126) Reduce JVM default size
Joseph Percivall created MINIFI-126: --- Summary: Reduce JVM default size Key: MINIFI-126 URL: https://issues.apache.org/jira/browse/MINIFI-126 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall Fix For: 0.1.0 MiNiFi currently still has the default NiFi size for the JVM[1]. This should be adjusted to be smaller (256mb?) so that it can run on target hardware by default. Specifically the Raspberry Pi Zero[1] will fail to start due to it only having 512mb of RAM total. [1] https://github.com/apache/nifi-minifi/blob/master/minifi-assembly/pom.xml#L233 [2] https://www.raspberrypi.org/products/pi-zero/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-125) Implement applicable NiFi 1.0.0 bootstrap changes to MiNiFi bootstrap
Joseph Percivall created MINIFI-125: --- Summary: Implement applicable NiFi 1.0.0 bootstrap changes to MiNiFi bootstrap Key: MINIFI-125 URL: https://issues.apache.org/jira/browse/MINIFI-125 Project: Apache NiFi MiNiFi Issue Type: Improvement Reporter: Joseph Percivall Fix For: 0.1.0 There were commits improving the NiFi-bootstrap in 1.0.0. Not all of them will be relevant to the MiNiFi bootstrap but some may be. Any applicable changes/improvements should be applied to the MiNiFi Bootstrap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-109) Add ExecuteProcess processor
[ https://issues.apache.org/jira/browse/MINIFI-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-109: Affects Version/s: (was: cpp-1.0.0) > Add ExecuteProcess processor > > > Key: MINIFI-109 > URL: https://issues.apache.org/jira/browse/MINIFI-109 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: C++ >Reporter: bqiu >Assignee: bqiu >Priority: Minor > Fix For: cpp-0.1.0 > > > Add ExecuteProcess processor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-120) RestChangeNotifier fails to instantiate due to missing dependencies
Joseph Percivall created MINIFI-120: --- Summary: RestChangeNotifier fails to instantiate due to missing dependencies Key: MINIFI-120 URL: https://issues.apache.org/jira/browse/MINIFI-120 Project: Apache NiFi MiNiFi Issue Type: Bug Affects Versions: 0.0.1 Reporter: Joseph Percivall Assignee: Joseph Percivall Priority: Critical Currently the RestChangeNotifier cannot be used because there are multiple dependencies missing from the lib/bootstrap folder. This is due to this commit[1]. NiFi-Framework-Core was properly removed as a dependency of MiNiFi-Bootstrap but NiFi-Framework-Core brought in many Jetty deps that allowed the RestChangeNotifier to work. The necessary ones need to be added back. [1] https://github.com/apache/nifi-minifi/commit/998205199fe1aae8396bbd18952840ae9e70c4db#diff-c346ba8457b89db5d90ab8207dd3301cL78 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-46) MiNiFi Connections Should be able to handle multiple selected relationships
[ https://issues.apache.org/jira/browse/MINIFI-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-46. Resolution: Fixed > MiNiFi Connections Should be able to handle multiple selected relationships > --- > > Key: MINIFI-46 > URL: https://issues.apache.org/jira/browse/MINIFI-46 > Project: Apache NiFi MiNiFi > Issue Type: New Feature >Reporter: Bryan Rosander >Assignee: Bryan Rosander > > In NiFi you can select that multiple relationships from a Processor are sent > via the same connection to another processor. That functionality helps keep > the flow design clean and should be supported by MiNiFi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MINIFI-15) Create Config Format, Documentation and Transformer
[ https://issues.apache.org/jira/browse/MINIFI-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned MINIFI-15: -- Assignee: Joseph Percivall > Create Config Format, Documentation and Transformer > --- > > Key: MINIFI-15 > URL: https://issues.apache.org/jira/browse/MINIFI-15 > Project: Apache NiFi MiNiFi > Issue Type: Sub-task > Components: Processing Configuration >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 0.0.1 > > > To configure MiNiFi there needs to be a standard format for sending > information to the config change listeners. This needs to be fleshed out and > documented. > Also there should be a config transformer to facilitate going from the config > file to nifi.properties and flow.xml.gz. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-81) Adjust usage information for minifi-toolkit executable
[ https://issues.apache.org/jira/browse/MINIFI-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-81: --- Fix Version/s: 0.1.0 > Adjust usage information for minifi-toolkit executable > -- > > Key: MINIFI-81 > URL: https://issues.apache.org/jira/browse/MINIFI-81 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: utilities >Affects Versions: 0.0.1 >Reporter: Aldrin Piri >Assignee: Joseph Percivall >Priority: Minor > Fix For: 0.1.0 > > > Currently the usage information is derived from the underlying Java class. > This is more verbose than needed and should be handled by the wrapping script > invoking that command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MINIFI-81) Adjust usage information for minifi-toolkit executable
[ https://issues.apache.org/jira/browse/MINIFI-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned MINIFI-81: -- Assignee: Joseph Percivall > Adjust usage information for minifi-toolkit executable > -- > > Key: MINIFI-81 > URL: https://issues.apache.org/jira/browse/MINIFI-81 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: utilities >Affects Versions: 0.0.1 >Reporter: Aldrin Piri >Assignee: Joseph Percivall >Priority: Minor > > Currently the usage information is derived from the underlying Java class. > This is more verbose than needed and should be handled by the wrapping script > invoking that command. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-64) Create mapping of C++ components/extensions to those in Java
[ https://issues.apache.org/jira/browse/MINIFI-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-64: --- Component/s: C++ > Create mapping of C++ components/extensions to those in Java > > > Key: MINIFI-64 > URL: https://issues.apache.org/jira/browse/MINIFI-64 > Project: Apache NiFi MiNiFi > Issue Type: Improvement > Components: C++, Processing Configuration >Reporter: Aldrin Piri >Assignee: Aldrin Piri > > To support a common configuration format, a mapping of those components that > are compatible with C++ components is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-59) CRON support Quartz dependency is missing
[
https://issues.apache.org/jira/browse/MINIFI-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall updated MINIFI-59:
---
Fix Version/s: 0.1.0
> CRON support Quartz dependency is missing
> -
>
> Key: MINIFI-59
> URL: https://issues.apache.org/jira/browse/MINIFI-59
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Joseph Percivall
> Fix For: 0.1.0
>
>
> From the mailing list:
> {quote}
> CRON driven support
> It seems to me that CRON driven processors are not supported (following
> stack trace when running MiNiFi with a template with a CRON driven
> processor):
> 2016-07-09 15:18:08,492 ERROR [main] org.apache.nifi.minifi.MiNiFi Failure
> to launch MiNiFi due to java.lang.NoClassDefFoundError:
> org/quartz/CronExpression
> java.lang.NoClassDefFoundError: org/quartz/CronExpression
> at
> org.apache.nifi.controller.StandardProcessorNode.setScheduldingPeriod(StandardProcessorNode.java:446)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.updateProcessor(StandardFlowSynchronizer.java:721)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.addProcessGroup(StandardFlowSynchronizer.java:776)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:271)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1287)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:72)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:629)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:479)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at org.apache.nifi.minifi.MiNiFiServer.start(MiNiFiServer.java:75)
> ~[minifi-framework-core-0.0.1.jar:0.0.1]
> at org.apache.nifi.minifi.MiNiFi.(MiNiFi.java:134)
> ~[minifi-runtime-0.0.1.jar:0.0.1]
> at org.apache.nifi.minifi.MiNiFi.main(MiNiFi.java:233)
> ~[minifi-runtime-0.0.1.jar:0.0.1]
> Caused by: java.lang.ClassNotFoundException: org.quartz.CronExpression
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_74]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_74]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[na:1.8.0_74]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_74]
> ... 11 common frames omitted
> If it is expected, it'd be nice to have a warning while converting
> templates.
> {quote}
> I feel CRON support is an important one, and in maintaining some of the
> simpler functionalities that are in NiFi, think should also be available in
> MiNiFi.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MINIFI-59) CRON support Quartz dependency is missing
[
https://issues.apache.org/jira/browse/MINIFI-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall reassigned MINIFI-59:
--
Assignee: Joseph Percivall (was: Aldrin Piri)
> CRON support Quartz dependency is missing
> -
>
> Key: MINIFI-59
> URL: https://issues.apache.org/jira/browse/MINIFI-59
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Pierre Villard
>Assignee: Joseph Percivall
>
> From the mailing list:
> {quote}
> CRON driven support
> It seems to me that CRON driven processors are not supported (following
> stack trace when running MiNiFi with a template with a CRON driven
> processor):
> 2016-07-09 15:18:08,492 ERROR [main] org.apache.nifi.minifi.MiNiFi Failure
> to launch MiNiFi due to java.lang.NoClassDefFoundError:
> org/quartz/CronExpression
> java.lang.NoClassDefFoundError: org/quartz/CronExpression
> at
> org.apache.nifi.controller.StandardProcessorNode.setScheduldingPeriod(StandardProcessorNode.java:446)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.updateProcessor(StandardFlowSynchronizer.java:721)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.addProcessGroup(StandardFlowSynchronizer.java:776)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:271)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1287)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:72)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:629)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at
> org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:479)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> at org.apache.nifi.minifi.MiNiFiServer.start(MiNiFiServer.java:75)
> ~[minifi-framework-core-0.0.1.jar:0.0.1]
> at org.apache.nifi.minifi.MiNiFi.(MiNiFi.java:134)
> ~[minifi-runtime-0.0.1.jar:0.0.1]
> at org.apache.nifi.minifi.MiNiFi.main(MiNiFi.java:233)
> ~[minifi-runtime-0.0.1.jar:0.0.1]
> Caused by: java.lang.ClassNotFoundException: org.quartz.CronExpression
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_74]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_74]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[na:1.8.0_74]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_74]
> ... 11 common frames omitted
> If it is expected, it'd be nice to have a warning while converting
> templates.
> {quote}
> I feel CRON support is an important one, and in maintaining some of the
> simpler functionalities that are in NiFi, think should also be available in
> MiNiFi.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MINIFI-82) Improve config.yml to handle component annotation data
[ https://issues.apache.org/jira/browse/MINIFI-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned MINIFI-82: -- Assignee: Joseph Percivall > Improve config.yml to handle component annotation data > -- > > Key: MINIFI-82 > URL: https://issues.apache.org/jira/browse/MINIFI-82 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Affects Versions: 0.0.1 >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 0.1.0 > > > Currently the config.yml does not allow for the configuration of component > annotation data. A specific example of which, is the annotation data created > by using the advanced UI of UpdateAttribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-106) Support for duplicate processor names
[ https://issues.apache.org/jira/browse/MINIFI-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-106. - Resolution: Fixed Fix Version/s: 0.1.0 Resolved via: https://github.com/apache/nifi-minifi/commit/93af87dd841c7886997e2b7d7c9f62334c366e74 > Support for duplicate processor names > - > > Key: MINIFI-106 > URL: https://issues.apache.org/jira/browse/MINIFI-106 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Bryan Rosander > Fix For: 0.1.0 > > > Currently we require that processor names be identical in the config.yml used > for MiNiFi Java. We would need unique identifiers to support duplicate names > which is something NiFi already has. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-108) MiNiFi should use id fields for uniqueness
[ https://issues.apache.org/jira/browse/MINIFI-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-108. - Resolution: Fixed Fix Version/s: 0.1.0 Resolved via: https://github.com/apache/nifi-minifi/commit/93af87dd841c7886997e2b7d7c9f62334c366e74 > MiNiFi should use id fields for uniqueness > -- > > Key: MINIFI-108 > URL: https://issues.apache.org/jira/browse/MINIFI-108 > Project: Apache NiFi MiNiFi > Issue Type: Improvement >Reporter: Bryan Rosander > Fix For: 0.1.0 > > > NiFi uses ids in order to guarantee uniqueness and ensure safe swap file > creation (MINIFI-104). > We should leverage ids in the MiNiFi YAML where NiFi uses them. > This should be done in a backwards-compatible way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-82) Improve config.yml to handle component annotation data
Joseph Percivall created MINIFI-82: -- Summary: Improve config.yml to handle component annotation data Key: MINIFI-82 URL: https://issues.apache.org/jira/browse/MINIFI-82 Project: Apache NiFi MiNiFi Issue Type: Improvement Affects Versions: 0.0.1 Reporter: Joseph Percivall Fix For: 0.1.0 Currently the config.yml does not allow for the configuration of component annotation data. A specific example of which, is the annotation data created by using the advanced UI of UpdateAttribute. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-60) Remove clean up default minifi-resources
Joseph Percivall created MINIFI-60: -- Summary: Remove clean up default minifi-resources Key: MINIFI-60 URL: https://issues.apache.org/jira/browse/MINIFI-60 Project: Apache NiFi MiNiFi Issue Type: Improvement Affects Versions: 0.0.1 Reporter: Joseph Percivall Priority: Minor Fix For: 0.1.0 In the minifi-resources module there are a number of files that are either not used at all or replaced when the service starts (nifi.properties and flow.xml.gz). The erroneous files should be removed. https://github.com/apache/nifi-minifi/tree/master/minifi-nar-bundles/minifi-framework-bundle/minifi-framework/minifi-resources/src/main/resources/conf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-54) ConfigSchema duplicate validation only works when processors is not null
[ https://issues.apache.org/jira/browse/MINIFI-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-54: --- Fix Version/s: 0.1.0 > ConfigSchema duplicate validation only works when processors is not null > > > Key: MINIFI-54 > URL: https://issues.apache.org/jira/browse/MINIFI-54 > Project: Apache NiFi MiNiFi > Issue Type: Bug >Reporter: Bryan Rosander > Fix For: 0.1.0 > > > ConfigSchema has logic to detect duplicate processor, connection, and remote > processing group names. This is to help MiNiFi ensure it can generate a > valid flow. > Unfortunately, the check is short circuited if processors are null, > regardless of which duplicates it is checking for, causing for possibly > missing validation errors. > https://github.com/apache/nifi-minifi/blob/2d1e43e73b90df55abc71845160b6422d7a6f03f/minifi-commons/minifi-commons-schema/src/main/java/org/apache/nifi/minifi/commons/schema/ConfigSchema.java#L122 > Should be changed to a null check on the names parameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-54) ConfigSchema duplicate validation only works when processors is not null
[ https://issues.apache.org/jira/browse/MINIFI-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-54. Resolution: Fixed > ConfigSchema duplicate validation only works when processors is not null > > > Key: MINIFI-54 > URL: https://issues.apache.org/jira/browse/MINIFI-54 > Project: Apache NiFi MiNiFi > Issue Type: Bug >Reporter: Bryan Rosander > > ConfigSchema has logic to detect duplicate processor, connection, and remote > processing group names. This is to help MiNiFi ensure it can generate a > valid flow. > Unfortunately, the check is short circuited if processors are null, > regardless of which duplicates it is checking for, causing for possibly > missing validation errors. > https://github.com/apache/nifi-minifi/blob/2d1e43e73b90df55abc71845160b6422d7a6f03f/minifi-commons/minifi-commons-schema/src/main/java/org/apache/nifi/minifi/commons/schema/ConfigSchema.java#L122 > Should be changed to a null check on the names parameter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-50) README is insufficient
[ https://issues.apache.org/jira/browse/MINIFI-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-50. Resolution: Fixed > README is insufficient > -- > > Key: MINIFI-50 > URL: https://issues.apache.org/jira/browse/MINIFI-50 > Project: Apache NiFi MiNiFi > Issue Type: Bug > Components: Documentation >Reporter: Aldrin Piri >Assignee: Aldrin Piri >Priority: Blocker > Fix For: 0.0.1 > > > The README in its current state is insufficient for helping people get > started especially in the context of the source distribution. We need to > ensure that users have at least enough information to get headed down the > right path and sufficient places to look if additional information is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-24) Remove Spring dependencies
[ https://issues.apache.org/jira/browse/MINIFI-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-24. Resolution: Fixed Resolved as part of https://github.com/apache/nifi-minifi/pull/27 > Remove Spring dependencies > -- > > Key: MINIFI-24 > URL: https://issues.apache.org/jira/browse/MINIFI-24 > Project: Apache NiFi MiNiFi > Issue Type: Sub-task >Reporter: Aldrin Piri > > There are a number of dependencies on Spring that provide a lot of great > configuration and dependency injection via configuration files that would > likely go unused given the limited interaction with a particular agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-21) Minimize footprint
[ https://issues.apache.org/jira/browse/MINIFI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-21. Resolution: Fixed > Minimize footprint > -- > > Key: MINIFI-21 > URL: https://issues.apache.org/jira/browse/MINIFI-21 > Project: Apache NiFi MiNiFi > Issue Type: Task >Reporter: Aldrin Piri >Assignee: Aldrin Piri > Fix For: 0.0.1 > > > There are a number of items that came with the NiFi dependencies in creating > the initial implementation that serve little utility in the scope of how > MiNiFi would be used and should be removed/rewritten in a capacity built > specifically for MiNiFi cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-48) Null or Empty queue prioritizer in config yaml should result in default prioritizer
[ https://issues.apache.org/jira/browse/MINIFI-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-48. Resolution: Fixed > Null or Empty queue prioritizer in config yaml should result in default > prioritizer > --- > > Key: MINIFI-48 > URL: https://issues.apache.org/jira/browse/MINIFI-48 > Project: Apache NiFi MiNiFi > Issue Type: Bug >Reporter: Bryan Rosander > > Currently, null or empty values for Queue Prioritizer in the config yaml > cause the following stack trace: > org.apache.nifi.controller.FlowSynchronizationException: > java.lang.IllegalArgumentException: Unable to set prioritizer : > java.lang.ClassNotFoundException: > at > org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:317) > ~[nifi-framework-core-0.6.0.jar:0.6.0] > at > org.apache.nifi.controller.FlowController.synchronize(FlowController.java:1287) > ~[nifi-framework-core-0.6.0.jar:0.6.0] > at > org.apache.nifi.persistence.StandardXMLFlowConfigurationDAO.load(StandardXMLFlowConfigurationDAO.java:72) > ~[nifi-framework-core-0.6.0.jar:0.6.0] > at > org.apache.nifi.controller.StandardFlowService.loadFromBytes(StandardFlowService.java:629) > ~[nifi-framework-core-0.6.0.jar:0.6.0] > at > org.apache.nifi.controller.StandardFlowService.load(StandardFlowService.java:479) > ~[nifi-framework-core-0.6.0.jar:0.6.0] > at > org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:79) > ~[na:na] > at > org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444) > ~[jetty-servlet-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294) > ~[jetty-servlet-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) > ~[jetty-webapp-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) > ~[jetty-webapp-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) > ~[jetty-webapp-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at org.eclipse.jetty.server.Server.start(Server.java:387) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at org.eclipse.jetty.server.Server.doStart(Server.java:354) > ~[jetty-server-9.2.11.v20150529.jar:9.2.11.v20150529] > at > org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) > ~[jetty-util-9.2.11.v20150529.jar:9.2.11.v20150529] > at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:662) > ~[nifi-jetty-0.6.0.jar:0.6.0] > at org.apache.nifi.minifi.MiNiFi.(MiNiFi.java:138) > [minifi-runtime-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT] > at org.apache.nifi.minifi.MiNiFi.main(MiNiFi.java:233) >
[jira] [Resolved] (MINIFI-41) Command Line Configuration Utility
[ https://issues.apache.org/jira/browse/MINIFI-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-41. Resolution: Fixed > Command Line Configuration Utility > -- > > Key: MINIFI-41 > URL: https://issues.apache.org/jira/browse/MINIFI-41 > Project: Apache NiFi MiNiFi > Issue Type: New Feature >Reporter: Bryan Rosander > > It would really increase usability if we had a way to transform template xmls > into configuration YAML files for consumption by MiNiFi. > The utility should: > 1. Transform template xmls exported from NiFi into configuration YAML files. > 2. Validate the contents of a given YAML file in the same way MiNiFi does at > runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-29) Create FlowController implementation
[ https://issues.apache.org/jira/browse/MINIFI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-29: --- Fix Version/s: (was: 0.0.1) 0.1.0 > Create FlowController implementation > - > > Key: MINIFI-29 > URL: https://issues.apache.org/jira/browse/MINIFI-29 > Project: Apache NiFi MiNiFi > Issue Type: Task > Components: Core Framework >Reporter: Aldrin Piri >Assignee: Aldrin Piri > Fix For: 0.1.0 > > > While much can be reused and many of the fundamentals are the same, a > component of similar functionality to the FlowController in NiFi is also > needed to handle the specifics of how processing works within MiNiFi -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2169) Improve RouteText performance with pre-compilation of RegEx in certain cases
[ https://issues.apache.org/jira/browse/NIFI-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated NIFI-2169: --- Fix Version/s: (was: 0.7.0) 1.0.0 > Improve RouteText performance with pre-compilation of RegEx in certain cases > > > Key: NIFI-2169 > URL: https://issues.apache.org/jira/browse/NIFI-2169 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek > Fix For: 1.0.0 > > > When using RegEx matches for the RouteText processor (and possibly other > processors), the RegEx gets recompiled every time the processor works. The > RegEx could be precompiled / cached under certain conditions, in order to > improve the performance of the processor > See email from Mark Payne: > Re #2: The regular expression is compiled every time. This is done, though, > because the Regex allows the Expression > Language to be used, so the Regex could actually be different for each > FlowFile. That being said, it could certainly be > improved by either (a) pre-compiling in the case that no Expression Language > is used and/or (b) cache up to say 10 > Regex'es once they are compiled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2169) Improve RouteText performance with pre-compilation of RegEx in certain cases
[ https://issues.apache.org/jira/browse/NIFI-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362550#comment-15362550 ] Joseph Percivall commented on NIFI-2169: Hello [~stephane.maa...@gmail.com], we are currently in the final stages of releasing 0.7.0 so only critical blocker bugs will be tracked for the release. I am removing the fix version of 0.7.0 and adding 1.0 (the other release currently being tracked). > Improve RouteText performance with pre-compilation of RegEx in certain cases > > > Key: NIFI-2169 > URL: https://issues.apache.org/jira/browse/NIFI-2169 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 0.6.1 >Reporter: Stephane Maarek > Fix For: 1.0.0 > > > When using RegEx matches for the RouteText processor (and possibly other > processors), the RegEx gets recompiled every time the processor works. The > RegEx could be precompiled / cached under certain conditions, in order to > improve the performance of the processor > See email from Mark Payne: > Re #2: The regular expression is compiled every time. This is done, though, > because the Regex allows the Expression > Language to be used, so the Regex could actually be different for each > FlowFile. That being said, it could certainly be > improved by either (a) pre-compiling in the case that no Expression Language > is used and/or (b) cache up to say 10 > Regex'es once they are compiled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MINIFI-21) Minimize footprint
[ https://issues.apache.org/jira/browse/MINIFI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15361881#comment-15361881 ] Joseph Percivall commented on MINIFI-21: [~aldrin] I removed those docs as part of a PR for MINIFI-22 > Minimize footprint > -- > > Key: MINIFI-21 > URL: https://issues.apache.org/jira/browse/MINIFI-21 > Project: Apache NiFi MiNiFi > Issue Type: Task >Reporter: Aldrin Piri >Assignee: Aldrin Piri > Fix For: 0.0.1 > > > There are a number of items that came with the NiFi dependencies in creating > the initial implementation that serve little utility in the scope of how > MiNiFi would be used and should be removed/rewritten in a capacity built > specifically for MiNiFi cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MINIFI-49) RestChangeNotifier test fails on Windows
[ https://issues.apache.org/jira/browse/MINIFI-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated MINIFI-49: --- Fix Version/s: 0.0.1 > RestChangeNotifier test fails on Windows > > > Key: MINIFI-49 > URL: https://issues.apache.org/jira/browse/MINIFI-49 > Project: Apache NiFi MiNiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 0.0.1 > > > The upload checks against a file on disk and fails due to line endings > varying. The test should be fixed to be system independent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-49) RestChangeNotifier test fails on Windows
Joseph Percivall created MINIFI-49: -- Summary: RestChangeNotifier test fails on Windows Key: MINIFI-49 URL: https://issues.apache.org/jira/browse/MINIFI-49 Project: Apache NiFi MiNiFi Issue Type: Bug Reporter: Joseph Percivall Assignee: Joseph Percivall The upload checks against a file on disk and fails due to line endings varying. The test should be fixed to be system independent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-42) ConfigTransformer does not honor Remote Process Group name/id
[
https://issues.apache.org/jira/browse/MINIFI-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall resolved MINIFI-42.
Resolution: Fixed
> ConfigTransformer does not honor Remote Process Group name/id
> -
>
> Key: MINIFI-42
> URL: https://issues.apache.org/jira/browse/MINIFI-42
> Project: Apache NiFi MiNiFi
> Issue Type: Bug
> Components: Processing Configuration
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
>
> The config YAML uses the Remote Process Group name to establish identity for
> the associated process group with the introduction of supporting multiple
> such groups. If this does not coincide with the Remote-Process-Group name,
> there will be issues when trying to provide the appropriate connections as
> evidenced by stacktraces such as:
> {quote}
> 2016-06-27 10:22:30,242 WARN [main] org.apache.nifi.web.server.JettyServer
> Failed to start web server... shutting down.
> org.apache.nifi.controller.FlowSynchronizationException:
> java.lang.NullPointerException
> at
> org.apache.nifi.controller.StandardFlowSynchronizer.sync(StandardFlowSynchronizer.java:317)
> ~[nifi-framework-core-0.6.1.jar:0.6.1]
> {quote}
> or
> {quote}
> java.lang.Exception: Unable to load flow due to:
> org.apache.nifi.controller.FlowSynchronizationException:
> java.lang.RuntimeException: Found Invalid Connectable ID for Destination:
> 8644cbcc-a45c-40e0-964d-5e536e2ada61
> at org.apache.nifi.minifi.MiNiFiServer.start(MiNiFiServer.java:92)
> [minifi-runtime-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
> at org.apache.nifi.minifi.MiNiFi.(MiNiFi.java:133)
> [minifi-runtime-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
> at org.apache.nifi.minifi.MiNiFi.main(MiNiFi.java:228)
> [minifi-runtime-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
> Caused by: org.apache.nifi.controller.FlowSynchronizationException:
> java.lang.RuntimeException: Found Invalid Connectable ID for Destination:
> 8644cbcc-a45c-40e0-964d-5e536e2ada61
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NIFI-1502) FetchEventViewer - NiFi should be able to consume Even Viewer (Windows Logs)
[ https://issues.apache.org/jira/browse/NIFI-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved NIFI-1502. Resolution: Fixed > FetchEventViewer - NiFi should be able to consume Even Viewer (Windows Logs) > > > Key: NIFI-1502 > URL: https://issues.apache.org/jira/browse/NIFI-1502 > Project: Apache NiFi > Issue Type: Bug >Reporter: Andre > > While a lot of the use cases using NiFi orbit the IoT, Unix Cloud type > workloads, I suspect NiFi would be a great fit for data collections of > business critical platforms running Windows. > A good example of this type of workload would be ATMs running Windows 7 and > even run Windows XP, or collection of Event Log error events on Windows > platforms (including Azure). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-1976) JNA-Based Event Log Subscription Processor
[ https://issues.apache.org/jira/browse/NIFI-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved NIFI-1976. Resolution: Fixed > JNA-Based Event Log Subscription Processor > -- > > Key: NIFI-1976 > URL: https://issues.apache.org/jira/browse/NIFI-1976 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Bryan Rosander > > Using JNA, we should be able to leverage existing Windows APIs to natively > consume events as they happen. Will look into subscribing to events > (https://msdn.microsoft.com/en-us/library/windows/desktop/aa385771(v=vs.85).aspx) > in order to reduce latency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (NIFI-2089) NIFI-1824 causes failures on Windows
[ https://issues.apache.org/jira/browse/NIFI-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reopened NIFI-2089: I didn't realize this issue needed to be resolved in 1.0.0 and didn't merge the fix into master. > NIFI-1824 causes failures on Windows > > > Key: NIFI-2089 > URL: https://issues.apache.org/jira/browse/NIFI-2089 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.0.0, 0.7.0 > > > Below is the output of a maven build of the current 0.x branch on Windows 8. > After reverting NIFI-1824 (commit 1ff55244ceca8220dbfdc3ca58eb42218536579f) > the test succeeds. > Output: > --- > T E S T S > --- > Running org.apache.nifi.cluster.HeartbeatPayloadTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec - > in org.apache.nifi.cluster.HeartbeatPayloadTest > Running org.apache.nifi.controller.repository.io.TestLimitedInputStream > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in > org.apache.nifi.controller.repository.io.TestLimitedInputStream > Running org.apache.nifi.controller.repository.TestFileSystemRepository > Tests run: 28, Failures: 1, Errors: 2, Skipped: 0, Time elapsed: 33.81 sec > <<< FAILURE! - in > org.apache.nifi.controller.repository.TestFileSystemRepository > testRemoveDeletesFileIfNoClaimants(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.86 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at org.junit.Assert.assertFalse(Assert.java:74) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testRemoveDeletesFileIfNoClaimants(TestFileSystemRepository.java:274) > testExportToFile(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.867 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638368813-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToFile(TestFileSystemRepository.java:348) > testExportToOutputStream(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.859 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638376837-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToOutputStream(TestFileSystemRepository.java:335) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2089) NIFI-1824 causes failures on Windows
[ https://issues.apache.org/jira/browse/NIFI-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353608#comment-15353608 ] Joseph Percivall commented on NIFI-2089: [~markap14] could you open a new PR for master, the current one does not apply cleanly. > NIFI-1824 causes failures on Windows > > > Key: NIFI-2089 > URL: https://issues.apache.org/jira/browse/NIFI-2089 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.0.0, 0.7.0 > > > Below is the output of a maven build of the current 0.x branch on Windows 8. > After reverting NIFI-1824 (commit 1ff55244ceca8220dbfdc3ca58eb42218536579f) > the test succeeds. > Output: > --- > T E S T S > --- > Running org.apache.nifi.cluster.HeartbeatPayloadTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec - > in org.apache.nifi.cluster.HeartbeatPayloadTest > Running org.apache.nifi.controller.repository.io.TestLimitedInputStream > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in > org.apache.nifi.controller.repository.io.TestLimitedInputStream > Running org.apache.nifi.controller.repository.TestFileSystemRepository > Tests run: 28, Failures: 1, Errors: 2, Skipped: 0, Time elapsed: 33.81 sec > <<< FAILURE! - in > org.apache.nifi.controller.repository.TestFileSystemRepository > testRemoveDeletesFileIfNoClaimants(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.86 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at org.junit.Assert.assertFalse(Assert.java:74) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testRemoveDeletesFileIfNoClaimants(TestFileSystemRepository.java:274) > testExportToFile(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.867 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638368813-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToFile(TestFileSystemRepository.java:348) > testExportToOutputStream(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.859 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638376837-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToOutputStream(TestFileSystemRepository.java:335) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2120) source release produces an extraneous file
[ https://issues.apache.org/jira/browse/NIFI-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353112#comment-15353112 ] Joseph Percivall commented on NIFI-2120: I looked into how this would be done and couldn't find any Maven Release Plug-in options that would fulfill this need. The closest thing I've found is "checkModificationExclude"[1] but that is for ignoring local uncommitted changes to a file. If anyone has experience with this please feel free to to take a shot at it. [1] http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#checkModificationExcludes > source release produces an extraneous file > -- > > Key: NIFI-2120 > URL: https://issues.apache.org/jira/browse/NIFI-2120 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build >Reporter: Joseph Witt >Priority: Trivial > > The source release now includes 'appveyor.yml' at the top of the source > directory. This file should not end up in the source release ideally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2119) Secure clustering returning bad request response
[ https://issues.apache.org/jira/browse/NIFI-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated NIFI-2119: --- Fix Version/s: 0.7.0 > Secure clustering returning bad request response > > > Key: NIFI-2119 > URL: https://issues.apache.org/jira/browse/NIFI-2119 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Joseph Witt > Fix For: 0.7.0 > > > Cannot get a secured cluster working that worked well on 0.6.0. After > upgrading now seeing the following line. It either means I upgraded > incorrectly, or we're missing critical migration guidance, or we have > introduced a new bug. > 2016-06-25 14:19:12,017 INFO [NiFi Web Server-23] > o.a.n.w.a.c.IllegalArgumentExceptionMapper > java.lang.IllegalArgumentException: User account already created > CN=box1.testing.org, OU=NIFI, O=Apache-NiFi, L=Here, ST=There, C=EVERYWHERE. > Returning Bad Request response. > Speaking with [~mcgilman] about this he looked into it and says > "the socket used for cluster communications is configured with an sslContext > that has client auth set to none... which seems to be why the we're not > getting the NCM DN during connection > i think the issue is this part of this commit > https://github.com/apache/nifi/commit/7b5583f3a8c8e3f62e2985059a3466a5bb36f4e8#diff-a14f46a45c394fbd82a2b99730e04bcbR68; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2120) source release produces an extraneous file
[ https://issues.apache.org/jira/browse/NIFI-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15352990#comment-15352990 ] Joseph Percivall commented on NIFI-2120: The travis yaml gets bundled in too (it's a hidden file, ".travis.yml") and ideally wouldn't be in the source release either. > source release produces an extraneous file > -- > > Key: NIFI-2120 > URL: https://issues.apache.org/jira/browse/NIFI-2120 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build >Reporter: Joseph Witt >Priority: Trivial > > The source release now includes 'appveyor.yml' at the top of the source > directory. This file should not end up in the source release ideally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MINIFI-40) SecurityPropertiesSchema doesn't properly handle empty security properties
[ https://issues.apache.org/jira/browse/MINIFI-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved MINIFI-40. Resolution: Fixed > SecurityPropertiesSchema doesn't properly handle empty security properties > -- > > Key: MINIFI-40 > URL: https://issues.apache.org/jira/browse/MINIFI-40 > Project: Apache NiFi MiNiFi > Issue Type: Bug >Reporter: Joseph Percivall > > The SecurityPropertiesSchema class uses the getOptionalKeyAsType method with > a default value of null for each of the keystore, truststore and sslProtcol > properties. This ends up getting translated to "null" in the nifi.properties > file. > The correct default should be "". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MINIFI-43) ConfigSchema always instantiates ProvenanceReporter
Joseph Percivall created MINIFI-43: -- Summary: ConfigSchema always instantiates ProvenanceReporter Key: MINIFI-43 URL: https://issues.apache.org/jira/browse/MINIFI-43 Project: Apache NiFi MiNiFi Issue Type: Bug Reporter: Joseph Percivall Assignee: Joseph Percivall Currently when a flow does set not the Provenance Reporting Task the ConfigTransformer will instantiate a ProvenanceReportingSchema the default constructor. The problem being there are required properties that don't get created and when NiFi attempts to start the reporting task it fails. ConfigSchema needs a way to get an optional property that doesn't get instantiated when null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2118) Correct license/notice issues
[ https://issues.apache.org/jira/browse/NIFI-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned NIFI-2118: -- Assignee: Joseph Percivall > Correct license/notice issues > - > > Key: NIFI-2118 > URL: https://issues.apache.org/jira/browse/NIFI-2118 > Project: Apache NiFi > Issue Type: Bug > Components: Tools and Build >Reporter: Joseph Witt >Assignee: Joseph Percivall > Fix For: 0.7.0 > > > *The LICENSE file has this entry "This product bundles 'Jolt' which is > available under an Apache License" > We should not have apache licensed items in our license file. We only need > to carry forward NOTICE information of such dependencies and those would go > in our NOTICE if applicable. > * The nifi-assembly/NOTICE file has an "MIT License" section. This should be > removed. MIT licensed items should be reflected in the LICENSE file and Luaj > already appears to be there. > * The nifi-assembly/NOTICE file references "Python Software Foundation" > section. Python license is category A. Such dependency belongs in LICENSE > file and not NOTICE. Only if that dependency has a NOTICE with legally > required items should there be a reference to it in our NOTICE as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2112) Perform Release Management Functions for 0.7.0
Joseph Percivall created NIFI-2112: -- Summary: Perform Release Management Functions for 0.7.0 Key: NIFI-2112 URL: https://issues.apache.org/jira/browse/NIFI-2112 Project: Apache NiFi Issue Type: Task Reporter: Joseph Percivall Assignee: Joseph Percivall Fix For: 0.7.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-2089) NIFI-1824 causes failures on Windows
[ https://issues.apache.org/jira/browse/NIFI-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved NIFI-2089. Resolution: Fixed > NIFI-1824 causes failures on Windows > > > Key: NIFI-2089 > URL: https://issues.apache.org/jira/browse/NIFI-2089 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Mark Payne >Priority: Blocker > Fix For: 1.0.0, 0.7.0 > > > Below is the output of a maven build of the current 0.x branch on Windows 8. > After reverting NIFI-1824 (commit 1ff55244ceca8220dbfdc3ca58eb42218536579f) > the test succeeds. > Output: > --- > T E S T S > --- > Running org.apache.nifi.cluster.HeartbeatPayloadTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec - > in org.apache.nifi.cluster.HeartbeatPayloadTest > Running org.apache.nifi.controller.repository.io.TestLimitedInputStream > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in > org.apache.nifi.controller.repository.io.TestLimitedInputStream > Running org.apache.nifi.controller.repository.TestFileSystemRepository > Tests run: 28, Failures: 1, Errors: 2, Skipped: 0, Time elapsed: 33.81 sec > <<< FAILURE! - in > org.apache.nifi.controller.repository.TestFileSystemRepository > testRemoveDeletesFileIfNoClaimants(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.86 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at org.junit.Assert.assertFalse(Assert.java:74) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testRemoveDeletesFileIfNoClaimants(TestFileSystemRepository.java:274) > testExportToFile(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.867 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638368813-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToFile(TestFileSystemRepository.java:348) > testExportToOutputStream(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.859 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638376837-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToOutputStream(TestFileSystemRepository.java:335) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2098) Improve testManyFilesOpened in TestStandardProcessSession
Joseph Percivall created NIFI-2098: -- Summary: Improve testManyFilesOpened in TestStandardProcessSession Key: NIFI-2098 URL: https://issues.apache.org/jira/browse/NIFI-2098 Project: Apache NiFi Issue Type: Bug Reporter: Joseph Percivall Priority: Minor This unit test[1] is just unnecessarily long and poorly written (uses System.out). What the test is trying to test should be revisited and at the very least it should be ignored for the maven build. [1] https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/test/java/org/apache/nifi/controller/repository/TestStandardProcessSession.java#L804-L804 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2092) TestProcessorLifecyle fails on Windows
[ https://issues.apache.org/jira/browse/NIFI-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15345636#comment-15345636 ] Joseph Percivall commented on NIFI-2092: This also applies to the MonitorMemoryTest which does the same thing: https://github.com/apache/nifi/blob/0.x/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-reporting-tasks/src/test/java/org/apache/nifi/controller/MonitorMemoryTest.java#L53-L53 > TestProcessorLifecyle fails on Windows > -- > > Key: NIFI-2092 > URL: https://issues.apache.org/jira/browse/NIFI-2092 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.0.0, 0.7.0 > > > Currently, the "after" method tries to delete the content-repo and test-repo > before shutting down the flowcontroller (causing failures due to files being > locked). > `fc.shutdown(true)` should be moved before the deleteDirectory() calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (NIFI-2092) TestProcessorLifecyle fails on Windows
[ https://issues.apache.org/jira/browse/NIFI-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reassigned NIFI-2092: -- Assignee: Joseph Percivall > TestProcessorLifecyle fails on Windows > -- > > Key: NIFI-2092 > URL: https://issues.apache.org/jira/browse/NIFI-2092 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Joseph Percivall > Fix For: 1.0.0, 0.7.0 > > > Currently, the "after" method tries to delete the content-repo and test-repo > before shutting down the flowcontroller (causing failures due to files being > locked). > `fc.shutdown(true)` should be moved before the deleteDirectory() calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2092) TestProcessorLifecyle fails on Windows
Joseph Percivall created NIFI-2092: -- Summary: TestProcessorLifecyle fails on Windows Key: NIFI-2092 URL: https://issues.apache.org/jira/browse/NIFI-2092 Project: Apache NiFi Issue Type: Bug Reporter: Joseph Percivall Fix For: 1.0.0, 0.7.0 Currently, the "after" method tries to delete the content-repo and test-repo before shutting down the flowcontroller (causing failures due to files being locked). `fc.shutdown(true)` should be moved before the deleteDirectory() calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (NIFI-2089) NIFI-1824 causes failures on Windows
[ https://issues.apache.org/jira/browse/NIFI-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall updated NIFI-2089: --- Summary: NIFI-1824 causes failures on Windows (was: NIFI-1824 causes test failures on Windows) > NIFI-1824 causes failures on Windows > > > Key: NIFI-2089 > URL: https://issues.apache.org/jira/browse/NIFI-2089 > Project: Apache NiFi > Issue Type: Bug >Reporter: Joseph Percivall >Assignee: Mark Payne >Priority: Blocker > Fix For: 0.7.0 > > > Below is the output of a maven build of the current 0.x branch on Windows 8. > After reverting NIFI-1824 (commit 1ff55244ceca8220dbfdc3ca58eb42218536579f) > the test succeeds. > Output: > --- > T E S T S > --- > Running org.apache.nifi.cluster.HeartbeatPayloadTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec - > in org.apache.nifi.cluster.HeartbeatPayloadTest > Running org.apache.nifi.controller.repository.io.TestLimitedInputStream > Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in > org.apache.nifi.controller.repository.io.TestLimitedInputStream > Running org.apache.nifi.controller.repository.TestFileSystemRepository > Tests run: 28, Failures: 1, Errors: 2, Skipped: 0, Time elapsed: 33.81 sec > <<< FAILURE! - in > org.apache.nifi.controller.repository.TestFileSystemRepository > testRemoveDeletesFileIfNoClaimants(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.86 sec <<< FAILURE! > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertFalse(Assert.java:64) > at org.junit.Assert.assertFalse(Assert.java:74) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testRemoveDeletesFileIfNoClaimants(TestFileSystemRepository.java:274) > testExportToFile(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.867 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638368813-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToFile(TestFileSystemRepository.java:348) > testExportToOutputStream(org.apache.nifi.controller.repository.TestFileSystemRepository) > Time elapsed: 0.859 sec <<< ERROR! > java.nio.file.FileSystemException: > C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638376837-1: > The process cannot access the file because it is being used by another > process. > at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) > at > sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) > at java.nio.file.Files.copy(Files.java:1274) > at > org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToOutputStream(TestFileSystemRepository.java:335) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2089) NIFI-1824 causes test failures on Windows
Joseph Percivall created NIFI-2089: -- Summary: NIFI-1824 causes test failures on Windows Key: NIFI-2089 URL: https://issues.apache.org/jira/browse/NIFI-2089 Project: Apache NiFi Issue Type: Bug Reporter: Joseph Percivall Assignee: Mark Payne Priority: Blocker Fix For: 0.7.0 Below is the output of a maven build of the current 0.x branch on Windows 8. After reverting NIFI-1824 (commit 1ff55244ceca8220dbfdc3ca58eb42218536579f) the test succeeds. Output: --- T E S T S --- Running org.apache.nifi.cluster.HeartbeatPayloadTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec - in org.apache.nifi.cluster.HeartbeatPayloadTest Running org.apache.nifi.controller.repository.io.TestLimitedInputStream Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in org.apache.nifi.controller.repository.io.TestLimitedInputStream Running org.apache.nifi.controller.repository.TestFileSystemRepository Tests run: 28, Failures: 1, Errors: 2, Skipped: 0, Time elapsed: 33.81 sec <<< FAILURE! - in org.apache.nifi.controller.repository.TestFileSystemRepository testRemoveDeletesFileIfNoClaimants(org.apache.nifi.controller.repository.TestFileSystemRepository) Time elapsed: 0.86 sec <<< FAILURE! java.lang.AssertionError: null at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.junit.Assert.assertFalse(Assert.java:74) at org.apache.nifi.controller.repository.TestFileSystemRepository.testRemoveDeletesFileIfNoClaimants(TestFileSystemRepository.java:274) testExportToFile(org.apache.nifi.controller.repository.TestFileSystemRepository) Time elapsed: 0.867 sec <<< ERROR! java.nio.file.FileSystemException: C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638368813-1: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) at java.nio.file.Files.copy(Files.java:1274) at org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToFile(TestFileSystemRepository.java:348) testExportToOutputStream(org.apache.nifi.controller.repository.TestFileSystemRepository) Time elapsed: 0.859 sec <<< ERROR! java.nio.file.FileSystemException: C:\Users\Joe\AppData\Local\Programs\Git\nifi\nifi-nar-bundles\nifi-framework-bundle\nifi-framework\nifi-framework-core\target\content_repository\1\1466638376837-1: The process cannot access the file because it is being used by another process. at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165) at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278) at java.nio.file.Files.copy(Files.java:1274) at org.apache.nifi.controller.repository.TestFileSystemRepository.testExportToOutputStream(TestFileSystemRepository.java:335) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (NIFI-2045) ConsumeMQTT can lose a message if session commit fails
[ https://issues.apache.org/jira/browse/NIFI-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved NIFI-2045. Resolution: Fixed > ConsumeMQTT can lose a message if session commit fails > -- > > Key: NIFI-2045 > URL: https://issues.apache.org/jira/browse/NIFI-2045 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.0.0 >Reporter: Bryan Rosander >Priority: Critical > > ConsumeMQTT removes the received message from the queue before committing the > session. This means that if the session commit fails and the session rolls > back, the message will be lost. > https://github.com/apache/nifi/blob/f47af1ce8336c9305916f00738976f3505b01b0b/nifi-nar-bundles/nifi-mqtt-bundle/nifi-mqtt-processors/src/main/java/org/apache/nifi/processors/mqtt/ConsumeMQTT.java#L292 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-2069) Add option to UI to enter interpreted vs literal text
[
https://issues.apache.org/jira/browse/NIFI-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15344392#comment-15344392
]
Joseph Percivall commented on NIFI-2069:
There may be someone who can suggest a better term than "interpreted" but I
like the placement a lot. It's visually reinforces the distinction between the
two. One thing, I think there should be a little "?" (like in processor
descriptors) which we can have a pop-up explanation for it.
> Add option to UI to enter interpreted vs literal text
> --
>
> Key: NIFI-2069
> URL: https://issues.apache.org/jira/browse/NIFI-2069
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Joseph Percivall
> Attachments: interpret-escape-sequences_nifi-2...@2x.png, mock-up.png
>
>
> In adding the PutTCP processor there has been some debate over accepting "\n"
> as the literal characters "\" and "n" vs the character for a new line.
> Currently the UI will pass the literal values and it's on the processor to
> decide what to do with them. Leading to multiple processors to interpret
> "\n", "\t" or "\r" entered in the UI as a new line, tab and carriage return
> respectively.
> It is reasonable for a user to want enter "\n" as a new line but it is also
> not correct to be inconsistent in how the user enters values throughout the
> UI. When entering a string in the UI there should be a second checkbox (next
> to "Empty") for "Interpreted" (name subject to change). This would allow
> users to select whether the values the enter are interpreted ("\n" -> new
> line character) vs literals ("\n" -> "\" and "\n"). Also this should allow
> for the support for entering unicode characters.
> In order to keep backwards compatibility the default would be not interpreted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (NIFI-2046) Mention @TriggerSerially in Processor.onTrigger() javadoc
[ https://issues.apache.org/jira/browse/NIFI-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall resolved NIFI-2046. Resolution: Fixed > Mention @TriggerSerially in Processor.onTrigger() javadoc > - > > Key: NIFI-2046 > URL: https://issues.apache.org/jira/browse/NIFI-2046 > Project: Apache NiFi > Issue Type: Bug >Reporter: Bryan Rosander >Priority: Trivial > > The Processor javadoc explicitly says that multiple threads can concurrently > call the onTrigger() method. > It should be modified to account for the @TriggerSerially annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (NIFI-2069) Add option to UI to enter interpreted vs literal text
Joseph Percivall created NIFI-2069:
--
Summary: Add option to UI to enter interpreted vs literal text
Key: NIFI-2069
URL: https://issues.apache.org/jira/browse/NIFI-2069
Project: Apache NiFi
Issue Type: Improvement
Reporter: Joseph Percivall
Attachments: mock-up.png
In adding the PutTCP processor there has been some debate over accepting "\n"
as the literal characters "\" and "n" vs the character for a new line.
Currently the UI will pass the literal values and it's on the processor to
decide what to do with them. Leading to multiple processors to interpret "\n",
"\t" or "\r" entered in the UI as a new line, tab and carriage return
respectively.
It is reasonable for a user to want enter "\n" as a new line but it is also not
correct to be inconsistent in how the user enters values throughout the UI.
When entering a string in the UI there should be a second checkbox (next to
"Empty") for "Interpreted" (name subject to change). This would allow users to
select whether the values the enter are interpreted ("\n" -> new line
character) vs literals ("\n" -> "\" and "\n"). Also this should allow for the
support for entering unicode characters.
In order to keep backwards compatibility the default would be not interpreted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (NIFI-2069) Add option to UI to enter interpreted vs literal text
[
https://issues.apache.org/jira/browse/NIFI-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Percivall updated NIFI-2069:
---
Attachment: mock-up.png
Example mock of the new checkbox
> Add option to UI to enter interpreted vs literal text
> --
>
> Key: NIFI-2069
> URL: https://issues.apache.org/jira/browse/NIFI-2069
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Joseph Percivall
> Attachments: mock-up.png
>
>
> In adding the PutTCP processor there has been some debate over accepting "\n"
> as the literal characters "\" and "n" vs the character for a new line.
> Currently the UI will pass the literal values and it's on the processor to
> decide what to do with them. Leading to multiple processors to interpret
> "\n", "\t" or "\r" entered in the UI as a new line, tab and carriage return
> respectively.
> It is reasonable for a user to want enter "\n" as a new line but it is also
> not correct to be inconsistent in how the user enters values throughout the
> UI. When entering a string in the UI there should be a second checkbox (next
> to "Empty") for "Interpreted" (name subject to change). This would allow
> users to select whether the values the enter are interpreted ("\n" -> new
> line character) vs literals ("\n" -> "\" and "\n"). Also this should allow
> for the support for entering unicode characters.
> In order to keep backwards compatibility the default would be not interpreted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (NIFI-2067) Fix MonitorMemory unit tests
Joseph Percivall created NIFI-2067: -- Summary: Fix MonitorMemory unit tests Key: NIFI-2067 URL: https://issues.apache.org/jira/browse/NIFI-2067 Project: Apache NiFi Issue Type: Bug Reporter: Joseph Percivall Priority: Minor I've seen failures in the MonitorMemory unit tests in tickets that are completely unrelated to MonitorMemory. For example, these PutTCP builds: https://travis-ci.org/apache/nifi/builds/139104774 The MonitorMemory unit tests should be changed to be more consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1769) Add support for SSE-KMS and S3 Signature Version 4 Authentication AWS
[ https://issues.apache.org/jira/browse/NIFI-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15339899#comment-15339899 ] Joseph Percivall commented on NIFI-1769: Sounds good, thanks for the update and taking time to review! > Add support for SSE-KMS and S3 Signature Version 4 Authentication AWS > - > > Key: NIFI-1769 > URL: https://issues.apache.org/jira/browse/NIFI-1769 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 0.5.1 >Reporter: Michiel Moonen >Priority: Minor > Labels: newbie, patch, security > Fix For: 1.0.0 > > > Currently there is no support for SSE-KMS S3 Signature Version 4 > Authentication. This is necessary for enhanced security features -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1769) Add support for SSE-KMS and S3 Signature Version 4 Authentication AWS
[ https://issues.apache.org/jira/browse/NIFI-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15339702#comment-15339702 ] Joseph Percivall commented on NIFI-1769: [~jameswing] why do you think this is better for 1.0 than 0.7.0? > Add support for SSE-KMS and S3 Signature Version 4 Authentication AWS > - > > Key: NIFI-1769 > URL: https://issues.apache.org/jira/browse/NIFI-1769 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Affects Versions: 0.5.1 >Reporter: Michiel Moonen >Priority: Minor > Labels: newbie, patch, security > Fix For: 1.0.0 > > > Currently there is no support for SSE-KMS S3 Signature Version 4 > Authentication. This is necessary for enhanced security features -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1834) Create PutTCP Processor
[ https://issues.apache.org/jira/browse/NIFI-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336683#comment-15336683 ] Joseph Percivall commented on NIFI-1834: Yup, added > Create PutTCP Processor > --- > > Key: NIFI-1834 > URL: https://issues.apache.org/jira/browse/NIFI-1834 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Brown >Priority: Minor > Fix For: 1.0.0, 0.7.0 > > Attachments: 0001-PutTCP-Processor-created.patch > > > Create a PutTCP Processor to send FlowFile content over a TCP connection to a > TCP server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (NIFI-1834) Create PutTCP Processor
[ https://issues.apache.org/jira/browse/NIFI-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336681#comment-15336681 ] Joseph Percivall commented on NIFI-1834: I'm going to assume it was commented it and the test is running fine that it should be removed. > Create PutTCP Processor > --- > > Key: NIFI-1834 > URL: https://issues.apache.org/jira/browse/NIFI-1834 > Project: Apache NiFi > Issue Type: New Feature > Components: Extensions >Reporter: Matt Brown >Priority: Minor > Fix For: 1.0.0, 0.7.0 > > Attachments: 0001-PutTCP-Processor-created.patch > > > Create a PutTCP Processor to send FlowFile content over a TCP connection to a > TCP server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (NIFI-2009) StandardProcessNode and AbstractConfiguredComponent duplicate instance variable "annotationData"
[ https://issues.apache.org/jira/browse/NIFI-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Percivall reopened NIFI-2009: This is not in 0.x yet but was marked resolved > StandardProcessNode and AbstractConfiguredComponent duplicate instance > variable "annotationData" > > > Key: NIFI-2009 > URL: https://issues.apache.org/jira/browse/NIFI-2009 > Project: Apache NiFi > Issue Type: Bug >Reporter: Oleg Zhurakousky >Assignee: Oleg Zhurakousky > Fix For: 1.0.0, 0.7.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
